PXE-E51: No DHCP or proxyDHCP offers were received.
-
George is correct. The next step is looking at a capture.
-
Try commenting out port=0 and restarting dnsmasq.
-
He shouldn’t even be using dnsmasq honestly if his DHCP server is configured to support FOG.
-
@Wayne-Workman I skimmed most comments, was in a hurry, my bad.
-
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.
-
@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.
-
ok thanks
Here is the file…0_1478723712526_output.pcap
-
@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.
-
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.
- 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.
- 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
- At frame 8 the target device 40:2c:f4:ed:3f:a4 says, great I need to know these additional things
- 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?
- 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.
-
@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.
-
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.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@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.
-
Excellent work Sebastian and George. This makes sense.
-
Ok follow the steps.
- Turn off the watchguard DHCP options.
- enable dnsmasq on server
- 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
-
@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.
-
hmmm… ok why would the other machines not boot? will try to get another log file
-
@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?
-
ok got it to pxe boot… seems to work somewhat.
Was able to take image but still having issues deploying0_1478830627175_output.pcap
-
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?
-
@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
bootpand you’ll only see DHCP related traffic.
