@sebastian-roth said in Can't get UEFI to PXE boot:
@jclumbo33 Well done, the new PCAPs have all the information we need to look into this!
Comparing the DHCP discovery packets between the two I see a few minor differences:
- Option 60: Vendor Class Identifier (see section 3 in RFC 3925)
- Option 93: Client System Architecture (see section 2.1 in RFC 4578)
- Option 94: Client Network Device Interface (see section 2.2 in RFC 4578)
- Option 57: Maximum DHCP Message Size (see section 9.10 in RFC 2132)
All those seem obvious to me and I would not expect any to cause this trouble.
Now let’s take a look at the actual DHCP sequence. Client sends DHCP discover and we see the DHCP offer in response in both cases. While the BIOS PCAP proceeds with the expected DHCP request packet the UEFI one does not!
That’s real interesting because I don’t see much of a difference in the Dhcp offer except bootfile name (as we want it) and DHCP transaction ID (expected and not a problem). I have compared the two DHCP offers and can’t see why this shouldn’t work.
Well there is one thing jumping at me. You seem to use non default subnetting masks. This is totally fine as long as your network admins know what they are doing and I expect this to be the case. BUT I can imagine the UEFI firmware to go mad at this (for no good reason really!) and stop the DHCP handshake at this point.
You said that PXE boot works in a different VLAN - which probably uses a different IP subnet and maybe also a different subnet mask?!
You are correct, the VLAN that it works on uses a /16 subnet. That’s interesting, so we could potentially be screwed without redoing our network then?
Here’s an idea of maybe a workaround? Our fog server is running in Hyper-V. If I add a NIC to the VM and put it on each VLAN we need, then point the DHCP options to the new IP address on the same VLAN, would that potentially act as a work around? And is that even possible to configure fog with multiple NICs like that? Just a thought.
