PXE-E78 Cannot locate boot server

[george1421]

@mkstreet Well the first issue is that the FOG server MUST be at a static IP address (period). The issue comes (even if you use dhcp reservations) just as you noted the resolv.conf file will change based on outside forces. Once the network mode is set to static then resolve.conf should stay put. I don’t know if dnsmasq is forcing a dhcp renew or not, but what you have is not what I see on my FOG-Pi server that IS running dnsmasq.

[george1421]

@george1421 The pxe error PXE-E78 means that the boot server that is either being returned by dhcp either doesn’t exist or that value is not being returned. Lets fix the IP address on the fog server. You can keep it at this address, it just needs to be configured in linux as static. Once you do that you should inspect the content of the /etc/resolv.conf file to make sure it is configured as you need it.

[mkstreet]

@george1421

Ok I changed /etc/network/interfaces and did a reboot (to be sure my changes were implemented):

compteach@iepcomlabsrv:/etc/network$ cat interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto em1
iface em1 inet static
address 10.0.253.24
netmask 255.255.255.0
gateway 10.0.253.1
dns-nameservers 110.164.252.222 8.8.8.8

However, I still seem to have unknown hosts and the resolv.conf just has the loopback address:

compteach@iepcomlabsrv:/etc/network$ sudo service dnsmasq status
 * Checking DNS forwarder and DHCP server dnsmasq                                                                                                                       * (running)
compteach@iepcomlabsrv:/etc/network$
compteach@iepcomlabsrv:/etc/network$
compteach@iepcomlabsrv:/etc/network$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
compteach@iepcomlabsrv:/etc/network$ ping google.com
ping: unknown host google.com
compteach@iepcomlabsrv:/etc/network$

Do I need to do anything with the /etc/dnsmasq.conf file ?

[george1421]

@mkstreet This is very strange, indeed. If you manually set the values in resolv.conf and then start and stop dnsmasq does it change the settings? I’m going to confirm on my Pi server to see if it does the same things. In my experience it does not.

[george1421]

@george1421 OK I sit here a bit red faces, since my server does the same thing AND I have it setup to use dhcp. AND my server is working correctly. I need to look into this now.

[george1421]

@george1421 Just to be clear every line in /etc/dnsmasq.conf is commented out?

And actually dnsmasq is suppose to rewrite the file. I takes what was in there and caches it internally and then puts the loopback address in to point to itself.

Also you disabled the iptables firewall on this server right?

[mkstreet]

@george1421

For the /etc/dnsmasq.conf, the last lines are NOT commented out as shown here:

# For debugging purposes, log each DNS query as it passes through
# dnsmasq.
#log-queries
# MKS 04-Oct-2016
log-queries

# Log lots of extra information about DHCP transactions.
#log-dhcp
# MKS 04-Oct-2016
log-dhcp

# Include another lot of configuration options.
#conf-file=/etc/dnsmasq.more.conf
#conf-dir=/etc/dnsmasq.d
# MKS 04-Oct-2016
conf-dir=/etc/dnsmasq.d

I am not familiar with “iptables firewall” – where should I look?

[mkstreet]

I found this…

compteach@iepcomlabsrv:/etc$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[george1421]

@mkstreet Those lines in the dnsmasq.conf are safe one.

For iptables, if you key in iptables -L you should either get a response back like I don’t know what you are talking about or it should show you 3 filters with accept. If your iptables output looks like this one you have iptables turned on. The content isn’t important just if you see rules in there other than allow you need to disable iptables.

hain INPUT (policy DROP)
target     prot opt source               destination         
ufw-before-logging-input  all  --  anywhere             anywhere            
ufw-before-input  all  --  anywhere             anywhere            
ufw-after-input  all  --  anywhere             anywhere            
ufw-after-logging-input  all  --  anywhere             anywhere            
ufw-reject-input  all  --  anywhere             anywhere            
ufw-track-input  all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ufw-before-logging-forward  all  --  anywhere             anywhere            
ufw-before-forward  all  --  anywhere             anywhere            
ufw-after-forward  all  --  anywhere             anywhere            
ufw-after-logging-forward  all  --  anywhere             anywhere            
ufw-reject-forward  all  --  anywhere             anywhere            
ufw-track-forward  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ufw-before-logging-output  all  --  anywhere             anywhere            
ufw-before-output  all  --  anywhere             anywhere            
ufw-after-output  all  --  anywhere             anywhere            
ufw-after-logging-output  all  --  anywhere             anywhere            

[george1421]

@mkstreet Ok then iptables is disabled. I’m looking over your previous pcap file now.

This should be working!!

[george1421]

@george1421 Can you confirm that the dhcpProxy service is running on port 4011.

netstat -an|grep 4011

You should see an output like:

udp        0      0 0.0.0.0:4011            0.0.0.0:*   

[george1421]

@george1421 I’m seeing the same thing as Sebastian saw. Let me check a pcap file I captured the other day.

This is very strange indeed. Our configurations are basically the same, except I’m running the latest version of dnsmasq to test uefi booting. In my pcap dnsmasq is sending out its IP addresss in the dhcp offer for next server, but in yours its not sending out the next server address at all. This is the only difference. Plus after the ACK from my main dhcp server (soho router) the target computer connects to the dhcpProxy port and then download the boot file.

[mkstreet]

@george1421

I did some experimenting and noticed this anomaly.

The Fog server and the host I want to load are on two switches which are connected together.
When I attach the Ethernet cable to the outside LAN / Internet to one of those switches, then I get the behavior as noted. Meaning the DHCP gets answered but when I press F8 to network boot, I get the PXE-E78 error.

When I disconnect that cable to the outside, then the PC I want to load can no longer find the DHCP. So something external to the LAB must be helping get the initial requests to 10.0.253.24 ?

[mkstreet]

@george1421

compteach@iepcomlabsrv:~$ netstat -an|grep 4011
udp        0      0 0.0.0.0:4011            0.0.0.0:*
compteach@iepcomlabsrv:~$

[george1421]

@mkstreet said in PXE-E78 Cannot locate boot server:

@george1421

When I disconnect that cable to the outside, then the PC I want to load can no longer find the DHCP. So something external to the LAB must be helping get the initial requests to 10.0.253.24 ?

This I understand. Since dnsmasq is not providing dhcp services for you, its only providing dhcpProxy services (filling in the gaps left out by your main dhcp server). What is strange is that your main dhcp server is sending out itself as the next server. I simply can’t understand why its not working here. It SHOULD BE WORKING.

TBH right now I’m at a loss, on where to turn next everything should be working. If you can disable the dhcp relay in your router (10.0.253.1) for 10.0.253.0 subnet then you can have the fog server with isc dhcp enabled supply the IP address (then also dnsmasq is not needed) or on your router (10.0.253.1) add yor dnsmasq server as the last dhcp server in its list. But this is starting to get messy.

The only other thing is to see if you can get your main dhcp server to NOT send out dhcp option 66 {next-server}. But its not clear if this will fix the issue either.

[mkstreet]

@george1421

Hmmm… If I understand this correctly, then I cannot disable dhcp relay within 10.0.253.1 as other hardware in this subnet but outside my lab would still need dhcp service for other purposes.
And, as you say, this path is getting messy.

As for changing the main dhcp option 66, I could try to request this. Would this affect only my subnet or our whole facility? My lab is about 90% of my subnet, but the main dhcp is servicing the whole campus which is comprised of several subnets… If the option 66 will affect others outside my area, then it is hard for me to do.

I am setting up the new version of FOG etc under VirtualBox. I think I will complete that, as it is a new clean install. I will see if this clean start resolves anything, as opposed to this – attempting to add DNSMASQ to an existing setup that (was) working.

[Sebastian Roth]

@mkstreet I understand that it is hard or maybe impossible to change the config of that 10.0.253.1 server. As you said dnsmasq can be used for exactly this purpose. So let’s give it another go. I’d say dnsmasq is answering faster as the other server as it is located right within your subnet. The PCAP output kind of proofs this. 10.0.253.24 answered 0.5 seconds before 10.0.253.1 did. So that’s good!
Then we only need to offer the correct PXE information to the client in one single DHCP answer. This is next-server and filename. Please modify the following line in your config and add the server IP as shown:

dhcp-boot=undionly.kpxe, 10.0.253.24, 10.0.253.24
pxe-service=X86PC, "Boot from network", undionly, 10.0.253.24

The later one shouldn’t be used but setting this correctly doesn’t hurt I’d say. Please take another PCAP capture to see if the next-server info is now being sent by dnsmasq.

[edit] I just saw that the information in the wiki page does not set those adresses. I haven’t played with dnsmasq in a while so this is just a quick idea. It’s kind of strange that you get an answer from dnsmasq that does not have next-server set… [/edit]

[Sebastian Roth]

I just had a look at the dnsmasq code (version 2.68-1ubuntu0.1 used in Ubuntu 14.04) and found that from the initially posted log output it seems like next-server (mess->siaddr.s_addr in the code) is actuelly not being set. Now I know what’s going on I think. If I remember correctly dnsmasq in proxy mode does not have to send the next-server information in the first DHCP answer (reply to the first DHCP discovery request). The client knows that there is a DHCP proxy server as it got a first quick message (only containing the filename) and should contact that server (port 4011) after finishing the normal DHCP handshake to setup an IP.

In your case the next-server information sent by 10.0.253.1 is most probably interfering and confusing the client. I guess I need to think a little more about this to find a good solution… Maybe George has an idea.

[george1421]

@Sebastian-Roth I think I like your first suggestion, updating the config file with the additional IP references:

dhcp-boot=undionly.kpxe, 10.0.253.24, 10.0.253.24
pxe-service=X86PC, "Boot from network", undionly, 10.0.253.24

If that fails, get another pcap file of the booting process to let us see what changed in the conversation.

The second though is that Wow, for ubuntu dnsmasq of 2.68 that was released 08-Dec-2013, where most of the distros are at 2.72. If this doesn’t work I can setup a ubuntu VM and compile the latest version of dnsmasq to see if that helps. But before I go through that effort lets see if your edits work.

[Tom Elliott]

@mkstreet Comment the port=0 line of your ltsp.conf file and restart dnsmasq.