PXE boot DHCP settings check

[Sebastian Roth]

Reviving the a discussion I had with George a while ago about potential and usefulness of tools to check on PXE boot information in DHCP packets. The first idea was to have a listen only (capture) tool which I didn’t really like because it would need to run on a second PC while another one is PXE booting. Because of that we possibly don’t see the DHCP answer packets as they might be unicast or don’t reach that second client due to other network setup issues.

It should be fairly easy to get more information without using a hub or monitoring port by sending “fake requests” from a client that is not actually PCE booting at that moment. I have tried it using dhcptest (cmd options: --query --wait --option 60=PXEClient:Arch:00000:UNDI:002001 --request 66 --request 67).

I had a quick look into PHP’s socket operations and I am sure it would be quite easy to implement a DHCP PXE boot info check. The only problem is that you are allowed to send packets from low ports (DHCP src port 68) as root!! So this would need another FOGService to run on the server. I don’t really see why we should add another FOG daemon which is not useful as soon as PXE boot is working for you. So I guess we better focus on the idea of having a cross platform client binary. This way we also see if network issues on the client would prevent DHCP answers from reaching the client - even better!

PS: I moved the posts from the other (kind of unrelated) topic here as well.

[george1421]

I remember that discussion about the dhcp client tool. The utility I found was for windows and it wasn’t very good.

I did check into dhcpdump which looked promising. There is a version for each distro but it seems inconsistent between the distributions. The commands from this article did not work as intended on centos. http://www.cyberciti.biz/faq/linux-unix-dhcpdump-monitor-dhcp-traffic/

This one worked for my centos tests http://higaknowit.com/2011/08/04/debugging-dhcpdump/

If you follow on to the projects homepage http://www.mavetju.org/unix/general.php you can get dhcpping and dhcpdump. It would be interesting if we could use these tools some how for detection. But I feel Sebastian’s right in that some how we need to know for sure at dhcp is responding correctly for pxe booting. This (dhcp configuration) is not specifically a FOG issue but FOG is dependent on on a proper dhcp setup. I know for a fact other image deployment tools struggle with the same issue.

[Wayne Workman]

@george1421 I’d be willing to try to make something. Shouldn’t be too hard, after all, just making a DHCP request to ff:ff:ff:ff:ff:ff and then storing any returned DHCP offer packets. Simple enough, right? It’d be much less sophisticated than DHCPDump I’m sure.

[george1421]

@Wayne-Workman While we are getting a bit off the OP’s point. I think I would focus on parsing the dhcpdump’s output into a friendly format, instead of trying work on decoding on the packet level. But that’s just me.

[Sebastian Roth]

I just compiled and tested dhcping. I think it’s useless for what we are trying to achieve. There is no way to specify DHCP options and we won’t get option 66/67 back from the DHCP server.

The mentioned dhcptest tool does what we want but I actually don’t want to add another language (D in this case!) to the pool. I’d actually prefer to go along the lines of what we are running on the clients already - the FOG client. Don’t think it needs to be build into the FOG client but rather have a simple extra tool for users (ready to be downloaded via the FOG web gui if someone has trouble with DHCP). Possibly there is something to start from: http://windhcp.codeplex.com/releases/view/8903

[Wayne Workman]

@Sebastian-Roth Maybe we need a service that would start ALL fog services, based on what the DB says.

Then, you could turn on/off services at will from the web interface as need presents itself.

For example,

IF…
SELECT settingValue FROM globalSettings WHERE settingKey = ‘FOGImageReplicatorEnabled’

equals 1

then start FOGImageReplicator

[Tom Elliott]

@Wayne-Workman any/all services of this service would already be able to run automatically from this point forward if this were implemented. Why? Because all the fog services need are network and db to start properly. This would be the same for this referenced service as well.

[Wayne Workman]

@Tom-Elliott I’m not sure I follow your last two sentences… not sure about the first one either. You’re doing Tom-Speak again.

[Sebastian Roth]

@Jbob Yeah, the RFC is definitely a good starting point. You might wanna check out the PXE spec as well: ftp://download.intel.com/design/archives/wfm/downloads/pxespec.pdf

Please let me know if I can assist in building the tool. I am happy to join in.

[george1421]

I don’t know if the source for dhcpdump would be of any help or just confuse the programming.

(just a brain dump here…)

From a support standpoint. It would be ideal if we could see all responding dhcp servers as well as their parameters being published by the dhcp server.

Things we need to identify is if more than one dhcp server responds to a dhcp request
The parameters returned by all dhcp servers (specifically dhcp options 66, 67 and maybe 1 if fog is in a routed network)
If there is a dhcpPROX (dnsmasq like service sending out data, I think via udp port 4011) in the environment providing additional parameters not supplied by the dhcp server.

From that info we should be able to find out if the FOG external environment is setup correctly. Of course more information is alway helpful for strange issues. But the tool should be able to provide those values.

[Sebastian Roth]

Jbob started of with a nice code sample in C# to send DHCP discovery and receive answer packets. Working on this I ran into a major problem trying to send packets with source address 0.0.0.0 (as one usually does not have a source IP when trying to get one via DHCP). It seems like some DHCP servers don’t mind DHCP discovery packets with proper source address but I feel this is not good and might tamper the results we get…

I have tried to build my own raw IP packets but C#/mono on Linux still try to be smart and set source address to one of my interface IPs.

[Wayne Workman]

@Sebastian-Roth maybe an interface without an address then (just for starters)?

[Sebastian Roth]

@Wayne-Workman said:

maybe an interface without an address then (just for starters)?

Not sure what you mean by that? Can you explain? In C# you can use function SendTo without specifying a sender address (uses just any it finds) or you can tell it to use “any” (0.0.0.0 really) which gives me the same result. AFAIK there is no way to just specify a sender interface…

[Wayne Workman]

@Sebastian-Roth Set the interface to have the ip 0.0.0.0 and then try.

Also - I’ve been studying for RHCSA and this book I’ve got says that every hardware device is accessible via the file system, and you can send/receive data by reading and writing to the device files (wild stuff to me). I wonder if you could send a packet with just a shell script if you knew the device file?

[Sebastian Roth]

@Wayne-Workman said:

Set the interface to have the ip 0.0.0.0 and then try.

Tried… magically uses my WLAN adapter address as source then! Funny thing, I can set source to 1.0.0.0 and I get 1.0.0.0 in wireshark. But as soon as I try 0.0.0.0 it does not want to play the game.

I wonder if you could send a packet with just a shell script if you knew the device file?

For sure we could but doesn’t help much here as we would like to have a platform independent solution to check on PXE information.

[Sebastian Roth]

I found a way to send very much raw packets via AF_PACKET socket on Linux in plain C - allowing sender IP 0.0.0.0! This code could also be used as native library calls from C#. But AFAIK that won’t be portable to Windows as winsock does not have AF_PACKET or anything similar.

So I put that idea aside for now and played with PcapDotNet and SharpPcap. Where only the later one I could make work on Linux/mono - possibly because I don’t know mono/C# well enough. With SharpPcap I was able to send DHCP Discover packets with sender address 0.0.0.0 just fine. So I am wondering if this would be the way to go. What do you think @Jbob ? I will provide example code soon!

[Sebastian Roth]

Ok, together with Jbob I seem to have figured out a working set of libraries (SharpPcap and PacketDotNet) and C# code to send and receive the packets we want. Hopefully we’ll have the first alpha version of a tool ready soon!