TFTP: File Not Found

[Scott B]

When booting pxe I’ve started getting a file not found message. No changes have been made to the DHCP servers that I’m aware of, and only an SVN update to FOG (currently 6911 on Ubuntu 14.04) and I see undionly.kpxe in the tftpboot directory. Rights to undionly.kpxe are 664. Owner fog:root. Any ideas?

[Tom Elliott]

It’s most likely nothing to do with FOG as it’s not even getting to the point of requesting a file, from what I can see. That or the FOG Server doesn’t have tftp running?

[Scott B]

@Tom-Elliott said:

It’s most likely nothing to do with FOG as it’s not even getting to the point of requesting a file, from what I can see. That or the FOG Server doesn’t have tftp running?

tftpd-hpa service shows running. I tried restarting it as well. Checked in fog’s web gui and the user and password listed for fog tftp are correct.

[Tom Elliott]

@Scott-B FOG Tftp has nothing to do with tftp running or not.

Can you tftp a file to the system? THE FOG_TFTP stuff in fogsettings of from the time where fog was using pure pxelinux.0 as the boot file. These options were what was used for kernel updates and pushing the task file to the server telling the host to boot. More or less these fields could now be erradicated entirely, but I still use them for kernel updating.

Can you try this: manually?

sudo service xinetd stop
sleep 2
sudo service xinetd start
sleep 2
sudo service tftpd-hpa stop
sleep 2
sudo service tftpd-hpa start

[Scott B]

@Tom-Elliott

I get a “timeout occurred. connect request failed.” when I try to send a file manually. Same if I try to get a file as well.

[Sebastian Roth]

Maybe you upgraded the system as well. Possibly enabling the firewall??

[Scott B]

@Sebastian-Roth said:

Maybe you upgraded the system as well. Possibly enabling the firewall??

I can tftp a file directly from the server console so its at least running. The only firewall on the system is ufw (Uncomplicated Firewall) but its disabled on start and is not running on the system.

[Quazz]

@Scott-B Could you check on a non-VM machine if it works? I’m not overly familiar with VM but I do know VM’s can be weird with PXE sometimes, they’re particularily picky with what network adapter will work.

[Scott B]

@Quazz said:

@Scott-B Could you check on a non-VM machine if it works? I’m not overly familiar with VM but I do know VM’s can be weird with PXE sometimes, they’re particularly picky with what network adapter will work.

I’ve tried on both physical and vm devices.

[Quazz]

@Scott-B What does your /etc/default/tftpd-hpa file look like?

[Wayne Workman]

@Scott-B said:

I can tftp a file directly from the server console so its at least running. The only firewall on the system is ufw (Uncomplicated Firewall) but its disabled on start and is not running on the system.

Because you can get the files via TFTP from the local server, it’s firewall or network related. And you say the firewall is disabled so… it’s network related probably.

Could it be an IP conflict, for either this host or the fog server?

Do you have a network hub (as opposed to a switch)? You could use that to do a capture with wireshark on a test computer. you could also do a capture on the FOG server. To really figure out what is going on, we need to see what’s going across the lines.

[Scott B]

@Quazz said:

@Scott-B What does your /etc/default/tftpd-hpa file look like?

# /etc/default/tftpd-hpa
# FOG Modified version
TFTP_USERNAME="root"
TFTP_DIRECTORY="/tftpboot"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="-s"

[Sebastian Roth]

My guess it’s firewall… iptables -L -n -v

[Scott B]

@Sebastian-Roth said:

My guess it’s firewall… iptables -L -n -v

root@FOG:~# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

[Scott B]

/var/log/syslog show the messages below.

Mar 24 07:52:26 FOG in.tftpd[29283]: tftp: client does not accept options
Mar 24 08:03:59 FOG in.tftpd[29827]: tftp: client does not accept options
Mar 24 08:09:01 FOG CRON[30159]: (root) CMD (  [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean)
Mar 24 08:16:10 FOG in.tftpd[30432]: tftp: client does not accept options
Mar 24 08:17:01 FOG CRON[30490]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Mar 24 08:39:01 FOG CRON[31690]: (root) CMD (  [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean)
Mar 24 08:44:49 FOG in.tftpd[31921]: tftp: client does not accept options
Mar 24 09:01:08 FOG kernel: [73741.076609] ip_tables: (C) 2000-2006 Netfilter Core Team
Mar 24 09:09:01 FOG CRON[911]: (root) CMD (  [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean)
Mar 24 09:17:01 FOG CRON[1629]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

I also checked the firewall

root@FOG:~# ufw status
Status: inactive

[Sebastian Roth]

@Scott-B said:

Mar 24 08:44:49 FOG in.tftpd[31921]: tftp: client does not accept options

You can safely ignore this. It’s just a notice and does not prevent the client from downloading binaries via TFTP! I guess this message in the log came up when you tried tftp from the server console, right?? Please try again from the server and remote and see when you get the message in the logs.

Other than that I am kind of lost with this. Have you double/triple checked the IP addresses? Are you able to ping both ways (client which you test tftp from and FOG server)??

[Scott B]

@Sebastian-Roth said:

@Scott-B said:

Mar 24 08:44:49 FOG in.tftpd[31921]: tftp: client does not accept options

You can safely ignore this. It’s just a notice and does not prevent the client from downloading binaries via TFTP! I guess this message in the log came up when you tried tftp from the server console, right?? Please try again from the server and remote and see when you get the message in the logs.

Other than that I am kind of lost with this. Have you double/triple checked the IP addresses? Are you able to ping both ways (client which you test tftp from and FOG server)??

I was able to tftp a file from the console, I was trailing the syslog at the time and did not see the message again. I can ping both ways without issue.

[Wayne Workman]

@Scott-B The idea with troubleshooting when you don’t know what’s going on is just to start trying stuff. A lot of stuff. Write down notes about what you tried and if it worked or not. And while your doing all these ‘things’, your looking for messages and clues anywhere and everywhere.

Try a WOL.
Try an image capture
Try an image deploy
Try a snapin
Try pinging.
Try a packet capture while you try to do an image deploy.
Make sure the patch cable connections are snug on the server.
Try a new patch cable.
Is there a typo in your DHCP option 066 or 067 ???
Install FOG with DHCP, then take it off the network and connect it to just a mini-switch / hub, and then connect a target host to that and try imaging. Does it work?

[Sebastian Roth]

@Scott-B Wanna chat? See in the top right corner of this site…

[Sebastian Roth]

Ok, we did a tcpdump session on the FOG server and we see that the TFTP request from the client as well as the first TFTP answer packet leaving the server (but probably never making it to the client). While ping is working!! So the only two things (more or less one really) I can think of is access rules on the switches or firewall rules on the VM host (test client is running on a VWware host)… definitely not a FOG issue.