PXE-E51: No DHCP or proxyDHCP offers were received.

[cnkpadobi]

@george1421

DHCP is done by my firewall… Its a watchguard firewall.

My DNS is on a windows Server
Yes, all targeting the same network

I am actually getting a different message.

So I tried to pxe boot two different type of machine

1. Hyper V machine I got the above PXE-E51 error
2. Stand alone box I get the follow error : PXE-E32 TFTP Open timeout

[Wayne Workman]

@cnkpadobi Can you configure the watchguard dhcp with DHCP options? Look through the settings and look for Option 066, 067, next-server, and filename, or anything that looks/sounds very similar.

[cnkpadobi]

yes I setup dhcp options already

[george1421]

@cnkpadobi OK good your router at least supports the pxe booting options.

From here to see what is really going on, we need to get a pcap of the booting communications.

This is pretty simple since all of these devices are on the same subnet.

1. Install tcpdump on your FOG server.
2. Ensure that dnsmasq is not running on your fog server. If your dhcp server supports dhcp options 66 and 67 then dnsmasq is not needed at this time (possibly in a bit, but lets get this system pxe booting)
3. start the tcpdump program with the following options: tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
4. Now pxe boot the target computer to the error message
5. At the pxe target error press ctrl-C on tcpdump to exit the program.
6. YOU can either review this pcap file with wireshark, or you can post it here and we can review it for you. (if you don’t know what you are looking for, just post it here).

This pcap file will tell is the truth of what is going on in the wire.

[Wayne Workman]

George is correct. The next step is looking at a capture.

[Quazz]

Try commenting out port=0 and restarting dnsmasq.

[Wayne Workman]

He shouldn’t even be using dnsmasq honestly if his DHCP server is configured to support FOG.

[Quazz]

@Wayne-Workman I skimmed most comments, was in a hurry, my bad.

[cnkpadobi]

I am not sure if I am doing it right. However when I ran the tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 it did not report anything back after pxe booting the machine.

[george1421]

@cnkpadobi That second screen shot said that it was working. It captured 39 packets and saved them in the output.pcap file in your /etc/selinux directory (I probably would have selected a better directory like root’s home directory).

By using that specific filter we only captured the pxe booting process and not stuff we shouldn’t see, which should have been about 39 packets.

[cnkpadobi]

ok thanks

Here is the file…0_1478723712526_output.pcap

[george1421]

@cnkpadobi can you supply the mac address of the computer you are trying to pxe boot. It appears as if you have a pretty busy network. I want to make sure I’m focusing on the right computer asking for dhcp services.

[george1421]

I looked at this a bit more in a quiet room and I see the flow in the code.

Let me translate what I see into words.

1. At frame 6 a device 40:2c:f4:ed:3f:a4 says, hello I’m here. Tell me about the world. I’m a bios based IA86 system.
2. At frame 7 192.168.0.1 says hi, I hear you and this is the stuff I know about and just in case you need it the tftp boot server (66) is 192.168.0.253 and the boot file name (67) is undionly.kpxe
3. At frame 8 the target device 40:2c:f4:ed:3f:a4 says, great I need to know these additional things
4. At frame 9 192.168.0.1 says here is the stuff you requested and your IP address is 192.168.0.23 your server host name is 192.168.0.253 and your boot file is undionly.kpxe, are you good?
5. After that nothing else is happening. I would assume here we should see the target computer request undionly.kpxe from the FOG server. This did not happen there are only dhcp communications in this pcap file.

So from this pcap I see your dhcp server is 192.168.0.1. It is handing out dhcp option 66 192.168.0.253 and dhcp option 67 undionly.kpxe. From this pcap I would say it should be working!!

I guess the next debugging step would be to install a tftp client on a windows system (from programs and features) also be sure to allow it through your windows firewall. And then try to use a tftp get to download undionly.kpxe from the FOG server. I might think that the firewall has not been disabled on the FOG server because I find its strange that the right information has been sent to the target computer but we are not seeing the download request in the pcap and the client is saying tftp timeout.

[Wayne Workman]

@george1421 Ubuntu typically doesn’t have firewall on. According to your analysis the dhcp server is configured correctly, yet hosts say no dhcp or proxy dhcp response.

I think the host he was trying to boot was on a different network segment, or has a bad patch cable or switch or something. Because if the hosts had even got pxe info from dhcp there would be a different error than reported.

I guess tge question I would ask is has fog ever worked in this environment, and where is it currently working?

Also Georges first question about what MAC the problem host has would be very helpful to know.

[Sebastian Roth]

George has done a great bit getting the right information and analyzing the packet dump. Thanks for that!!

Looking at the dump I see a nearly perfect DHCP/PXE conversation going on. I say nearly because there is one thing I notice that might cause the issue. There are two places in a DHCP packet where PXE information can be stored. First is within the general DHCP header. The fields are decoded and named by wireshark as “Next server IP address” and “Boot file name”. And then there are the DHCP options following the header. There you have option 66 “TFTP Server Name” and option 67 “Bootfile name”.

Now what’s wrong with this? My guess is that most clients are happy to use either of those to find TFTP server and file to load. But in this case the watchguard firewall does send “Next server IP address” empty (0.0.0.0) but supplies the “Boot file name” within the header. Although it also sends option 66 and 67 the client might just be confused by the missing IP for next serer in the header. It sees “Boot file name” being not empty in the header and might try to use this pair of information instead of the 66/67 options.

Just a wild idea, haven’t tried this myself yet. If this is the case you might need to disable the PXE options on your watchguard and use dnsmasq again. But possibly you can figure out the watchguard config to make this work as well.

[george1421]

@Sebastian-Roth I also saw that (missing next server) but I thought the “server host name” was the same. I guess I was wrong.

What Sebastian is taking about is in packet 7 and packet 9 the next server value is missing in the dhcp header, but the server host name IS set.

Packet 7

Packet 9

I agree with Sebastian’s recommendation to remove the dhcp options 66 and 67 from the watchguard box and then enable dnsmasq again on the FOG server. The DNSMasq service will provide the missing values (66 and 67) not supplied by the watchguard dhcp server. The watchguard will continue to manage the dhcp IP address pool, but dnsmasq will provide these values via dhcpProxy. I did allude to this in my previous post step 2.

To explain it a bit more, if the OP must support both uefi and bios clients dynamically he will need to use the latest version of dnsmasq to dynamically supply undionly.kpxe to bios clients and ipxe.efi to uefi clients.

[Wayne Workman]

Excellent work Sebastian and George. This makes sense.

[cnkpadobi]

Ok follow the steps.

1. Turn off the watchguard DHCP options.
2. enable dnsmasq on server
3. Got the first machine to pxe boot and was able to take snapshot of the machine.

While taking a snapshot of the machine, I decided to see if I can pxe boot and register another machine.

HOwever, I got the origal mesage again… HOwever the other machine is still working.

Here is a capture of my log files 0_1478826719275_output.pcap

[george1421]

@cnkpadobi I see a normal pxe booting process for 192.168.0.23, That looks beautiful. I see both your dhcp server and the dnsmasq respond and then the client asks for the undionly.kpxe from the tftp server.

Looking through the rest of the file.

The rest of the file seems to be damaged. But I can see that 192.168.0.23 iPXE booted well.

[cnkpadobi]

hmmm… ok why would the other machines not boot? will try to get another log file