• Moderator

    @NTex I really need to see the pcap from the witness computer at the remote site. The whole pcap and not just screen shots. We need to identify what the server is presenting itself as. (dhcp option 94 [I think]) and who the actors are in the dhcp OFFER. The 4 packet DHCP sequence is important as well as what the target computer does after it gets the ACK from the dhcp server.

  • @george1421

    Hello again,

    I actually done both (WAN and Fog) in past, but never done on mirror way, this is good idea.

    I use Meraki location, since has a capture tool, it’s very good.
    On the WAN side, I capture all traffic for host DHCP IP and on Fog Server the ports mentioned.

    It actually loop for while and can take sometime to finally give up on loop and time-out, so I set it as 180 seconds on both ends.

    There was once took 30 mins to finally give up.
    The screenshot will show you … like not loading.
    Usual behavior, is the use graphical representation of pipes and slashes while loading PXE bootfile, instead of …

    Attached screenshot from iLO that gives me the view / control on the client:
    alt text

    I attached both captures.
    Fog Server Capture
    WAN Side / Server

    I’m really curious to see, if you can discover the reason on these specific servers, even if I can’t solve it remotely for some odd reason.

    I’m not used to not get some the answers, I always like to find why something doesn’t work like how it should work.

    Thanks for everything.

    PS - Edit uploading on forums doesn’t seem to be working for me, throwing “Something went wrong while parsing server response”, hold let me fix it.

  • Moderator

    @NTex Ok what I would like to see is a pcap (packet capture) of the pxe booting process on these computers that are failing.

    The witness computer needs to be on the same subnet as the failing server. Ideally if you can swing a mirror port that would give us the best quality of the pcap. If you can’t then on the same subnet will work. I need a pcap for this witness computer to use this wireshark capture filter port 67 or port 68 or port 69 That will ensure we only get pxe booting packets and not any incidental packets with information you shouldn’t share.

    If you can’t use a mirror port then at the same time run the pcap defined in this tutorial on the FOG server. This will give us the tftp side of the booting process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

    Upload the pcap to this forum or to a file share site, share as public with the link. You can either post the link here or DM me the link using the FOG Forum chat function. I’ll take a look at the pcap and see if I can find why these are not booting.

    It would also be helpful to grab a screen shot of the error on the server’s console when the boot fails.

  • @george1421

    Yes, you understood correctly.
    Different locations, we did like around 200 migrations, with no issue whatsoever. These locations all have the same template.

    All other servers boots fine on this specific model and all other models, even some recent Lenovo, I have no issues.

    I also tried to run tftp command from the actual server while inside the OS shell, it download the PXE file from our Fog server, no problem.

    This happens only when we try to PXE boot those.

    I have some Windows workstations on all these subnets I can use, only

    One site I have MX Meraki those have a incorporated Wireshark as tool, which I can save it too.


  • This post is deleted!
  • Moderator

    OK so if I understand this you only have 4 of this specific model that won’t pxe boot. I take it that these 4 servers are on the opposite end of the mpls link as the FOG server? Is this correct?

    If it is do you have a witness (second computer at the remote site) computer that we can use for packet capture? This can be another linux computer or windows computers on the same subnet as the pxe booting computer.