Once upon a time, Steven Tardy <sjt5atra at gmail.com> said:> The ?ICMP unreachable? should be a dead giveaway. . .You cut out the part of the email where the OP said that the UEFI system was ignoring the next-server part of the DHCP reply and trying to TFTP to the DHCP server instead of the TFTP server. Of course that got ICMP unreachable, but it isn't a firewall problem. To the OP: can you post a full tcpdump decode of the DHCP offer? I seem to remember having some issue with ISC DHCP in the past not getting the next server set correctly - maybe a packet will jog some memory (and I'll go try to grab the same from my dnsmasq DHCP for comparison). -- Chris Adams <linux at cmadams.net>
On Thu, Apr 25, 2019 at 8:46 PM Chris Adams <linux at cmadams.net> wrote:> Once upon a time, Steven Tardy <sjt5atra at gmail.com> said: > > The ?ICMP unreachable? should be a dead giveaway. . . > > You cut out the part of the email where the OP said that the UEFI system > was ignoring the next-server part of the DHCP reply and trying to TFTP > to the DHCP server instead of the TFTP server. Of course that got ICMP > unreachable, but it isn't a firewall problem. > > To the OP: can you post a full tcpdump decode of the DHCP offer? I > seem to remember having some issue with ISC DHCP in the past not getting > the next server set correctly - maybe a packet will jog some memory (and > I'll go try to grab the same from my dnsmasq DHCP for comparison). >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"; Changed it to follow redhat guide CAMELCase and poof, match if substring (option vendor-class-identifier, 0, 9) "PXEClient"; PXEClient tried to reach out "next-server". 00:42:24.606544 IP 1.2.3.10.1165 > 1.2.3.2.69: 50 RRQ "pxelinux/bootx64.efi" octet tsize 0 blksize 1468 If the OP still can't get this working, packet captures really do help. (; [root at DHCPServer ~]# cat /etc/dhcp/dhcpd.conf option arch code 93 = unsigned integer 16; #RFC 4578 subnet 1.2.3.0 netmask 255.255.255.0 { option routers 1.2.3.254; range 1.2.3.10 1.2.3.20; class "pxeclients" { match if substring (option vendor-class-identifier, 0, 9) "PXEClient"; next-server 1.2.3.2; if option arch = 00:06 { filename = "pxelinux/bootia32.efi"; } else if option arch = 00:07 { filename = "pxelinux/bootx64.efi"; } else { filename = "pxelinux/pxelinux.0"; } } }
> 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 ...