[ipxe-devel] Filename Option Precedence

[Shao Miller]

-----Original Message-----
From: Shao Miller [mailto:sha0.miller at gmail.com] 
Sent: Tuesday, October 02, 2012 03:49
To: ipxe-devel at lists.ipxe.org
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