Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: RSOO bug in 0.9.1 (Templin, Fred L)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Apr 2015 19:28:11 +0000
From: "Templin, Fred L" <[email protected]>
To: Wlodek Wencel <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] RSOO bug in 0.9.1
Message-ID:
<2134f8430051b64f815c691a62d9831832e4e...@xch-blv-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="utf-8"
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
[email protected]
> -----Original Message-----
> From: Wlodek Wencel [mailto:[email protected]]
> Sent: Tuesday, April 21, 2015 2:11 AM
> To: Templin, Fred L; [email protected]
> 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
> > [email protected]
> >
> >> -----Original Message-----
> >> From: Templin, Fred L
> >> Sent: Tuesday, April 14, 2015 12:09 PM
> >> To: 'Wlodek Wencel'; [email protected]
> >> 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
> >> [email protected]
> >>
> >>> -----Original Message-----
> >>> From: Wlodek Wencel [mailto:[email protected]]
> >>> Sent: Monday, April 13, 2015 8:08 AM
> >>> To: [email protected]
> >>> 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
> >>>> [email protected]
> >>>> 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-0001.obj>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 13, Issue 12
***************************************
