NBP filesize is 0 Bytes; PXE-E18: Server response timeout
-
Hi all,
Just started randomly receiving this error while attempting to UEFI boot:NBP filesize is 0 Bytes; PXE-E18: Server response timeout
I have 3 DHCP servers that sync with each other but I haven’t changed any settings on them or the fog server. It just seemed to come out of nowhere. Any ideas?
Thanks!
-
@foggymind Quite often the DHCP sync is “out of sync”. Have you double checked?
-
@foggymind Are all three DHCP server, fog server and target computer on the same subnet? If not can you install wireshark on a witness computer (second computer on the same subnet as the pxe booting computer)? If so please run with a capture filter of
port 67 or port 68and then upload the contents to a file share site and post the link here. Ideally if you can capture the error being generated that would tell us what is broke. -
@george1421 Thanks for the quick reply! I’m waiting to hear back to see if our DHCP servers are in sync, but the fog server and client are both on the same subnet. I did check the configuration for 66/67 and they are correct on all three DHCP servers so I think everything is configured correctly it just seems like that TFTP service isn’t running for some reason or something is blocking it. This error happens when attempting UEFI boot, but I just tried a legacy PXE boot and the got the message PXE-E32 TFTP open timeout.
-
@foggymind Some background, both UEFI and legacy PXE were working fine before this.
-
@foggymind ok with the fog server and cleints on the same subnet we can get the fog server to listen in on the dhcp process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
This will capture the pxe booting process. Once captured you can load into wireshark or upload so one of us can look at it. What you want to look for is multiple OFFER packets. You should have one from each DHCP that hears the clients DISCOVER packet. Look to see if you have more offer packets than known dhcp servers.
Also look into the Discover packet, there should be the bootp settings in the ethernet header. You should see a {next-server} this should point to your fog server’s IP as well as a {boot-file} that should be the name of the boot loader (undionly.kpxe for bios and ipxe.efi for uefi systems). Then down in the dhcp options make sure 66 is the ip address of the fog server and 67 is the proper boot loader. Do this for every offer packet making sure they ALL point to the same settings.
-
@foggymind Did some more testing and legacy PXE boot doesn’t work either, with error E-23. So I think it might be something related to the TFTP service. Not sure how to verify the status but I’ll do some digging to see what I can find.
-
@foggymind IMO the first step is to ensure that the clients are being told the proper information to boot. So wireshark/tcpdump is the first step. If the pxe clients are being told the right thing then focus on the tftp server or something getting in the way of tftp booting.
What devices are your dhcp servers? Are they windows dhcp servers?
I have seen where someone pluged in a home wifi router into a company business network that caused this random pxe boot information because it was giving out bad data. SOHO routers will often give their LAN IP address out as the {next-server} value. Depending on which DHCP server answers the client first (rouge dhcp or company dhcp) it caused pxe booting issues.
-
@george1421 They’re Windows servers but I confirmed my suspicions because it turns out the TFTP service wasn’t running for some reason. It’s been restarted now so I’m going to test again. I’ll let you know how it goes. Thanks for the input though, it’s been very helpful!
-
@foggymind said in NBP filesize is 0 Bytes; PXE-E18: Server response timeout:
Just started randomly receiving this error while attempting to UEFI boot
We probaly focused too much on the word “random” here… If you had told us this stopped working altogether, then we might have considered the TFTP service to be an issue but not if it’s random or if legacy BIOS clients still work. Anyhow. Let us know if you need further help with this.
-
@george1421 Thanks! The TFTP service definitely wasn’t running so that was an issue, but it is now and as a result of attempting to capture the traffic it seems as though the FOG server isn’t receiving any TFTP requests. I’m at a loss because I didn’t change any of the DHCP settings and confirmed they’re correct. I did follow this guide to set it up a while back: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence but it had been working fine until now.
-
@sebastian-roth Thanks for the input, yeah I realize that you could interpret that as randomly occurring - should have rephrased it! Looks like the fog server isn’t receiving the TFTP requests for some reason.
-
It could be interperted as you said this:
Just started randomly receiving this error while attempting to UEFI boot
That is where we made a left turn in the discussion(right out of the gate).
Is the remote pxe booting client on the same subnet or beyond a router? IF beyond a router what is your MTU of the link?
-
@foggymind said in NBP filesize is 0 Bytes; PXE-E18: Server response timeout:
Looks like the fog server isn’t receiving the TFTP requests for some reason.
Either firewall (though this would be either working or not) or some random DHCP server in your network is answering as well and leads the PXE booting machines to a different TFTP server address.
Did you attempt to capture DHCP traffic in your network to see what’s going on?
-
@sebastian-roth Yeah that could definitely be it, I haven’t captured the DHCP traffic, is that something I would use wireshark for?
-
@foggymind Oh yeah, one more thing I just remembered. I noticed that ALL the hosts show up as a red unknown status in the fog interface. They used to show a green status if they were on. I know that they are on but they still show that status. I’m not sure if that happened at the same time, but it definitely wasn’t like that before. The weird thing is that if I apply a computer name change, the fog client picks it up and applies the change.
-
@foggymind I did this (below) and captured via wireshark but it doesn’t seem to show anything interesting, just the DHCP server that’s serving the IP address. Is there something in particular I should be looking for?
-
@foggymind You need to capture the pxe booting process not the dhcp release /renew. This is release/renew is handled by windows where the pxe booting process is handled by the uefi/pxe rom. The process is to start wireshark with a capture filter of
port 67 or port 68to capture the dhcp process. If your fog server and target computers are on the same subnet then you can use tcpdump on the fog server to get the best details into what is not working.Again are your clients that you are trying to pxe boot beyond a router? I have see (and again just recently) that if your MTU of the link is set below the block size for tftp the file will not transfer because the packets will be fragmented. tftp doesn’t handle fragmented packets. So everything will look like its working up to the point where it tries to send the file to the target computer. If everything is on a LAN and your mtu is the default of 1500 then we should look elsewhere.
-
This post is deleted! -
I’m taking another look at this and basically have no idea where to go from here, any help would be greatly appreciated!