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:Michael Brown (mbr@fensystems.co.uk)
Date:Apr 15, 2009 9:29:38 am
List:net.sourceforge.lists.etherboot-developers

On Wednesday 08 April 2009 20:42:27 Simon Kelley wrote:

gPXE seems not to multicast. It first broadcasts, and then unicasts if a boot server address is available. Both broadcasts and unicasts go to port 4011. This breaks dnsmasq, which is relying on broadcasts to port 67 (it doesn't listen on port 4011). Fixing the broadcast to go to the correct port 67 would almost certainly make non-proxy PXE-menu booting work. I will attempt to get a build-tree of gPXE up, and make the necessary patch.

I believe we should attempt multicasting. I definitely remember having to fix up some bugs in ethernet.c relating to transmission of multicast packets around the time I was working on this.

Intel's protocol diagram for proxyDHCP with the proxy on another server is on page 18. In that the proxy replies to DHCPDISCOVER with an OFFER of address 0.0.0.0. The client then contacts it again on port 4011 for reply with the PXE boot information. What is not specifically stated, though it is hinted at, is that if the proxy server OFFER of address 0.0.0.0 contains all the necessary information (option 60 and option 43 and possibly a filename if discovery control == 8) then the port 4011 stage is not required. This is how dnsmasq DHCPproxy is implemented. It doesn't currently work in gPXE.

It should work; gPXE will treat a port 4011 ProxyDHCPREQUEST failure as a non-fatal error, and will proceed with the options already obtain via DHCPACK.

Michael