[Kea-users] Testing option 43
Kraishak Mahtha
kraishak.edu at gmail.com
Wed Jun 14 14:02:54 UTC 2023
Yes, for a few of my lab centers that run using the ISC, I have checked the
config and they only have option 43 in their subnet without any option
spaces so I thought it would be the same for kea.
I don't have much familiarity with this option 43 but the current clients
in the subnet do use option 43, My existing production has the same options
with different values (a domain, number, and text) . I just replaced them
with some random text and I am checking the tcpdump of both ISC and Kea
server output to make sure I see the same results.
In ISC tcpdump I can see the option value for option 43 and for kea, it is
missing completely
TIME: 13:59:13.451640
IP: > (00:50:56:99:38:1c) > (00:50:56:99:5c:f3)
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 36835441
SECS: 0
FLAGS: 7f80
CIADDR: 0.0.0.0
YIADDR: 3.4.0.2
SIADDR: 0.0.0.0
GIADDR: 3.4.0.1
CHADDR: a1:21:2f:00:00:01:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION: 53 ( 1) DHCP message type 5 (DHCPACK)
OPTION: 54 ( 4) Server identifier 192.168.0.81
OPTION: 51 ( 4) IP address leasetime 86400 (24h)
OPTION: 1 ( 4) Subnet mask 255.255.0.0
OPTION: 3 ( 4) Routers 3.4.0.1
OPTION: 6 ( 12) DNS server 6.6.6.6,7.7.7.7,8.8.8.4
OPTION: 15 ( 11) Domainname test.com
OPTION: 43 ( 11) Vendor specific info 74657374 test
>>It sounds like you should be able to send data that isn't a suboption,
but I cannot find anywhere in the ARM that indicates that Kea supports this.
---> This is the major thing if we have different behavior change for
option 43 in kea compared to ISC
On Wed, Jun 14, 2023 at 6:48 PM Darren Ankney <darren.ankney at gmail.com>
wrote:
> Hi Kraishak,
>
> I don't know if I can provide more specific information than is
> contained in the RFC 2132 section about option 43:
> https://www.rfc-editor.org/rfc/rfc2132#section-8.4
>
> According to the RFC, the data in option 43 is "opaque" as it is meant
> to be vendor specific. It sounds like you should be able to send data
> that isn't a suboption, but I cannot find anywhere in the ARM that
> indicates that Kea supports this. It definitely supports sending
> sub-options of option 43 which is the usual case encountered in
> practice.
>
> Thank you,
>
> Darren Ankney
>
> On Wed, Jun 14, 2023 at 8:46 AM Kraishak Mahtha <kraishak.edu at gmail.com>
> wrote:
> >
> > Hi Darren,
> >
> > I am testing for each option and its corresponding behavior in kea by
> checking the tcpdump and packet4.log mainly
> >
> > Can you please confirm one thing, so basically to use option 43 do we
> must need to define the vendor-encapsulated-options-space in both ISC and
> Kea-DHCP?
> >
> > I am a bit confused here, maybe it would be basic but can you please
> give me more info on it or any reference link so that I can understand the
> scope of option 43
> >
> > Thanks In Advance
> > Kraishak
> >
> > On Tue, Jun 13, 2023 at 6:08 PM Darren Ankney <darren.ankney at gmail.com>
> wrote:
> >>
> >> Hi Kraishak,
> >>
> >> Does this do something for some device you are trying to support?
> >>
> >> option vendor-encapsulated-options "test";
> >>
> >> Typically, option 43 is defined on the basis of something that a
> >> vendor device needs to receive. That gives some constraints regarding
> >> how it is configured. Most of the time, it will be a collection of
> >> one or more sub-options. For example, here is one vendor's passing of
> >> a URL for tr69 in ISC DHCP:
> >>
> >> option space CALIXGC;
> >> option CALIXGC.acs-url code 1 = text;
> >> vendor-option-space CALIXGC;
> >> option CALIXGC.acs-url "http://someurl";
> >>
> >> which, translated to Kea, would look like this:
> >>
> >> "option-def": [
> >> {
> >> "space": "CALIXGC",
> >> "name": "acs-url",
> >> "code": 1,
> >> "type": "string"
> >> },
> >> {
> >> "name": "vendor-encapsulated-options",
> >> "code": 43,
> >> "type": "empty",
> >> "encapsulate": "CALIXGC"
> >> }
> >> ],
> >> "option-data": [
> >> {
> >> "name": "vendor-encapsulated-options",
> >> "code": 43
> >> },
> >> {
> >> "space": "CALIXGC",
> >> "name": "acs-url",
> >> "code": 1,
> >> "data": "http://someurl"
> >> }
> >> ]
> >>
> >> See if you can send that to your device or discover what actual data
> >> your device needs and we can see how that might be configured?
> >>
> >> Thank you,
> >>
> >> Darren Ankney
> >>
> >> On Tue, Jun 13, 2023 at 7:42 AM Kraishak Mahtha <kraishak.edu at gmail.com>
> wrote:
> >> >
> >> > Hi Darren,
> >> >
> >> > Thank you for the suggestion but I am still facing the same problem.
> >> >
> >> > {
> >> > "code": "43",
> >> > "csv-format": true,
> >> > "data": "74657374",
> >> > },
> >> >
> >> > ---> With the above format I am getting a few issues because of
> double quotes for the code, and for CSV format, If I set that to true I am
> getting an error as
> >> > 2023-06-13 06:23:40.309 ERROR [kea-dhcp4.dhcp4/6561.139810011805888]
> DHCP4_PARSER_FAIL failed to create or run parser for configuration element
> subnet4: option data does not match option definition (space: dhcp4, code:
> 43): attempt to write invalid option data field type into the option
> buffer: 0 (kea-dhcp4.conf:60:27)
> >> > Error encountered: option data does not match option definition
> (space: dhcp4, code: 43): attempt to write invalid option data field type
> into the option buffer: 0 (kea-dhcp4.conf:60:27)
> >> >
> >> > The final trial is as follows:
> >> > {
> >> > "code": "43",
> >> > "csv-format": false,
> >> > "data": "74657374",
> >> > },
> >> >
> >> > This also gave me an empty for option 43 in the ACK packet.
> >> >
> >> > This is the subnet of the ISC config that I using for testing
> >> > subnet 3.4.0.0 netmask 255.255.0.0 {
> >> > pool {
> >> > range 3.4.0.2 3.4.0.5;
> >> > range 3.4.0.12 3.4.0.16;
> >> > range 3.4.0.41 3.4.0.56;
> >> > }
> >> > default-lease-time 86400;
> >> > max-lease-time 86400;
> >> > option domain-name "test.com";
> >> > option domain-name-servers 6.6.6.6,7.7.7.7,8.8.8.4;
> >> > option routers 3.4.0.1;
> >> > option subnet-mask 255.255.0.0;
> >> > option vendor-encapsulated-options "test";
> >> > }
> >> >
> >> > Thanks
> >> > Kraishak
> >> >
> >> >
> >> >
> >> > On Tue, Jun 13, 2023 at 12:35 AM Darren Ankney <
> darren.ankney at gmail.com> wrote:
> >> >>
> >> >> Hi Kraishak,
> >> >>
> >> >> Have a look here:
> >> >>
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html?highlight=%22vendor-encapsulated-options%22#dhcpv4-vendor-specific-options
> >> >>
> >> >> You might need to setup encapsulated sub-options and tell Kea to
> >> >> include the "vendor-encapsulated-options-space" content in the
> options
> >> >> as a sub-option:
> >> >>
> >> >> "option-data": [
> >> >> {
> >> >> "name": "REPLACE_ME",
> >> >> "space": "vendor-encapsulated-options",
> >> >> "code": 1,
> >> >> "csv-format": false,
> >> >> "data": "74657374"
> >> >> },
> >> >> {
> >> >> "name": "vendor-encapsulated-options"
> >> >> }
> >> >> ]
> >> >>
> >> >> So, above, first the data is added as a sub-option of option 43
> >> >> (option 43 typically consists of one or more sub-options). Replace
> >> >> "REPLACE_ME" with the name of the sub-option you are trying to send
> (I
> >> >> think you can omit name entirely if there is none as that part isn't
> >> >> sent). Set the code to the correct sub-option number. If this
> >> >> particular data should not be a sub-option, then you might have to do
> >> >> something like this:
> >> >>
> >> >> {
> >> >> "code": "43",
> >> >> "csv-format": true,
> >> >> "data": "74657374",
> >> >> },
> >> >>
> >> >> please note that if "csv-format" is set to false, then Kea will be
> >> >> expecting "a hexadecimal string." see:
> >> >>
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html?highlight=%22csv-format%22#standard-dhcpv4-options
> >> >>
> >> >> Can you share the option 43 portion of the ISC DHCP configuration you
> >> >> are trying to convert if you still have trouble?
> >> >>
> >> >> Thank you,
> >> >>
> >> >> Darren Ankney
> >> >>
> >> >> On Mon, Jun 12, 2023 at 1:59 PM Kraishak Mahtha <
> kraishak.edu at gmail.com> wrote:
> >> >> >
> >> >> > Hi,
> >> >> > I am trying to convert my ISC config to kea-equivalent and testing
> the changes as part of the testing, I am stuck at testing option 43 ,
> >> >> > Using the keama tool I convert my ISC config to Kea equivalent
> config and tested the leases but in the DHCP ACK packet I cannot see option
> 43 coming when I operate with Kea
> >> >> >
> >> >> > sample code config for option 43 that I used in my testing subnet
> >> >> > {
> >> >> > "data": "74657374",
> >> >> > "name": "vendor-encapsulated-options",
> >> >> > "csv-format": false
> >> >> > },
> >> >> >
> >> >> > But in log and tcpdump I see the empty value for option 43
> >> >> >
> >> >> > Log:
> >> >> > ===
> >> >> > 2023-06-12 15:10:26.284 DEBUG
> [kea-dhcp4.packets/30590.140464453838592] DHCP4_RESPONSE_DATA [hwtype=1
> 21:21:2f:00:00:01], cid=[01:21:21:2f:00:00:01]x8259145: responding with
> packet DHCPACK (type 5), packet details: local_address=192.168.0.125:67,
> remote_address=4.0.0.1:67, msg_type=DHCPACK (5), =0x8259145,
> >> >> > options:
> >> >> > type=001, len=004: 4294901760 (uint32)
> >> >> > type=003, len=004: 4.0.0.1
> >> >> > type=006, len=012: 6.6.6.6 7.7.7.7 8.8.8.4
> >> >> > type=012, len=018: "dhcp-client-000001" (string)
> >> >> > type=015, len=011: "test.com" (string)
> >> >> > type=043, len=000: ----->Empty Value, and I cross-verified the
> tcpdump too.
> >> >> > type=051, len=004: 86400 (uint32)
> >> >> > type=053, len=001: 5 (uint8)
> >> >> > type=054, len=004: 192.168.0.125
> >> >> > type=061, len=007: 01:21:21:2f:00:00:01
> >> >> >
> >> >> > I have checked the discover packet option 55 just to make sure if
> my packet is asking for option 43 or not, and yes I can see option 43 in
> the option 55 parameter value.
> >> >> >
> >> >> > I am not sure what is wrong I am doing, Can someone who has
> familiar can guide me
> >> >> >
> >> >> > Thanks in Advance
> >> >> > Kraishak
> >> >> > --
> >> >> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >> >> >
> >> >> > To unsubscribe visit
> https://lists.isc.org/mailman/listinfo/kea-users.
> >> >> >
> >> >> > Kea-users mailing list
> >> >> > Kea-users at lists.isc.org
> >> >> > https://lists.isc.org/mailman/listinfo/kea-users
> >> >> --
> >> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >> >>
> >> >> To unsubscribe visit
> https://lists.isc.org/mailman/listinfo/kea-users.
> >> >>
> >> >> Kea-users mailing list
> >> >> Kea-users at lists.isc.org
> >> >> https://lists.isc.org/mailman/listinfo/kea-users
> >> --
> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>
> >> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> >>
> >> Kea-users mailing list
> >> Kea-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/kea-users
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230614/185a98a7/attachment-0001.htm>
More information about the Kea-users
mailing list