TFTP Open Timeout Issues
-
Hey All,
I am getting a TFTP Open timeout error and it is making me spin my wheels. I am running Ubuntu 16.04.3 LTS with FOG 1.5.0. On 2 of my sites, it works beautifully except for the high school and it is almost like it isn’t pulling the file.
Per the instructions on the TFTP open timeout troubleshooting, I have testing tftp from my windows laptop and I was able to download the undionly.kpxe file and I was also able to do it from the FOG server.
I have also set the chmod R 777 for the /tftpboot folder and that hasn’t done anything either.
I am running these computers on Cisco Switches and spanning-tree portfast is enabled on the port. So are some other security features like bpduguard and things like that. I don’t know if that has anything to do with it or not.
Any help would be much appreciated!
-
Does your network use Windows dhcp? If so is this scope defined to use that storage node and file name?
-
@tom-elliott Yes sir. Options 66 and 67 are set to the IP address of the FOG server and the undionly.kpxe
-
@chris-whiteley Is your fog server and target (pxe booting) computer on the same subnet?
-
@george1421 No they are not, they are on different subnets, but the other schools are as well and they don’t have this issue
-
@chris-whiteley For the ease of debugging it would be helpful to have them on the same subnet. We have a document for debugging pxe booting using the fog server: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
But in your case since the target computers are on a different subnet the fog server can’t spy on the entire conversation. So in your case you will need to take a computer on the same subnet as the (non)pxe booting computer and install wireshark on it. Then setup a capture filter of
port 67 or port 68, then launch the target computer to pxe boot. This will watch the dhcp dialog. What will be interesting is the “offer” response from the dhcp server. If you don’t know what you are looking for in the dhcp process upload the pcap to a google drive and IM me the link. I’ll take a look at it to see if the dhcp server is sending the right information.If that bit is good then we will need to run a pcap on the fog server to see that side of the conversation.
-
@george1421 That is unfortunately not possible. The way our network is setup, this school is one of the many that we take care. We have 2 routers in the fold and one is a virtualized pfsense that has this “servers (fog being one of them) vlan” that is routed from their firewall to us. The other router is sitting right here in the next room where I am. This router points to the other to see that “server vlan”.
I know this sounds confusing, but it is only a virtualized VLAN we use for VSphere as this FOG server is Virtual.
-
@george1421 and I should say…it isn’t impossible, but it wouldn’t be very fun to setup I guess
-
@chris-whiteley I think we have a disconnect somewhere (remember I’m trying to visualize how you have things setup).
We need to get a monitoring computer on the same vlan as the computer that will not pxe boot. Typically when we debug this, we will take a laptop with wireshark installed to the remote site and plug it into the same vlan as the failing to boot computer. Start wireshark and then try to pxe boot the target computer. Once the target computer fails to boot, stop the pcap and look at what is collected.
This is not possible to do?
-
@george1421 I think we did have our wires crossed
I will go ahead and set this up right now. Since I won’t be good at reading it correctly, where could I send it? -
@chris-whiteley Upload to a google drive / dropbox and IM me the link
Make sure you use the capture filter I posted so we don’t get extra stuff I should not see.
-
@george1421 That is sent to you. Let me know what you find.
Thanks,