atom feed8 messages in net.sourceforge.lists.etherboot-developersRe: [Etherboot-developers] gPXE and d...
FromSent OnAttachments
Simon KelleyApr 8, 2009 1:00 am 
Marty ConnorApr 8, 2009 9:38 am 
Simon KelleyApr 8, 2009 12:42 pm 
Michael BrownApr 15, 2009 9:29 am 
Michael BrownApr 15, 2009 1:11 pm 
Simon KelleyApr 16, 2009 9:41 am 
Michael BrownApr 16, 2009 12:02 pm 
Simon KelleyApr 19, 2009 7:54 am 
Subject:Re: [Etherboot-developers] gPXE and dnsmasq
From:Marty Connor (
Date:Apr 8, 2009 9:38:18 am

Hi Simon,

Thanks very much for writing. We are very interested in better interoperability with dnsmasq and look forward to working with you to achieve it.

Our lead developer, Michael Brown is away for a few days, but will be back soon. We recently discussed the filename (option 67) issue and are interested in working on proxy support as well.

I'm sure Michael will soon share some more specific thoughts, but I wanted to reply sooner so you know we hear you and that we look forward to working with you.

Thanks and Regards,


Simon Kelley wrote:

Greeting and apologies for breaking the threading on this. I just found this list and the previous discussion via Google, and I have no way to safely include threading headers.

I'm the main developer of dnsmasq, and I have indeed been testing gPXE (and every PXE ROM I could get my hands on) over the last few weeks whilst I've been implementing proxyDHCP and PXE menuing in dnsmasq.

There are two completely different issues I've found with pPXE.

The first is the option 67 one: gPXE asks for option 67 in DHCPDISCOVER/DHCPREQUEST but if it gets the boot filename that way, it ignores it. It would be great to change that since at the moment to use gPXE and dnsmasq an obscure dnsmasq option is needed. I could detect gPXE (by looking for option 175) and special-case it, and I will do that if there's a good reason to retain the existing gPXE behaviour. I'm hoping that the existing gPXE behaviour is an oversight and it can be fixed in gPXE.

The second issue that came up was the gPXE either doesn't implement the PXE menu system, or I'm doing something wrong and it's not understanding my packets.

My understanding of the situation is this: Intel PXE ROMS can function in two modes. Mostly the DHCP server doesn't send option 60 == "PXEClient" and a whole slew of encapsulated options in option 43 so the ROM goes into simple mode, once it has an IP address it TFTPs the file given in the filename field of the DHCPACK packet and transfers control to it. If the extra DHCP options are there, then they can specify a set of menu lines and various other information. After possibly putting up a menu and getting a response, the PXE ROM then contacts a "Boot server" and the reply from the boot server gives the filename. The interaction with the boot server looks like DHCP, but it isn't. It can go via broadcast to port 67 or multicast/unicast to port 4011.

What I'm seeing with gPXE is that even when supplied with a DHCPACK which puts every other PXEClient I've tried into "full fat" mode, and contains menu and prompt options, it stays in "simple" mode. Using wireshark I can see DHCPREQUEST packets going to port 4011 unicast, but since dnsmasq doesn't listen there it doesn't see them. I'me not seeing the broadcast to port 67 which is requested in the "Discovery control" option I send.

If this is deliberate, I'd say that's a good design decision: the full PXE protocol is insane, and gPXE has other menuing facilities when combined with PXELINUX. I'll arrange to provide a filename as well as the full PXE options in response to vendorclass:PXEClient requests, and document the gPXE difference. If OTOH it's supposed to work like Intel PXE, I'd like to try and find out why it isn't.

I'd like to conclude by saying that I'm happy to work on interop between gPXE and dnsmasq (I've already done work to enable gPXE chain load, and to send arbitrary encapsulated options.). I'm now subscribed to the list, and plan to keep an eye on gPXE-land from now on.