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

[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

[george1421]

@cnkpadobi Not sure, but the pcap was damaged some how after 192.168.0.23 booted. When you pxe boot the one that fails, please pay attention to the IP address being issued. You should see that on the bios screen just before it transitions over to iPXE. So you have to read fast. That will tell me that I’m looking at the right system.

One question, the system that doesn’t boot is that a uefi system or bios (legacy mode) too?

[cnkpadobi]

ok got it to pxe boot… seems to work somewhat.

Was able to take image but still having issues deploying0_1478830627175_output.pcap

[cnkpadobi]

question was looking at the wireshark file. Since it has so many ip address in it… was thinking it may be picking up my voip phones as well… Is that possible?

[Wayne Workman]

@cnkpadobi It depends on how your network is laid out. Typically VOIP is put on a different network and also a different vlan which makes it impossible to see unless you’re connected to the same vlan. The addresses you see are likely broadcasts from other systems. ARP requests, DHCP Discovery and Requests, WhoIs requests, ICMP traffic, and other things. This stuff is normal network chatter.

If you want to filter what you’re seeing, in the filter box in wireshark, put in bootp and you’ll only see DHCP related traffic.

[george1421]

@cnkpadobi said in PXE-E51: No DHCP or proxyDHCP offers were received.:

question was looking at the wireshark file. Since it has so many ip address in it… was thinking it may be picking up my voip phones as well… Is that possible?

The pcap file is fine. It looks like you have a busy networks. We specifically created the tcpdump line to only include dhcp, dpchproxy and tftp traffic. This all looks normal, the dhcp inform lines are just the devices (mainly windows) telling the dhcp server, hello I’m still here.

Voip phones do add a bit of information since voip phones some times uses the next server (dhcp option 66) to locate the pbx server. By enabing dnsmasq and pointing it to the fog server you “may” run into provisioning issues with your voip handsets. But if your dhcp server didn’t ahve option 66 set when you started your voip phones may not use auto provisioning. Even if we did run into a conflict with dnsmasq we can make them happy together.

Are all of your computers on the same subnet or do you have a network router in your environment? (i.e. you have multiple sites, or buildings on your campus where you have a router to segregate traffic?)

[cnkpadobi]

no not all we have 15 different location as well.

How do I setup for my network to received computers from the different subnet.

[george1421]

@cnkpadobi well that opens up a bunch more questions about your setup. The main one is, do you have a dhcp server at each site?

But to get this working, let’s focus at just one site and one subnet. When you introduce a router between the client computer and the dhcp server you’ll need to use a dhcp helper service. When the fog server is on a different subnet from the pxe booting computer the dnsmasq service will not hear the dhcp hello broadcast.

[cnkpadobi]

So DHCP is done is on each subnet.

The Main one we been working on is 192.168.0.x
One of the sub sites 10.10.1.x

However the subnet and the main site is connect by MPLS Network

[george1421]

@cnkpadobi said in PXE-E51: No DHCP or proxyDHCP offers were received.:

So DHCP is done is on each subnet.

Does each subnet have its own dhcp server or do you have a central dhcp server? I can say that deploying images across an MPLS circuit will be very slow.

[cnkpadobi]

Thanks for the help…

I have another question, I have one machine is that is on a continuous loop.
Seen pic for the last screen before it loop. This was a machine that I tested and took  image on before.

And will not get to the quick registration screen. Lastly is there a way to set the fog registration screen with the options to stay a bit longer?

[Wayne Workman]

I have another question, I have one machine is that is on a continuous loop.

Check Task Management in the web interface to see if there is a task for this device. Tasks don’t just go away. They will stay in task management until either they are canceled or completed.

Lastly is there a way to set the fog registration screen with the options to stay a bit longer?

Web Interface -> FOG Configuration -> iPXE Boot Menu -> Menu Timeout (in seconds):*

Also, any additional questions, please ask them in a new thread.

[cnkpadobi]

Can’t seem to get my machines to deploy image just keep rebooting… Not sure what i am doing wrong     

[george1421]

@cnkpadobi Lets make sure we have the same terminology. FOG is capable of deploying an image to a target computer, but the target computer does not boot correctly once deployed?

[Wayne Workman]

@cnkpadobi If this thread’s original problem is solved, please create a new thread.