-----Original Message----- From: Shao Miller [mailto:[email protected]] Sent: Tuesday, October 02, 2012 03:49 To: [email protected] Subject: Filename Option Precedence
Tim Riker reported a behavioural difference between an Intel stack and iPXE. In his scenario, the client receives an offer from both a DHCP server as well as a PXE server. Only the PXE server sends option 60. The DHCP also sends option 67. Both the Intel stack and iPXE go through the DHCP motions with the DHCP server. Then they both go through the motions on UDP 4011 with the PXE server. The difference being that the Intel stack uses the filename option from the PXE server, but iPXE uses the filename option from the DHCP server. Something like: DHCPDISCOVER DHCPOFFER from 192.168.10.1:67 proxy DHCPDISCOVER DHCPOFFER from 192.168.10.1:67 proxy DHCPOFFER from 192.168.11.1:67 for 192.168.11.23 entering request state DHCREQUEST to 192.168.11.1:67 for 192.168.11.23 DHCPOFFER from 192.168.10.1:67 DHCPACK from 192.168.11.1:67 for 192.168.11.23 entering ProxyDHCP state ProxyDHCP REQUEST to 192.168.10.1 ProxyDHCP REQUEST to 192.168.10.1 DHCPACK from 192.168.10.1:4011 But then a look at 'show filename' shows net0.dhcp/filename instead of proxydhcp/filename I remember that there's been lots of discussion about this kind of thing in the past, including Simon Kelley for dnsmasq, but I don't quite recall if this particular precedence for the filename option is intentional or not. If we're not going to use the option from the ProxyDHCP server, why do we bother asking it? :) -----End of Original Message----- I've reviewed some of the e-mail correspondence with Simon in Etherboot-developers' thread "[Etherboot-developers] gPXE and dnsmasq" and off-list thread "Re: ProxyDHCPOFFERs with 67 versus 4011" I've concluded that accepting the filename option from the ProxyDHCP server to take precedence over the DHCP server's filename option won't break dnsmasq compatibility. (E-mail were April 8th, 2009 through November 9th, 2009) Looking at PXE 2.1, self-labeled page 49 (though 51 in my reader), I can imagine the Intel PXE logic having a focus on filling the three "cached packets." Simon had mentioned long ago that he observed Intel not actually sending out a DHCP Request to a PXE service on UDP 4011 if that service had already sent all useful options in an earlier DHCP Offer. That is consistent with page 49's description of cached packet #3. However, I had noticed Intel _would_ send a Request to UDP 4011 if it still required additional information. Something I'd like to test is if the cached packet #3 is the DHCP Acknowledgement for the case when Intel actually sends a Request to the ProxyDHCP service, or if they hack it to look like an Offer. In Tim Riker's scenario, the PXE service (which I think was some incarnation of Windows Deployment Services) wasn't sending the filename until its DHCP Acknowledgement, at which point Intel is finally satisfied. Same motions as iPXE, only we use the DHCP filename, after all that has finished. Simon, would you expect a PXE client using dnsmasq in ProxyDHCP mode to use the filename option from dnsmasq? I assume so, but had better ask. - Shao _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
