> Just set up ISC DHCP on fresh CentOS 7 install and followed the redhat > guide linked in this thread. > Did what I thought was correct and duplicated the OPs problem. > /me scratches head. . . off to `tcpdump -vv -nn -i ens192`. . . packets > never lie. . . > Vendor-Class Option 60, length 32: > "PXEClient:Arch:00007:UNDI:003000" > > d'oh; I did _lower case_ a string in dhcpd.conf line on accident while > transcribing: > match if substring (option vendor-class-identifier, 0, 9) > "pxeclient";Ok, this is not the case here, case is correct, and tcpdump shows that the correct file is requested. However: 11:06:51.413549 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 390) 10.1.2.2.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 362, xid 0x4007adc6, Flags [Broadcast] (0x8000) Your-IP 10.1.2.57 Server-IP 10.1.2.1 <-- Client-Ethernet-Address 00:1b:21:d8:69:1c file "linux-install/bootx64.efi" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 10.1.2.2 Lease-Time Option 51, length 4: 43200 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 10.1.2.250 Domain-Name-Server Option 6, length 8: 10.1.2.2 Hostname Option 12, length 5: "client" Domain-Name Option 15, length 20: "foo.bar.com" NTP Option 42, length 8: 10.1.2.2 RN Option 58, length 4: 21600 RB Option 59, length 4: 37800 TFTP Option 66, length 11: "10.1.2.1" <-- END Option 255, length 0 11:06:51.413552 IP (tos 0x0, ttl 64, id 64565, offset 0, flags [none], proto UDP (17), length 84) 10.1.2.57.1943 > 10.1.2.2.69: [udp sum ok] 56 RRQ "linux-install/bootx64.efi" octet tsize 0 blksize 32768 <-- Where: dhcp server = 10.1.2.2, tftp server 10.1.2.1, client 10.1.2.57. DHCP answer is all good and the client still requests the wrong server I will check if there are any NIC fw updates. If not, the workaround is to move the tftp server to the dhcp server. And I thought computers were supposed to do my bidding and not the other way round ...
Once upon a time, isdtor <isdtor at gmail.com> said:> 11:06:51.413549 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 390) > 10.1.2.2.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 362, xid 0x4007adc6, Flags [Broadcast] (0x8000) > Your-IP 10.1.2.57 > Server-IP 10.1.2.1 <-- > Client-Ethernet-Address 00:1b:21:d8:69:1c > file "linux-install/bootx64.efi" > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: ACK > Server-ID Option 54, length 4: 10.1.2.2 > Lease-Time Option 51, length 4: 43200 > Subnet-Mask Option 1, length 4: 255.255.255.0 > Default-Gateway Option 3, length 4: 10.1.2.250 > Domain-Name-Server Option 6, length 8: 10.1.2.2 > Hostname Option 12, length 5: "client" > Domain-Name Option 15, length 20: "foo.bar.com" > NTP Option 42, length 8: 10.1.2.2 > RN Option 58, length 4: 21600 > RB Option 59, length 4: 37800 > TFTP Option 66, length 11: "10.1.2.1" <-- > END Option 255, length 0I do see a couple of differences - main one is that my boot file is in option 67, not the BOOTP "file" field. Also, my option 66 is a hostname, not an IP. I don't know how you tell ISC DHCP to use option 67 instead of the file field, but maybe that could trigger different client behavior? More odd is that dnsmasq is adding a null terminator to both options 66 and 67. My UEFI PXE clients seem to accept it just fine though. -- Chris Adams <linux at cmadams.net>
Chris Adams writes:> Once upon a time, isdtor <isdtor at gmail.com> said: > > 11:06:51.413549 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 390) > > 10.1.2.2.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 362, xid 0x4007adc6, Flags [Broadcast] (0x8000) > > Your-IP 10.1.2.57 > > Server-IP 10.1.2.1 <-- > > Client-Ethernet-Address 00:1b:21:d8:69:1c > > file "linux-install/bootx64.efi" > > Vendor-rfc1048 Extensions > > Magic Cookie 0x63825363 > > DHCP-Message Option 53, length 1: ACK > > Server-ID Option 54, length 4: 10.1.2.2 > > Lease-Time Option 51, length 4: 43200 > > Subnet-Mask Option 1, length 4: 255.255.255.0 > > Default-Gateway Option 3, length 4: 10.1.2.250 > > Domain-Name-Server Option 6, length 8: 10.1.2.2 > > Hostname Option 12, length 5: "client" > > Domain-Name Option 15, length 20: "foo.bar.com" > > NTP Option 42, length 8: 10.1.2.2 > > RN Option 58, length 4: 21600 > > RB Option 59, length 4: 37800 > > TFTP Option 66, length 11: "10.1.2.1" <-- > > END Option 255, length 0 > > I do see a couple of differences - main one is that my boot file is in > option 67, not the BOOTP "file" field. Also, my option 66 is a > hostname, not an IP. I don't know how you tell ISC DHCP to use option > 67 instead of the file field, but maybe that could trigger different > client behavior? > > More odd is that dnsmasq is adding a null terminator to both options 66 > and 67. My UEFI PXE clients seem to accept it just fine though.Yes, it looks like I'm out of luck and need to find a newer machine to test this with. Moving the tftp server works to an extent - server boots right into a grub prompt. I went over the linux-poweredge archives and found this: https://lists.us.dell.com/pipermail/linux-poweredge/2015-May/049810.html In particular: | 2. Don't waste time w/ a R*10, the UEFI PXE boot code is buggy! It misinterprets the NBP filename (DHCP option 67). That's an old Intel bug; they fixed it years ago in their BIOS PXE implementation. I'm guessing it was resurrected in their UEFI PXE implementation. | | Most all NIC vendors (Intel, Broadcom, etc) use the Intel reference implementation for PXE.