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

[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

[Tom Elliott]

@K.Hays Have you tried updating to trunk?

[Tom Elliott]

First, all, this is 1.2.0 (Sorry it wasn’t asked before. And glancing over the posts, it wasn’t mentioned at all either).

[Wayne Workman]

@K.Hays Internal addressing is not available to the outside world and doesn’t harm anything to share. However I’d recommend not sharing external addressing.

[george1421]

@Wayne-Workman Isn’t there suppose to be text to the left of /default.ipxe? I just tried on my system and its too fast for me to catch.