• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    PXE-E32 Error on Client Startup

    Scheduled Pinned Locked Moved Solved
    FOG Problems
    2
    5
    1.2k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      david.gage
      last edited by

      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!

      1 Reply Last reply Reply Quote 0
      • george1421G
        george1421 Moderator
        last edited by

        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.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

        1 Reply Last reply Reply Quote 0
        • D
          david.gage
          last edited by

          Here’s the pcap file.
          0_1525447859731_output.pcap

          george1421G 1 Reply Last reply Reply Quote 0
          • george1421G
            george1421 Moderator @david.gage
            last edited by

            @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.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

            1 Reply Last reply Reply Quote 1
            • D
              david.gage
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • 1 / 1
              • First post
                Last post

              180

              Online

              12.1k

              Users

              17.3k

              Topics

              155.3k

              Posts
              Copyright © 2012-2024 FOG Project