[kea-dev] RSOO bug in 0.9.1

Templin, Fred L Fred.L.Templin at boeing.com
Tue Apr 21 19:28:11 UTC 2015


Hello Wlodek,

You are indeed correct that the Vendor-specific Information Option was
malformed due to my mis-read of the spec. I was consistently applying
the same incorrect format in all places, so that explains why it was
working with my ISC DHCP server code (which was treating the entire
VSIO as opaque data) but not with kea.

I made the necessary corrections, and now I am able to run my code with
the kea server and get the correct 4-message PD exchange (see attached
pcap file). 

I now feel comfortable migrating from the ISC DHCP server over to
kea. Thanks very much for incorporating the RSOO option, and for
your help in diagnosing this issue.

Thanks - Fred
fred.l.templin at boeing.com

> -----Original Message-----
> From: Wlodek Wencel [mailto:wlodek at isc.org]
> Sent: Tuesday, April 21, 2015 2:11 AM
> To: Templin, Fred L; kea-dev at lists.isc.org
> Subject: Re: [kea-dev] RSOO bug in 0.9.1
> 
> Hello,
> Yes I had some time but in future could you send captures from tcpdump
> in .pcap file not txt? That saves a lot of time.
> 
> I managed to convert you message and that is what I got:
> ###[ DHCP6 Relay-Supplied Options Option ]###
>               optcode= OPTION_RELAY_SUPPLIED_OPTIONS
>               optlen= 30
>               \relaysupplied\
>                |###[ DHCP6 Vendor-specific Information Option ]###
>                |     optcode= VENDOR_OPTS
>                |     optlen= 26
>                |     enterprisenum= 45282
>                |     \vso\
>                |      |###[ vendor specific option data ]###
>                |      |  optcode= 256
>                |      |  optlen= 33
>                |      |  optdata=
> '|\x1f\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\x14\x00\x00\n'
> 
> Message with such option can be classified as 'malformed'. We have here
> three values "optlen". Going from the end of the message:
> 
> vendor specific option data - optlen= 33
> Vendor-specific Information Option - optlen = 26 but should be 41
> (enterprise number + option data) if you want vendor specific option
> data to be part of the Vendor-specific Information Option.
> 
> And length of Relay-Supplied Options Option is 30... but should be 45
> because you are sending Vendor-specific Information Option in it.
> 
> Could you fix those values and check if your message exchange will be
> then correct?
> 
> Regards,
> Włodek Wencel
> 
> 
> 
> On 04/20/2015 06:12 PM, Templin, Fred L wrote:
> > Hello Wlodek,
> >
> > Have you had a chance to look into this yet?
> >
> > Thanks - Fred
> > fred.l.templin at boeing.com
> >
> >> -----Original Message-----
> >> From: Templin, Fred L
> >> Sent: Tuesday, April 14, 2015 12:09 PM
> >> To: 'Wlodek Wencel'; kea-dev at lists.isc.org
> >> Subject: RE: [kea-dev] RSOO bug in 0.9.1
> >>
> >> Hello Wlodek,
> >>
> >> See attached for the kea server configuration file plus a tcpdump packet capture
> >> of the Relay-forward and Relay-reply messages. The packet captures show that
> >> the Relay-forward includes a Vendor-Specific Information option with length
> >> 26, while the Relay-reply produced by the kea server only includes a VSIO with
> >> length 4. Let me know if you need any further information.
> >>
> >> Thanks - Fred
> >> fred.l.templin at boeing.com
> >>
> >>> -----Original Message-----
> >>> From: Wlodek Wencel [mailto:wlodek at isc.org]
> >>> Sent: Monday, April 13, 2015 8:08 AM
> >>> To: kea-dev at lists.isc.org
> >>> Cc: Templin, Fred L
> >>> Subject: Re: [kea-dev] RSOO bug in 0.9.1
> >>>
> >>> Hello,
> >>> Thank you for your email. I checked again RSOO feature in Kea (sending
> >>> Vendor-Specific Information Option with multiple sub-options, what I
> >>> assume you do) and unfortunately I could not reproduce error you described.
> >>>
> >>> Can you provide more details? Like kea config file and capture from
> >>> wireshark? Or details about Vendor-Specific Information Option you are
> >>> including to message?
> >>>
> >>> Regards,
> >>> Wlodek Wencel
> >>>
> >>> On 04/11/2015 12:44 AM, Templin, Fred L wrote:
> >>>> Hello,
> >>>>
> >>>> I am trying to use the new RFC6422 Relay Supplied Options Option (RSOO) facility.
> >>>> My RFC6221 relay inserts a Vendor-Specific Information Option (option #17) in the
> >>>> Relay-forward message that will be sent to the kea server. The option has length
> >>>> 26 decimal. But, when the kea server does the RFC6422 transformation it truncates
> >>>> the VSIO to only include the option header and the 4-byte enterprise number. The
> >>>> VSIO is then inserted into the DHCPv6 Reply message, but loses the 22 bytes that
> >>>> follow the enterprise number.
> >>>>
> >>>> See attached for the kea log. It does not show anything about the Relay-forward
> >>>> or Relay-reply messages, but does show how the server inserts the VSIO with
> >>>> length 4. Please let me know if any further information is needed.
> >>>>
> >>>> Fred Templin
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> kea-dev mailing list
> >>>> kea-dev at lists.isc.org
> >>>> https://lists.isc.org/mailman/listinfo/kea-dev
> >>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsoo.pcap
Type: application/octet-stream
Size: 921 bytes
Desc: rsoo.pcap
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20150421/76628757/attachment.obj>


More information about the kea-dev mailing list