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

[cnkpadobi]

Hello, When I try to take an image of a machine, I keep getting this message.

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

NOt sure what I am doing wrong

I have an inhouse DNS and DHCP server already setup.

Please help

here is my /etc/dnsmasq.d/ltps.conf file.

# Sample configuration for dnsmasq to function as a proxyDHCP server,
# enabling LTSP clients to boot when an external, unmodifiable DHCP
# server is present.
# The main dnsmasq configuration is in /etc/dnsmasq.conf;
# the contents of this script are added to the main configuration.
# You may modify the file to suit your needs.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Dnsmasq can also function as a TFTP server. You may uninstall
# tftpd-hpa if you like, and uncomment the next line:
# enable-tftp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename.
dhcp-boot=undionly.kpxe,192.168.0.253,192.168.0.253

# rootpath option, for NFS
dhcp-option=17,/images

# kill multicast
dhcp-option=vendor:PXEClient,6,2b

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 0

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot from network", undionly.kpxe

# A boot service type of 0 is special, and will abort the
# net boot procedure and continue booting from local media.
pxe-service=X86PC, "Boot from local hard disk", 0

# If an integer boot service type, rather than a basename is given, then the
# PXE client will search for a suitable boot service for that type on the
# network. This search may be done by multicast or broadcast, or direct to a
# server if its IP address is provided.
# pxe-service=x86PC, "Install windows from RIS server", 1

# This range(s) is for the public interface, where dnsmasq functions
# as a proxy DHCP server providing boot information but no IP leases.
# Any ip in the subnet will do, so you may just put your server NIC ip here.
# Since dnsmasq is not providing true DHCP services, you do not want it
# handing out IP addresses.  Just put your servers IP address for the interface
# that is connected to the network on which the FOG clients exist.
# If this setting is incorrect, the dnsmasq may not start, rendering
# your proxyDHCP ineffective.
dhcp-range=192.168.0.253,proxy

# This range(s) is for the private network on 2-NIC servers,
# where dnsmasq functions as a normal DHCP server, providing IP leases.
# dhcp-range=192.168.0.20,192.168.0.250,8h

# For static client IPs, and only for the private subnets,
# you may put entries like this:
# dhcp-host=00:20:e0:3b:13:af,10.160.31.111,client111,infinite

Tom Elliott – Edited to wrap the code in triple backticks so we can actually read the config more properly.

[Tom Elliott]

Is the IP of the fog server 192.168.0.253?

Is the DHCP handing out DNS addresses within the 192.168.0 range?

What version of FOG are you running? What OS are you running? Is firewall enabled? Is selinux enforcing?

[cnkpadobi]

Yes, that is the Fog Server Ip

Yes dns is being handed out in the 192.168.0 range.

I am using version 1.2.0

I am running
ubuntu 14.04.5 LTS
No firewall enable and Does Selinux need to be enforced?

[cnkpadobi]

Also when this is fixed I wanted to make sure that my remote sites that are on the 10.10.x.x networks to be able to reach the imaging machine for imaging as well.

[george1421]

OK lets backup a bit here.

What device is your dhcp server for this subnet?
What OS is your dhcp server running?
Is the dhcp server, fog server, and the pxe booting target in the same subnet range?

[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.