[kea-dev] RSOO bug in 0.9.1

Wlodek Wencel wlodek at isc.org
Tue Apr 21 09:11:16 UTC 2015

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
               |###[ DHCP6 Vendor-specific Information Option ]###
               |     optcode= VENDOR_OPTS
               |     optlen= 26
               |     enterprisenum= 45282
               |     \vso\
               |      |###[ vendor specific option data ]###
               |      |  optcode= 256
               |      |  optlen= 33
               |      |  optdata=

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?

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

More information about the kea-dev mailing list