PXE-E32 error with Realtek 8169
-
[COLOR=#141414][FONT=Tahoma]I originally posted in the Developers forum in the help section, I’m not sure where this post should be since it is not FOG nor Windows related.[/FONT][/COLOR]
[COLOR=#141414][FONT=Tahoma]I have a computer lab with 26 AcerPower S285 with a Realtek RTL 8169/8110 Family Gigabit Ethernet NIC. I can see my FOG server by logging in using a web browser. When I set it up to PXE boot I get an PXE-E32: TFTP open timeout. I installed an old 3com 3c905 pci NIC and was able to PXE boot. How can I get the Realtek adapters to work? [/FONT][/COLOR]
[COLOR=#141414][FONT=Tahoma]I first installed Ubuntu 12 with FOG 0.32 and got the error. I installed Ubutu 10.04 and FOG 0.32 and still got the error. FOG is working with classroom computers that are HP’s and library computers that are AcerPower FH that have a Generic Marvell Yukon Chipset based Ethernet Controller. [/FONT][/COLOR]
[COLOR=#141414][FONT=Tahoma]I wonder if the Realtek running at Gigabit speeds is too fast? I paused the PXE boot when DHCP started and waited 1 minute before resuming boot, but no joy.[/FONT][/COLOR] -
It may be a problem with the firmware on those cards. I have about 30 rebranded Compal JHL91 laptops and 270 Acer Iconia Tab w500p tablets. These two models of devices do not PXE boot properly by setting DHCP with the server and filename options. They would give me a tftp: file not found.
I installed WireShark (and WinPCap included) on a machine and setup my switch to let me monitor the port the problematic machines were plugged into. I found that when these machines booted to PXE, they would get the IP of the fog server and the name of the bootfile (pxelinux.0) but would fail when making the TFTP read request.
If you have access to the switch config, download a copy of WireShark (free on Linux and Windows) and investigate what’s going on during the PXE boot and TFTP initial transfer.
[B]Tip: [/B]Start your packet capture as the problematic computer boots and stop it right after you get the error. Then use filter: “not arp and not http and not snmp” in WireShark and look for UDP messages related to DHCP. The first should be a DHCPDiscover, then a DHCPRequest, followed by a DHCPAck.
If you look at the lines for DHCP, pay attention to the Bootp section in the data window.
Let’s see exactly where the failure is before we offer solutions.