PXE boot DHCP settings check

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