[syslinux] dhcp.h/dhcppack.c/dhcpunpack.c: license and enhancement

[Jeffrey Hutzelman]

On Sun, 2012-02-12 at 15:31 -0500, Gene Cumm wrote:
> On Sun, Feb 12, 2012 at 15:00, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> > There's actually another possibility...
> >
> > PXECHAIN.COM doesn't know about the option overload mechanism or options
> > 66/67.  It assumes that the NBP filename is always provided in the BOOTP
> > 'filename' field, and that things that care about the next server
> > address will care only about siaddr and not sname or option 66.  So, if
> > the original DHCP response used option overloading and moved the
> > filename to option 67, then PXECHAIN.COM will patch the wrong part of
> > the packet.
> 
> I believe most PXE stacks follow this and always use the 'file' field
> in place of the option 67.  I believe the situation you described
> isn't likely to be the culprit (however I'd still keep my mind open
> but rank it lower).  prdhcp.c32 can also help with that.  I think I
> need to add a serial or tftp output option for the data also.

AFAIK, most PXE stacks simply record the DHCP response exactly as it
came from the server.  So, it's all about what the DHCP server does,
which is going to depend on whether it needs the extra space.


> > It would be a pretty serious bug if WDS insisted that option 66/67 be
> > used even when overloading is not in effect.  Also, while I'm not 100%
> > sure that all of our infrastructure has been upgraded to 2008R2, we do
> > use PXECHAIN with WDS fairly regularly, and our DHCP responses don't use
> > option overloading (or PXECHAIN wouldn't work).  So I expect we'd have
> > noticed such a bug if it existed.
> 
> It is WS2008R2 specific as I've seen another Syslinux contributor
> comment that his WS2008 environment did work with pxechain.com.

I'll try to remember to find out tomorrow whether the WDS-related bits
of our infrastructure have been upgraded to 2008R2.



> As I said, there's 3 possible missing data elements.  MS documentation
> ( http://technet.microsoft.com/en-us/library/cc771670(WS.10).aspx#BKMK_ConfiguringDS
> ) references ensuring option 60 (Vendor Class) and 66 & 67
> (siaddr/sname & file) are present while the original PXE spec states
> option 97 should also be present.

Yup.  PXECHAIN.COM doesn't touch any of this -- it just rewrites siaddr
and filename; the presumption is that the original response was PXE
compliant to begin with.  Of course, being able to actually construct
exactly the DHCP response you want to pass to the next NBP would provide
considerably more flexibility than PXECHAIN.COM does.



>   I mentioned elsewhere that when I
> set option 66 in an MS DHCP service to an IPv4 dotted decimal string,
> it didn't set option 66 or sname but only set siaddr (I'm trying to
> use RFC names for clarity/consistency).

That's... interesting.  I suppose that's not too surprising, since sname
is supposed to be a name (in fact, once upon a time, some widely-used
platforms assumed sname to be the name of the server identified in
siaddr and used that to seed /etc/hosts).