PXE-E32 Error on Client Startup



  • Hello all,
    I’m sorry to beat this dead horse, but we’re at a loss on what is missing or possibly misconfigured. We recently setup FOG 1.5.2 on Ubuntu 16.04.4 on a VM “server”. When attempting to PXE boot a standalone client systems, I get a “PXE-E32: TFTP open timeout” error. We’ve followed the fog wiki on the config, checked other sites and suggestions, even tried the “well maybe if we ****.” but so far still not able to get to the Fog menu from the client system.

    We modified our DHCP (running on our Palo Alto firewall) with the following:
    0_1525387603401_fdc37f31-f484-4bf8-8116-43950d3602ef-image.png

    0_1525387670998_9737ca41-2783-4b1d-98e4-5aed63c9dd60-image.png

    From multiple desktops, I can ping the server and can “tftp –i 192.168.1.16 get undionly.kpxe”.

    I have followed several checklists, but cannot figure out what about the config won’t allow the tftp connection.

    Any suggestions on what to check/try next? Please let me know if there’s any further information needed.
    I’m out of ideas or been looking so close at the same thing that I’m missing something glaringly obvious.

    Any help is greatly appreciated!



  • Any idea what the output shows? From what I can read, the Fog Server is seeing the request come in but I don’t have the experience enough to garner further support knowledge.

    Thanx for the advice on the DNSMASQ. I’ll talk to my seniors about installing/configuring that hopefully this week.


  • Moderator

    @david-gage Well this pcap isn’t telling me what I need to know. You executed the steps perfectly, so its not what you did. It looks like your dhcp server is sending out responses using unicast messages which can’t be captured using tcp dump. This is the second pcap today that had this strange behavior.

    If you look at the pcap you uploaded. You will see only the pxe booting client’s side of the conversation. You see a Discovery and a Request packet. What is missing is the response from the dhcp server of Offer and ACK. The Offer packet is what we are really interested in. In that packet it tells the pxe booting client what boot file to download.

    I know the dhcp process is working because the client is sending out a Request packet, because that is in response to an Offer from a dhcp server.

    Does your network team have the ability to mirror the pxe booting clients network port to the port where your FOG server is or setup a computer with wireshark and mirror to that port. Port mirroring is a function of the network switch. On a mirrored port all data is echoed to the receiving port. This way you can monitor both normal broadcasts as well as unicast messages.



  • Here’s the pcap file.
    0_1525447859731_output.pcap


  • Moderator

    If your fog server, dhcp server and pxe booting client are on the same subnet you should follow this guide to find out how to tell what is going wrong: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

    Also since you are using a firewall for your dhcp server, you might consider using dnsmasq running on the fog server to supply the boot information only. We are seeing that often a static dhcp server is not capable of supporting both bios and uefi based systems since they require different boot files. (undionly.kpxe vs ipxe.efi).

    Capture a pcap of the pxe booting process where it fails and then either upload the pcap to a google drive and IM me the link or post the link in the forum and I’ll take a look at it.


 

448
Online

41.9k
Users

12.4k
Topics

116.8k
Posts