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

[george1421]

@Wayne-Workman I forgot about the wiki. I just looked through it and while I found the tcpdump section I thing we should update to include the complete command that includes the filters and output file. That way we can direct users to execute the command in step x.y.w and then post the output file here so Mr Pcap can read the bits in between the lines of code.

[george1421]

@george1421 I think at this time we need to focus on the getting the pcap file. Where we’ll run the tcpdump command on your fog server and then pxe boot the target computer. Since they are on the same subnet the fog server will see the dhcp part was well as the tftp file request.

[Wayne Workman]

@george1421 said in [PXE-E32 error:

… I thing we should update to include the complete command that includes the filters and output file.

I’m not sure I follow what you mean.

[K.Hays]

@george1421 so i need to get the pcap folder now? i ran the command and got something like this

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C719 packets captured
719 packets received by filter
0 packets dropped by kernel

[george1421]

@Wayne-Workman Sorry it took me some time to find it. My google-fu in searching the forum is very weak. (BTW: This tcpdump command was borrowed from one of Sebastian’s posts)

tcpdump -w output.pcap port 67 or port 68 or port 69

or
tcpdump -w output.pcap port 67 or port 68 or port 69 or host <fog_server_IP>
if you want to include any fog server communications too.

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.

[george1421]

@K.Hays The command you need is in my previous post.

The steps to collecting he inforamtion are

1. get the tcpdump command up and running
2. PXE boot your target computer until you reach the error
3. Ctrl-C on the tcpdump command
4. Upload the pcap file so it can be reviewed by the devs (your response time on this may be a bit)

This will give a clear picture of why your target computer can’t get that ipxe boot file (undionly.kpxe).

[K.Hays]

@george1421 ok when i try to retrieve the file from a windows computer it says it failed. ‘connect request failed’ do i need to do that or can i just put the file right up here

[K.Hays]

@george1421 Also, will this issue.pcap contain sensitive information? Should i give it out? I know how now i just need to make sure i dont release anything that shouldnt be released.

[Sebastian Roth]

@K-Hays Well either you want us to help you or you want to figure this out yourself. If we don’t have information we are pretty much helpless. I am kind of over it to ask 20 questions to get things like this fixed instead of just looking at the PCAP file that will give me all the details I need. Feel free to check out the PCAP file using wireshark yourself!

By the way, I had a look before you deleted it:

• Private IP addresses - no chance anyone here would be willing or able to make use of those to harm you
• A few DNS requests for porn URLs - just joking!!!
• DHCP wise I only see one discovery and one request packet - not enough to find out what’s going on - I guess your DHCP server is responding to the client directly instead of broadcasting (which is kind of unusual as the client requests broadcasting in its packets)

For next time: The more filters you use with tcpdump the less we see in the PCAP file. But adding to many filters might possible hide important information. As well you can open the PCAP file in wireshark, add display filters till you are happy with it and then export the remaining packets

[K.Hays]

@Sebastian-Roth sorry about that. i meant to re-add it after i talked to my boss. I will reupload it again, but what do you want me to do first? Have less filters?

[george1421]

From a security standpoint. If you use the filters command that was provided we would only be able to see what your internal dns name is. The ip address of your dhcp server, the target computer, anything your are sending to the client. The filters only allow us to see the dhcp and tftp requests. There are nothing (typically) confidential in this communications.

[K.Hays]

@george1421 i restored it but from what sebastion said i need to fix something? Should i redo the process for pcap differently? sorry for the suspicion just had to be sure

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