PXE-E32 error, unable to boot to fog from pxe

[george1421]

@K.Hays Hmmm, not sure what he means. DHCP is typically a broadcast protocol so the fog server should see the communications that goes on between the dhcp server and the client. As he said if the dhcp server is doing a unicast response tot he target this is very strange.

You are right to be concerned about posting any data, or following any instructions blindly from some strange people on the internet. If you have questions of what you are posting, use wireshark (free app) to look inside the pcap file to ensure you are not leaking data. If you have concerns but must share data, only share it long enough to get the answer you need then delete it. I can tell you we are honest folks here with only the desire to help with the fog deployment.

I would say run the capture again with this command tcpdump -w output.pcap port 67 or port 68 or port 69 and make sure you let it run long enough to capture the entire booting process of your target computer upto and for about 30 seconds past the target throwing an error. Since you are posting a second pcap file you can delete the first one.

[K.Hays]

@george1421 ok working on that now, which pcap folder should i throw your way, issues or output

[Wayne Workman]

@george1421 said in [PXE-E32 error:

Having it spelled out so the reader can just copy and paste the command to the fog server. Then once the pxe error happens they can just ctrl-c out and then upload the file to the forum. The wiki has the elements but not the whole command.

I’ve always copy/pasted what’s in the wiki. That’s the “whole command” that I use. I feel like less information in the .pcap file isn’t as good. The wiki is not written specifically for people to upload nicely filtered pcap files to the forums. The wiki is written from the perspective of “This is all you have and nobody in the forums will help you”. In other words, it’s written for the one person that will capture and troubleshoot themselves. You can always filter with wireshark later on, it’s very easy to do and those filters are in the wiki as well.

[K.Hays]

This post is deleted!

[Sebastian Roth]

I tried to get more information without using a hub or monitoring port by using this tool to send a DHCP PXE request to the DHCP server. For the record, command line options: --query --wait --option 60=PXEClient:Arch:00000:UNDI:002001 --request 66 --request 67 Unfortunately something went wrong and the output.pcap still does not have the information we need. Will probably need to try again on Monday…

But I remember a discussion about DHCP test tools with George. Back then I wasn’t very convinced for it to be a good idea. Can’t really remember which tools we talked about. I think it was more about tools that would read and display DHCP packets on the client. Now with this kind of tool that we used just now it would be very easy for pretty much every beginner to just send out a “fake” DHCP PXE boot request and see what the DHCP server’s answer is. I am thinking about having a simple (cross platform) command line tool which the user can download from his FOG server as soon as he has access to the web gui. Run the tool and it shows you your DHCP infos.

Now that I think of it why don’t have it integrated into the web interface? On click the FOG server sends a DHCP PXE request and shows the info…

[Wayne Workman]

@K.Hays I took a peek at the pcap file.

There are no next-server or filename or 066 or 067 options being given.

[Sebastian Roth]

@Wayne-Workman Sure because this is the request sent by the client! It does not show the answers as those are requests from other PCs and the DHCP server seams to answer unicast instead of broadcast.

[Wayne Workman]

@Sebastian-Roth I’m not so sure, Discovery, Offer, Request, and Acknowledge. The server does the offer, then the client takes that info and requests it from the DHCP server officially, then the DHCP server acknowledges it… This is how it works from all the captures I’ve seen…

EDIT - my bad, you are correct. I just double checked on a system here. But I still think it’d be more beneficial to just do a full capture with no filters.

[K.Hays]

So what we figured was we had to change all of our current ip pools to all point to the fog ip. Some were pulling the old fog server ip. I am now able to boot with pxe, but i get permission denied shortly after. Im still happy though, this is one step closer than i was a bit ago!

[K.Hays]

This post is deleted!

[george1421]

@K.Hays said in [PXE-E32 error:

So what we figured was we had to change all of our current ip pools to all point to the fog ip. Some were pulling the old fog server ip. I am now able to boot with pxe, but i get permission denied shortly after. Im still happy though, this is one step closer than i was a bit ago!

OK, we need to verify since you had a fog setup at one time. Lets make sure that you have undionly.kpxe listed for option 67 and not pelinux.0 or something else from the older deployment. I would also ensure (at least intially) that you the target computer and the fog server are in the same subnet. That will eliminate any cross subnet confusion.

[K.Hays]

@george1421 All of these settings and configs are correct.

[K.Hays]

@george1421 “/default.ipxe… Permission denied (http://ipxe.org/0212603c)”
That is the error I’m getting now when i try to pxe boot. It does in fact connect though to the fog server.

[Wayne Workman]

@K.Hays Can you just boot a destkop on that subnet to windows please, disable the network connection, start a Wireshark capture for that network connection, and then enable the network connection. Let Wireshark run for 15 or so seconds and then stop it, and upload that file? It will contain the DHCP information we are looking for - and this is the fastest way to get it in your situation.

[K.Hays]

@Wayne-Workman Is this going to help with the new problem? the permission denied problem? I’m doing that now but I got past the PXE-E32 error now.

[Wayne Workman]

@K.Hays Well that’s a different error and maybe a different problem - but it could be due to many things.

Firstly, I’d verify that the file exists inside of /tftpboot. If it’s there, I’d then check it’s permissions. If permissions are good, I’d then open the file and make sure the IP address at the bottom is good.

However, a photo of the error would help a lot, it would contain a lot of information that would help us help you.

[george1421]

@K.Hays Can you confirm that you have a default.ipxe in the /tftpboot directory on the server. I do have to admit this is the first time I’ve seen a permision denied message here.

The owner of this file should be fog.root with the access level of 644

And then finally cat default.ipxe and confirm that the chain at the end has the correct fog server IP address listed.

[Wayne Workman]

@george1421 It could even be requesting it from the wrong IP…

[george1421]

@Wayne-Workman Yes I agree a screen shot of the error would help. That way we can read between the pixels as it were.

[K.Hays]

@george1421