Hi Kraishak, Please provide the error message that you received.
Thank you, Darren Ankney On Sun, Jun 18, 2023 at 1:34 AM Kraishak Mahtha <[email protected]> wrote: > > Hi Darren, > This might be best kept out of the global area (use in subnet, classes > etc..), > ------>do you mean the following? > > "subnet4": [ > { > "subnet": "4.0.0.0/16", > "valid-lifetime": 86400, > "option-def": [{ > "code": 43, > "name": "vendor-encapsulated-options", > "type": "string", > "space": "dhcp4" > }], > "option-data": [ > { > "name": "vendor-encapsulated-options", > "data": "any old string" > }, > { > "data": "6.6.6.6, 7.7.7.7, 8.8.8.4", > "name": "domain-name-servers" > }, > { > "data": "86400", > "name": "dhcp-lease-time" > }, > { > "data": "255.255.0.0", > "name": "subnet-mask" > }, > { > "data": "4.0.0.1", > "name": "routers" > }], > "pools": [ > { > "pool": "4.0.0.2-4.0.6.125" > } > ], > "id": 786173 > }, > but it gives a syntax error for me and I don't see any reference in any > forums too that declares the option definition within the subnet. > > > On Thu, Jun 15, 2023 at 9:21 PM Darren Ankney <[email protected]> wrote: >> >> Hi Kraishak, >> >> I am informed by a colleague that you can redefine the expected >> contents of option 43 as shown: >> "option-def": [ >> { >> "name": "vendor-encapsulated-options", >> "code": 43, >> "type": "string" >> } >> "option-data": [ >> { >> "name": "vendor-encapsulated-options", >> "data": "any old string" >> }, >> ] >> which will allow you to store strings directly in the option. This >> might be best kept out of the global area (use in subnet, classes >> etc..), however, in case you need to use option 43 in the default way >> with sub-options. >> >> Thank you, >> >> Darren Ankney >> >> On Wed, Jun 14, 2023 at 10:03 AM Kraishak Mahtha <[email protected]> >> wrote: >> > >> > 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 <[email protected]> >> > 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 <[email protected]> >> >> 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 <[email protected]> >> >> > 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 >> >> >> <[email protected]> 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 >> >> >> > <[email protected]> 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 >> >> >> >> <[email protected]> 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 >> >> >> >> > [email protected] >> >> >> >> > 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 >> >> >> >> [email protected] >> >> >> >> 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 >> >> >> [email protected] >> >> >> 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 >> >> [email protected] >> >> 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 >> [email protected] >> 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 [email protected] https://lists.isc.org/mailman/listinfo/kea-users
