Topics created by JLE

@JLE Looks quite interesting that packet dump. Something I have not come across in a long time. I am trying to write down what I see in the PCAP to hopefully make any sense as I don’t see what’s wrong yet. Maybe George can add to that as well.

First the PXE ROM of the NIC sends a DHCP Discover and does not get an answer. So 8 seconds later it sends another Discover (same information but just a new DHCP transaction ID). The second DHCP Discover is answered with a DHCP Offer very promptly (delay only ms). Transaction IDs of the second Discover and the following Offer match so the answer is definitely not a delayed one to the first Discover. Question: Why is the first DHCP Discover not answered? (this is happening again later on) As far as I can see the DHCP Offer looks good (next-server and filename set properly). Now the client is quiet for 16 seconds before sending a DHCP Request packet to complete the DHCP communication. This Request packet is promptly answered by a proper looking DHCP ACK. So client is finally happy I suppose. Then I suspect the TFTP transfer to happen which was not captured. See the next bullet point. Another 12 seconds after the first DHCP DORA (Discover, Offer, Request, ACK) finished I see a new DHCP Discover from that client. This time option 175 is set which is a clear sign for iPXE sending the packet. And the same thing is happening again. No answer from the DHCP server for 8 seconds and the client (now iPXE instead of the PXE ROM) sends another DHCP Discover which is promptly answered with a fine DHCP Offer. After the Offer the client sends a third DHCP Discover and then a DHCP Request just a second later. I think this is where things start to go really wrong. I suppose iPXE is very confused about the DHCP server only answering the second DHCP Discover (matching transaction ID). I haven’t checked the iPXE code yet but I guess this is something unexpected now causing an issue in your case. Following are a row of DHCP Request packets from the client which are all answered by DHCP NAK (non ACK!) packets. So the DHCP server declines to give that offered IP information to the client. Result is the “No configuration methods succeeded” message in iPXE. In the packet dump I see the same thing happening again a minute later. But one thing is different this time. The very first DHCP Discover sent by the client’s PXE ROM is answered within one second this time. But for the DHCP Discover sent by iPXE I see again the exact same behavior as described above.

I guess this can be fixed in iPXE but I doubt this is the right place to do so. There is something wrong within your network. Do those first DHCP Discover packet get lost somewhere along the way? Why is the second one answered so promptly then?

Ok, I’ll leave this ti you for now. We all need to think about it and I am sure someone will come up with a proper explanation on what’s going wrong here.

@Sebastian-Roth I changed the FOG server over to 255.255.240.0, the old subnet was from before vlans were implemented it just got passed over 😛

My experience is sanboot works on most computers.

Dell Optiplex 9020s need Grub, even if they are in BIOS mode - not sure why on that but since it works I didn’t really spend time on it.

HP EliteBooks need Grub, even though they are in BIOS mode.

I should mention, every computer in my building - and we have maybe 15 different models - is successfully booting to the network every time they are turned on, and getting kicked to Windows when there isn’t a task scheduled. We’ve been working towards that for a long time, and finally got them all over the summer. Imaging is a dream now.

UEFI computers need various settings - I just go through the list until I find one that works. It’s usually refind.

Our environment has the correct exit mode per-machine. We have the global default set to sanboot, but we use fog groups when needed to set exit types where needed.