TFTP error - timeout
-
Does restarting the TFTP service have any effect?
[CODE]
sudo restart tftpd-hpa
[/CODE] -
[quote=“Tom Elliott, post: 38412, member: 7271”]Did you set your dhcp server’s option 66/next-server (ip) and option 67/filename (undionly.kpxe)?[/quote]
Yes I do have these options set properly. The odd thing is, if I change the next ip to my old server and change the file name from the undionly.kpxe to the pxelinux.0 file everything works fine with the old server.
[quote=“ArchFan, post: 38414, member: 19266”]Does restarting the TFTP service have any effect?
[CODE]
sudo restart tftpd-hpa
[/CODE][/quote]At first I was gettig the TFTP Error: Open Time Out error. Stopping and restarting the service corrected this issue and it now opens the connection, but the file not found error comes up.
Thanks and keep them coming. I appreciate the help.
-
[quote=“Corey, post: 38417, member: 1201”]Yes I do have these options set properly. The odd thing is, if I change the next ip to my old server and change the file name from the undionly.kpxe to the pxelinux.0 file everything works fine with the old server.
At first I was gettig the TFTP Error: Open Time Out error. Stopping and restarting the service corrected this issue and it now opens the connection, but the file not found error comes up.
Thanks and keep them coming. I appreciate the help.[/quote]
Are you setting the options per subnet or at the server level? I’ve heard of similar problems if you’ve only setup for the “global” setting rather than specifying at the subnet level.
Also, can you ensure your firewall is turned off? While I realize your command line tftp is successful, it still seems awfully suspicious that it’s only when the options are set to the new server that you’re having issues. Another, quick, test, would be to maybe ensure tftp is correct by removing the /var/lib/tftp folder and creating a symlink to it:
[code]sudo ufw disable #disables firewall.
sudo rm -rf /var/lib/tftp
sudo ln -s /tftpboot /var/lib/tftp[/code] -
[quote=“Tom Elliott, post: 38419, member: 7271”]Are you setting the options per subnet or at the server level? I’ve heard of similar problems if you’ve only setup for the “global” setting rather than specifying at the subnet level.[/quote]
I am specifying it at a global level.
[quote=“Tom Elliott, post: 38419, member: 7271”]Another, quick, test, would be to maybe ensure tftp is correct by removing the /var/lib/tftp folder and creating a symlink to it:
[code]sudo ufw disable #disables firewall.
sudo rm -rf /var/lib/tftp
sudo ln -s /tftpboot /var/lib/tftp[/code][/quote]I will try this and get back to you, but one question… If it was a firewall issue, would my tftp attempt from a command prompt on a windows machines still be succesful? It is always succesful, well, since I fixed the open timout issue that was ocurring anyway.
Thanks for the ideas, will post as soon as I have more information.
-
I just realized you want me to run the ufw command, is that a Debian command?
I had tried that back when I was fooling with Ubuntu 14.04, but have not tried it since moving to Debian 7.7. Hopefully that was my misunderstanding and that will fix my issues.
Again, thanks for the time so far, I really appreciate it.
-
Ok, so I have run those three commands, the two rm/ln commands passed whilie the ufw was unrecognized. I do remember that I exec’d the following commands already on this Debian install from my previous research on wiki…
[CODE]iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT[/CODE]I am looking into the DHCP server options, per vlan now, as you had mentioned earlier.
Thanks,
-
Haha, Tom you are a savior. Upon further review of the DHCP options I have found my problem. I have a global setting on the DHCP, but apparently either a) MS auto copies that rule into each subnet, or b) I set up the rule for each subnet individuall when I stood the first server up and don’t remember doing it.
Either way, I went to the particular vlan I was working with and found its own set of 66/67 rules there. I made them match the new servers information and presto, it worked.
Now I can continue working with some of my testing. I may come back for assistance on getting these newer NIC cards working on this system IF I have trouble with it. I am hoping that the newer server version will straighten all of that out though…
Again thanks for kicking that ‘ah-ha’ moment out of me everyone.
Will keep you posted.
-
FYI, so far the newer version of fog (1.2) on Debian 7.7 has corrected many of my incompatible hardware issues right out of the box.
Wonderful community work everyone. Special thanks to you Tom.
-
I hate to chime in all after the dust cleared but we have had a wiki article that would have helped you today.
[url]http://fogproject.org/wiki/index.php/Tftp_timeout[/url]…
-
Oh I know. I followed that wiki to the T for both Ubuntu 14.04 and Debian 7.7, and I was still having issues. So it really didn’t help me directly, although it was a good reference point for confirming the dhcp options as well as the commands to disable the firewall in Debian.
The underlying problem was that there were individual DHCP options set for a couple of our VLANs, but not all of the Vlans. So they were over riding the global options that I was working with.
I don’t expect the wiki to delve into Windows based DHCP management, but might be worth a line around the DHCP section, that explains…
“It is possible to have these options configured on your DHCP server per subnet/vlan. So make sure there is no conflicting information in the specific subnet you are working in.”Until it was mentioned in the post regarding DHCP settings per subnet, I didn’t have a clue that was even possible. Now that I know, I have actually configured the old .32 server on a specific maint vlan and the new machine on the production vlan, so our technicians can still access the older images in an emergency.
Thanks again for the feedback though. I appreciate it.
