Unable to Get Bootfile during PXE Boot
-
Hi. Like the title says I am unable to get a bootfile when booting a computer through PXE boot. It looks like the computer is able to grab the IP from DHCP but doesn’t get any further than that. Our network already has a DHCP and DNS server that I do not have access to and the network admins did not want to setup an IP helper address or modify the DHCP to point to FOG. I followed the steps in this article to setup a proxy DHCP https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq but after configuring that I still receive the above error.
dnsmasq service is on version 2.86 and is actively running. I was able to successfully connect to the TFTP server from my workstation PC. Here is the conf file from /etc/dnsmasq.d/ltsp.conf.
#dont function as a dns server
port=0#Log lots of extra info about DHCP transactions.
log-dhcp#Set the root directory for files available via ftp.
tftp-root=/tftpboot#The boot filename
dhcp-boot=undionly.kpxe,10.163.97.121#Disable re-use of the dhcp servername and filename fields
dhcp-no-override#inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009#set the boot file name based on the matching tag from the vendor class above
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,10.163.97.121
dhcp-boot=net:UEFI,ipxe.efi,10.163.97.121
dhcp-boot=net:UEFI64,ipxe.efi,10.163.97.121#pxe menu. the first part is text displayed to the user. The second is the tim>
pxe-prompt=“Booting FOG Client”, 1#The known types are x86PC, PC98, IA 64_EFI, Alpha, Arc_x86
#Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_efi and X86-64_EFI
#This option is first anf will be the default if there is no input from the us>
pxe-service=X86PC, “Boot to FOG”, undionly.kpxe
pxe-service=X86-64_EFI, “Boot to FOG UEFI”, ipxe.efi
pxe-service=BC_EFI, “Boot to FOG UEFI PXE-BC”, ipxe.efidhcp-range=10.163.97.121,proxy
Both the FOG server and target machine are attached to the same non-managed switch and should be within the same subnet. Is there anythingI am missing or did not configure correctly. Any help would be appreciated.
-
@smaxbang Lets start out by making sure that you restart the dnsmasq service after updating the config file. I didn’t go line by line but the ltsp.conf file looks complete.
systemctl restart dnsmasqshould restart dnsmasq.ps aux|grep dnsmasqshould show that dnsmask is running in memory.If dnsmasq checks out then lets grab a pcap to what the target computer is being told during pxe boot.
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
You can review the output.pcap with wireshark. You should see the DISCOVER packet from the target computer and then (2) OFFER packets. One will be from your main dhcp server and the second one should be from DNSMASQ on the FOG server. If you only see one OFFER packet then that is going to be a problem.
Next you will see a REQUEST from the target computer, and then an ACK/NAK from the target computer.
Next you should see the target computer reach out to the FOG server on port 4011 (this is the proxydhcp communications). After the target computer talks to dnsmasq then you should see the target computer contact the fog server using the tftp protocol to download the requested file.
If you can’t figure it out post the pcap to a file share site and either post the link here or DM me the link using FOG chat and I will take a look at the pcap.
-
@george1421 Great! Thanks so much I will do that now and update as soon as I can.
-
@george1421 Thank you for your help. I restarted dnsmasq again.
Here is the output from the ps aux|grep dnsmasq command:
dnsmasq 217786 0.0 0.0 10248 384 ? S 15:56 0:00 /usr/sbin/dnsmasq
oracle 222748 0.0 0.0 6380 2188 pts/0 S+ 17:13 0:00 grep --color=auto dnsmasq
I then ran a capture with tcpdump according to the link you sent. When viewing in Packet Tracer I can see the DHCP discover packet going out it receives two DHCP offer packets back however these both come from the DHCP relay address (10.163.96.3) and not my FOG server (10.163.97.121). We have two subnets in our building for our general data VLAN and clients can have IPs in the 10.163.96.0/24 range and 10.163.97.0/25 range.
This pattern of discover packets and offer packets repeats a few more times before the error is encountered. None of the offer packets come from the FOG server. Would this indicate that there is some issue with dnsmasq not responding properly to the initial Discover packet? Please let me know if you need any additional information I can also send the capture file if you would like to inspect them more closely.
-
@smaxbang I agree with your assessment in that dnsmasq is not hearing the dhcp the discover packet. The FOG server IS seeing it or you wouldn’t see the discover packet in the pcap (why I wanted you to run tcpdump/wireshark on the fog server to see what the fog server sees).
I would think then there is a configuration issue with dnsmasq, because the OS sees the DISCOVER because tcpdump sees the DISCOVER.
Now for the computers on a different subnet that is easy. On your firewall/vlan router you are running a service called dhcp-relay or dhcp-helper. That service lists your dhcp servers, you need to add the fog server as the last IP address in the dhcp relay list. That will tell the vlan router to send the discover packets to the FOG server like it does the main dhcp server. Once that is done then the FOG server will respond to the other subnets.
-
@george1421 Thank you for your help. I managed to speak with one of the techs from our central IT this morning. He informed me that they block PXE boot on our network. PXE traffic is automatically being filtered and dropped by the switches. I think it is unlikely that they would add my FOG server to the DHCP relay. Which makes sense I was only able to get tcpdump to see the discover traffic when I connected both machines to their own unmanaged switch.
Still not sure why dnsmasq did not respond to the DISCOVER packet. I will try reinstalling the service. Although following this revelation I may just reconfigure FOG to run DHCP and use it on its own isolated network. Thank you!
