FOG 1.4.2 TFTP Open Timeout
-
I recently installed a new FOG server (1.4.2). And I am running into a TFTP open timeout error. I am using Sophos for DCHP, and I can see when the PXE boot starts that the client gets an IP, and default gateway etc, so it looks to me like DHCP is working.
After that, I get a TFTP message that thinks for a while, and then it says “TFPT open timeout”
I have the 66 setting as the FOG server IP and 67 is set to undionly.kpxe is this correct?
I am running ubuntu 16 and I have the firewall disabled.
-
@cassie_280 Options 66 and 67 sound correct (no typo there, hmm??). Is the TFTP service running on the FOG server? Please run
netstat -antup | grep ":69"as root (sudo) on your server and post the output here. And just to make sure the firewall is properly disabled runiptables -Land post the results you get. -
Also make sure there are no extra white spaces before or after the undionly.kpxe prompt. We did see that happen once that caused the same error message.
If the fog server and pxe booting client are on the same subnet we might have you grab a pcap file to tell us what is actually being sent from your dhcp server. The instructions are here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Post the pcap file on a google drive or dropbox and share the link with either one of us by FOG Forum IM or just post the link here. You can pull down the files once we have a chance to look at them.
-
This post is deleted! -
Here is the output from the commands. I will work on getting the pcap file.
-
@cassie_280 the output of iptables is good, every rule is accept.
-
https://iuone-my.sharepoint.com/personal/cassie_shoemaker_iu1_org/_layouts/15/guestaccess.aspx?docid=1fcce189f5a84460b89f9d1869eed1dfc&authkey=AS-aXf2IT4Mx4iZREG9e3wE Here is the output tcpdump
-
@cassie_280 The packet dump is definitely helpful. It looks a bit crooked though. I see several DHCP requests and DHCP discoveries from different clients but only one pair of DHCP offer and DHCP ACK. Looking at the later two I can see it pointing to x.x.1.2 which probably is your (new?) FOG server but options 67 is
pxelinux.0which might not exist on the TFTP server (dir/tftpbooton your FOG server) and it would cause trouble anyway. So make sure you set option 67 toundionly.kpxeon your Sophos box.Did you use the syntax
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011to capture this? What makes me wonder is that I don’t see any TFTP data (port 69) in that packet dump…?? -
I agree with Sebastian, this pcap looks a bit wonky. But it does tell us a little bit of what is going on.
I will try to decode the pcap in human terms.
- You have a hp computer that is pxe booting
- The dhcp server 10.3.1.1 has responded giving the pxe booting clinet an ip address of 10.3.132.110 / 255.255.0.0
- It has sent dhcp option 66 of 10.3.1.2 and dhco option 67 of pxelinux.0 (<< this is A issue)
- Second issue is that your dhcp server appears non-standard since it didn’t include the boot server or boot file in the ethernet header. This may not be an issue, its just a bit strange.
- The rest of the dhcp process looks OK.
What I find strange is if you used the tcpdump command from the FOG server and the fog server is at 10.3.1.2 AND you use the tcpdump command that was provided in the tutorial or the one Sebastian posted, we are not seeing the request from the client to the FOG server for pxelinux.0 (which is the wrong boot file). This would be the next logical step for the pxe booting client.
So based on what I saw so far I have these questions.
- Is your fog server at IP address 10.3.1.2?
- What device is 10.3.1.1 it appears to be running dhcp as well as dns services. Maybe a router? (edit: ok reading your OP again, its a sophos router/fiewall. If we can’t get it to send out the right information we can use the FOG server to supplement the missing info.)
- Why is the boot file set to pxelinux.0?
-
So I’ve been working with the guy that manages our sophos box and he made a few changes and it looks like we’ve made some progress (we had a global rule, but now we have a rule specific to our site) We are now getting past the TFTP timeout error, but I am receiving the following:
I took another packet capture which I will include below. I’ll also include the command that I used. Could this be any issue with the undionly.kpxe setting? He says that he doesn’t have the pxelinux.0 setting in sophos any more.
-
@cassie_280 Looking at your pcap file I would say its working as it should. I see your target computer 10.3.132.110 is requesting the file size of undionly.kpxe and then requests the file. So I find it strange you are getting that error.
Can you confirm that on your fog server that in /tftpboot/undionly.kpxe exists?
You can also test this by installing the tftp client feature on a windows computer, see if you can download undionly.kpxe.
If you can’t get it to work, we still have an option. Remove all pxe booting settings from your sophos firewall. We can have you install dnsmaq on your fog server to supply the missing pxe booting information. This is an alternate method when your dhcp server isn’t capable of supplying the right info.
-
My tftpboot folder is empty, which is weird. XD Does this mean that my FOG installation didn’t work properly?
-
@cassie_280 It likely means the install didn’t complete fully.
-
Can I just run the installer again on top of the current installation with the same commands?
-
@cassie_280 Yes, though you may have better luck using the
-yargument as well (Auto accept) -
@cassie_280 There is one step in the installer where it tells you to go to the web interface. This is not the end. You need to hit enter after that to proceed. Not to sound rude just wanted to make sure…
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 said in FOG 1.4.2 TFTP Open Timeout:
@cassie_280 There is one step in the installer where it tells you to go to the web interface. This is not the end. You need to hit enter after that to proceed. Not to sound rude just wanted to make sure…
I don’t know how many times I’ve reached that step and when to copy the url and hit ctrl-c to copy the url, which then aborted the install. So it does create a botched install. It does happen.
