Pxe-E32: TFTP open timeout - FOG 1.5.10 - DHCP Windows Server 2019

[***Redbob]

Hi,

I cannot understand why a computer is not getting PXE boot, even when I configured everything correctly (I think so). I raised FOG 1.5.10 in Fedora 38 server, but when I try to boot a machine, I see the classical error: “Pxe-E32: TFTP open timeout”.

I use a Windows Server 2019 DHCP and everything is fine, as this imagem suggest:

Why it gathers 172.24.5.180 and not 172.24.3.70?

[george1421]

@Redbob Without being able to see the original pcap it makes this a little hard to debug on the boot file side to see if your dhcp server profiles are correct.

But on the surface if you are pxe booting a bios based computer everything looks right between the dhcp server configuration and the pcap. It should be working…

So I have to ask you this, is the pxe booting computer on the same subnet as the fog server? Is it local or across some WAN link?

[***Redbob]

@george1421 the server is in default subnet (172.24.0.0/22) and the workstation 172.24.12.35 is in WLAN 12 (172.24.12.0/23).

[george1421]

@Redbob said in Pxe-E32: TFTP open timeout - FOG 1.5.10 - DHCP Windows Server 2019:

server is in default subnet (172.24.0.0/22) and the workstation 172.24.12.35 is in WLAN 12 (172.24.12.0/23)

Specifically I’m asking if they are on the same site or different sites? I have seen the tftp download fail (which is what it looks like in the pcap) if the mtu of the link between the subnets are smaller than the default tftp packet size of 1456. I have seen WAN links sometimes have smaller than 1500 mtu.

Also is there a screening firewall between the subnets that might be blocking tftp traffic?

[george1421]

@Redbob What I’m seeing here:

It asks for the file size over and over again, on a 5 second timeout, then eventually it asks for the file. This should be a two packet process. 1. Ask for the file size and 2. Download the file. There is something abnormal going on here.

[***Redbob]

@george1421 I understand. There is another FOG server on the same subnet (172.24.3.71) that is normally working. I changed by this new one. Here are pcap file you asked before 12.35.pcap

[george1421]

@Redbob I think something happened to the pcap where it didn’t get uploaded correctly. I get file not found when I go to download it

[***Redbob]

@george1421 Here: 12.35.pcap

[george1421]

@Redbob Yes again we are seeing the multiple queries and then to load request. You have confirmed that 172.24.5.180 is the fog server?
Did you turn on any firewalls on the fog server, or are they on?

For a test, on a windows computer on the same subnet as the pxe booting computer, install the tftp client feature. Temp turn off the windows firewall (or this test will fail). Finally from a windows command line key in the following command tftp 172.24.5.180 get undiohly.kpxe see if you can download the file to your test computer on the remote subnet.

[***Redbob]

@george1421 Look at this pcap file about the other FOG server (172.24.3.71) - It’s working. That’s a 1.5.9 FOG running in Fedora 32 - I think it’s a client issue, because another client could caugth naturally PXE TFTP… I will exam differences between the two clients.

[***Redbob]

@george1421 No, 172.24.5.180 is not the FOG Server, it’s 172.24.3.70… I don’t even know where PXE come with this idea…

[***Redbob]

@george1421 I make another test with another client 172.24.12.65 running on same subnet to 172.24.12.35 - talking to the same server and got successfull - 12.65 - 3.70.pcap

[george1421]

@Redbob ok I think I know where its falling down but we need evidence and not an opinion.

Can you get a computer on the target’s network running wireshark? If yes create a pcap of the pxe booting process with this capture filter port 67 or port 68 This will only capture the dhcp process. What we are interested in is the dhcp OFFERS from one or more dhcp servers. In one of those OFFER packets is the bad actor that is sending your pxe booting into a loop. If you can’t figure it out who the bad actor is post the pcap here and I’ll look at it. The answer will be in the pcap. Use my capture filter so we only see the dhcp process and not other random traffic on your network.