Btw if it helps, I can provide the debug output of the kea 1.1 and 1.6 The strange thing is, that I see within the output two different type=60 queries. One match the (I)NODE test and the other doesn't.
But as explained the boot-file-name is set always to the content of the (I)NODE client-class... Below the output of the working 1.1 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.packets/103] DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to 255.255.255.255:67 over interface eno0 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.options/103] DHCP4_BUFFER_UNPACK parsing buffer received from 0.0.0.0 to 255.255.255.255 over interface eno0 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.options/103] EVAL_RESULT Expression NODE evaluated to 0 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION Pushing option 60 with value 0x505845436C69656E743A417263683A30303030303A554E44493A303032303031 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING Pushing text string '0' 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING Pushing text string '4' 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_SUBSTRING Popping length 4, start 0, string 0x505845436C69656E743A417263683A30303030303A554E44493A303032303031 pushing result 0x50584543 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING Pushing text string 'udhcp' 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping 0x7564686370 and 0x50584543 pushing result 'false' 2020-02-26 20:06:07.672 INFO [kea-dhcp4.options/103] EVAL_RESULT Expression bios evaluated to 1 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION Pushing option 93 with value 0x0000 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_HEXSTRING Pushing hex string 0x0009 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping 0x0009 and 0x0000 pushing result 'false' 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103] EVAL_RESULT Expression efi64 evaluated to 0 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION Pushing option 93 with value 0x0000 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_HEXSTRING Pushing hex string 0x0007 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping 0x0007 and 0x0000 pushing result 'false' 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103] EVAL_RESULT Expression ipxe_efi64 evaluated to 0 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.1/16 for packet received by matching address 10.0.103.1 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_SUBNET_SELECTED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX: the subnet with ID 1 was selected for client assignments 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_SUBNET_DATA [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX: the selected subnet details: 10.0.0.1/16 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_PACKET_RECEIVED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX: DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface mvlprov 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_QUERY_DATA [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX, packet details: local_address=255.255.255.255:67, remote_adress=0.0.0.0:68, msg_type=DHCPDISCOVER (1), transid=0x99XXXXXX, options: type=053, len=001: 1 (uint8) type=055, len=036: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 11(uint8) 12(uint8) 13(uint8) 15(uint8) 16(uint8) 17(uint8) 18(uint8) 22(uint8) 23(uint8) 28(uint8) 40(uint8) 41(uint8) 42(uint8) 43(uint8) 50(uint8) 51(uint8) 54(uint8) 58(uint8) 59(uint8) 60(uint8) 66(uint8) 67(uint8) 128(uint8) 129(uint8) 130(uint8) 131(uint8) 132(uint8) 133(uint8) 134(uint8) 135(uint8) type=057, len=002: 1260 (uint16) type=060, len=032: "PXEClient:Arch:00000:UNDI:002001" (string) type=093, len=002: 0(uint16) type=094, len=003: 1 (uint8) 2 (uint8) 1 (uint8) type=097, len=017: 0 (uint8) YYYYYYYYYYYYYYYYYYYYYYYYYY (binary) 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.1/16 for packet received by matching address 10.0.103.1 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_SUBNET_SELECTED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX: the subnet with ID 1 was selected for client assignments 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_SUBNET_DATA [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX: the selected subnet details: 10.0.0.1/16 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 1, identified by hwaddr=B42E99XXXXXX 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=B42E99XXXXXX 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103] HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier: hwaddr=B42E99XXXXXX, found host: hwaddr=B42E99XXXXXX ipv4_subnet_id=1 hostname=my_NODE ipv4_reservation=10.0.7.1 siaddr=10.0.103.25 sname=10.0.103.45 file=(empty) ipv6_reservations=(none) dhcp4_class0=NODE 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=B42E99XXXXXX, found 1 host(s) 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 1 and identifier hwaddr=B42E99XXXXXX, found host: hwaddr=B42E99XXXXXX ipv4_subnet_id=1 hostname=my_NODE ipv4_reservation=10.0.7.1 siaddr=10.0.103.25 sname=10.0.103.45 file=(empty) ipv6_reservations=(none) dhcp4_class0=NODE 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcp4/103] DHCP4_CLASS_ASSIGNED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX: client packet has been assigned to the following class(es): INIT_n0701, VENDOR_CLASS_PXEClient:Arch:00000:UNDI:002001, bios 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.ddns/103] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX: processing client's Hostname option 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.ddns/103] DHCP4_RESERVED_HOSTNAME_ASSIGNED [hwtype=1 b4:2e:99:XXXXXX], cid=[no info], tid=0x99XXXXXX: server assigned reserved hostname my_NODE 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103] DHCPSRV_MEMFILE_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID 1 and hardware address hwtype=1 b4:2e:99:XXXXXX 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.alloc-engine/103] ALLOC_ENGINE_V4_DISCOVER_HR client [hwtype=1 b4:2e:99:XXXXXX], cid=[no info], tid=0x99XXXXXX sending DHCPDISCOVER has reservation for the address 10.0.7.1 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.7.1 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.7.1 2020-02-26 20:06:07.672 INFO [kea-dhcp4.leases/103] DHCP4_LEASE_ADVERT [hwtype=1 b4:2e:99:XXXXXX], cid=[no info], tid=0x99XXXXXXX: lease 10.0.7.1 will be advertised 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103] DHCP4_PACKET_PACK [hwtype=1 b4:2e:99:XXXXXX], cid=[no info], tid=0x99XXXXXXX: preparing on-wire format of the packet to be sent 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_PACKET_SEND [hwtype=1 b4:2e:99:XXXXXXX], cid=[no info], tid=0x99XXXXXXXX: trying to send packet DHCPOFFER (type 2) from 10.0.103.1:67 to 255.255.255.255:68 on interface mvlprov 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_RESPONSE_DATA [hwtype=1 b4:2e:99:XXXXXXX], cid=[no info], tid=0x99XXXXXXXX: responding with packet DHCPOFFER (type 2), packet details: local_address=10.0.103.1:67, remote_adress=255.255.255.255:68, msg_type=DHCPOFFER (2), transid=0x99XXXXXXX, options: type=001, len=004: 4294901760 (uint32) type=012, len=005: "my_NODE" (string) type=051, len=004: 3600 (uint32) type=053, len=001: 2 (uint8) type=054, len=004: 10.0.103.1 type=058, len=004: 900 (uint32) type=059, len=004: 1800 (uint32) 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103] DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000 ms I hope this is the full data that is required. -----Original Message----- From: Kea-users [mailto:[email protected]] On Behalf Of Stephan Walter Sent: Wednesday, February 26, 2020 7:32 PM To: Oswald <[email protected]>; [email protected] Subject: [** SUSPICIOUS EMAIL **] Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6 Sorry, I tested INODE as well as NODE with the same result. So it is the SAME within the config, not NODE and INODE within the same file -----Original Message----- From: Kea-users [mailto:[email protected]] On Behalf Of Oswald Sent: Wednesday, February 26, 2020 7:21 PM To: [email protected] Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6 Hie Stephan, Is the client-class "INODE" or "NODE" /Os On 26/02/2020 18:07, Stephan_Walter wrote: > Hi, > > I moved from the kea 1.1 server, provided through the epel repo of > CentOS7, to a kea 1.6 server compiled on CentOS8 from srpm. > > The new kea worked from the beginning, but when I tried to boot nodes, > they received the wrong boot-file from the kea. Let me show the > relevant part of the kea config. > > > { > "Dhcp4": { > ... > "option-data": [ ], > "client-classes": [ > { > "name": "INODE", > "test": "substring(option[60].hex,0,4) == 'udhcp'", > "boot-file-name": "somefancy\n\\,string=now" > }, > { > "name": "bios", > "test": "option[93].hex == 0x0000", > "boot-file-name": "/tftp/bios/lpxelinux.0" > }, > { > "name": "ipxe_efi64", > "test": "option[93].hex == 0x0007", > "boot-file-name": "/tftp/efi64/ipxe.efi" > }, > { > "name": "efi64", > "test": "option[93].hex == 0x0009", > "boot-file-name": "/tftp/efi64/bootx64.efi" > } > ], > "subnet4": [ > { > "subnet": "10.0.0.1/16", > "reservations": [ > { "hw-address": "XX:XX:XX:XX:XX:XX", "ip-address": "10.0.2.1", > "next-server": "10.0.103.22", "hostname": "some_node", "client-classes": > ["NODE"], "server-hostname": "10.0.103.42"}, > ] > .... > > } > > > So with kea 1.1 the behavior is, that the system boots through PXE and > get "/tftp/..." as boot-file-name. Afterward, the system make again a > DHCP request and now get the "somefancy.." string as boot-file-name, > that it use to fetch additional data for a two stage boot > > With kea 1.6 already in the first response the "somefancy..." string > is replied as boot-file-name, what lead to a non working PXE boot. > > I tried now for several days without success to figure out what has changed. > > What I have found is: > > > But even after a reordering of the client class definition, so that > the pxe boot is at the top, the problem still occurs. > > Anybody an idea how I can get with kea 1.6 the same behavior as with 1.1? > > > > -- > Sent from: http://kea-users.7364.n8.nabble.com/ > _______________________________________________ > Kea-users mailing list > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users Click https://www.mailcontrol.com/sr/TA4wI8ajHdrGX2PQPOmvUpFBc4ZD8M8Usm8CQOShYRk3_VbzlmlReMMFBOEtnguvZn5f4yhWRYpAlVq5uz6AOA== to report this email as spam. _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
