Connection time out (4c0a6035)
-
Hi, I have been using a new install for a couple of months now and everything has been fine, for the most part. Recently I have been imagining a number of new PCs, and every now and again I come across one that won’t PXE boot correctly. I go through the FOG menu, and then when I select to Full Inventory it fails with the Could not boot: Connection timed out (http://ipxe.org/4c0a6035) error.
I have made sure FOG has the latest Kernel Update as I read that could be an issue, and have check ed the IP address is registered correctly etc, as per https://wiki.fogproject.org/wiki/index.php/Tftp_timeout…
I am running a Windows DHCP server, however all settings seem correct, especially as the vast majority of machines work just fine. Also, all of the machines I am imaging are identical models with sequential serial numbers.
I tried one that had previously failed and it worked, however another just keeps failing. I have also run a BIOS update on it. Is there any possible reason for FOG to cause this behavior, or is it most likely a machine issue on the odd ones that fail?
Thanks for any help!
-
@tlyneyor said in Connection time out (4c0a6035):
However unfortunately I am running through the imagine process and it is painfully slow. To the point where selecting the image and the group etc needed 3 or 4 attempts each, and it is currently downloading the image at around 50MB/min.
It screams network issue to me, but there are no other network problems at all that I can see, and I have run another machine in the same switch with no latency or connectivity problems.That sounds like it could be a duplicate IP. You’ll get a ton of slowness and intermittent transmissions with a duplicate IP.
-
@tlyneyor Two things come to mind:
- Bad patch cable. This could be a kink/loose wire/torn/bad connector/broken clip/stretched/etc.
- Funk in the chips. I’ve seen this only a couple times and when I have, it’s always been the same particular computers that have the issue. To fix, pull the power cable and then press the power button. This clears the funk from the BIOS chips and NIC chipset and can solve really weird pxe boot problems like this one.
-
@wayne-workman said in Connection time out (4c0a6035):
@tlyneyor Two things come to mind:
- Bad patch cable. This could be a kink/loose wire/torn/bad connector/broken clip/stretched/etc.
- Funk in the chips. I’ve seen this only a couple times and when I have, it’s always been the same particular computers that have the issue. To fix, pull the power cable and then press the power button. This clears the funk from the BIOS chips and NIC chipset and can solve really weird pxe boot problems like this one.
Hi, thanks for the reply!
Great shout on the patch cable - even though they have all been running on the same build station using the same cable, I swapped it out and at first I thought it had worked as it booted first time. However unfortunately I am running through the imagine process and it is painfully slow. To the point where selecting the image and the group etc needed 3 or 4 attempts each, and it is currently downloading the image at around 50MB/min.
It screams network issue to me, but there are no other network problems at all that I can see, and I have run another machine in the same switch with no latency or connectivity problems.
It certainly sounds like it could be a BIOS/chipset option so I will give the power button press a go next time - I hadn’t thought of trying that, thanks! -
@tlyneyor said in Connection time out (4c0a6035):
However unfortunately I am running through the imagine process and it is painfully slow. To the point where selecting the image and the group etc needed 3 or 4 attempts each, and it is currently downloading the image at around 50MB/min.
It screams network issue to me, but there are no other network problems at all that I can see, and I have run another machine in the same switch with no latency or connectivity problems.That sounds like it could be a duplicate IP. You’ll get a ton of slowness and intermittent transmissions with a duplicate IP.
-
@wayne-workman Wow, you are 100% correct, I never considered it just from those symptoms - thank you so much! There was a rogue device with a static IP within the DHCP range and it was clashing. Now I am going to search the whole network in case there are more. Thank you, that was driving me crazy!!!
-
@tlyneyor Glad I could help. I’ve seen duplicates a lot, so I’m really familiar and very weary of them.
An easy way to detect rogue DHCP services is to do a packet capture on a linux box while issuing the commands to release the current lease and get a new one:
dhclient -r; dhclient. In the packet capture, you would see the rogue DHCP server’s address and MAC address.Also, there is a way on Linux to check a specific IP address to see if there are duplicates:
arping -D -q -I eth0 -c 2 192.168.1.250 ; echo $?If you get a 0 back from that command, it means there are no duplicates. 1 or anything else that isn’t 0 means there are duplicates. Note thateth0in the command is the name of the interface you are using to send the request out of and192.168.1.250is the IP being tested. This does not need to be run on the affected computer, and probably should be executed on a normal-functioning system.
