On Thu, Apr 25, 2019 at 8:46 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Steven Tardy sjt5atra@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@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"; } } }