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

Jeffrey Hutzelman jhutz at cmu.edu
Sun Feb 12 12:00:44 PST 2012


On Sun, 2012-02-12 at 13:37 -0500, Gene Cumm wrote:
> On Sun, Feb 12, 2012 at 13:13, H. Peter Anvin <hpa at zytor.com> wrote:
> > On 02/12/2012 06:01 AM, Gene Cumm wrote:
> >> I had grabbed dhcp.h/dhcppack.c/dhcpunpack.c from
> >> http://www.zytor.com/~hpa/syslinux/dhcp/ months ago when we were
> >> talking about it more and it's been rather nice to use.  Should it
> >> contain a copyright/license header?  Currently I'm just using them
> >> as-is in com32/lib/ for pxechn.c32.
> >
> > It really should, yes.
> 
> I figured ask first.  Let me know if there's something I can do in
> that respect to help.
> 
> >> Also, as I stated yesterday, I need to be able to use DHCP options
> >> 66/67 as real options (not just their DHCP fields) and thought either
> >> a flag argument to dhcp_pack_packet() or a flags field on struct
> >> dhcp_option would work.  I think the flags field (probably as a
> >> uint32_t) would be better as I could foresee wanting to have the
> >> options in a certain order in order to satisfy some NBP in the future.
> >>  I'm thinking the order section would be the lowest 8-9 bits (such
> >> that masking reveals the order number).  0 would indicate no order
> >> specified (which says add it to the tail) and the maximum value would
> >> attempt to insert it at the head (with option 53 always taking
> >> precedence).
> >
> > I'm not entirely sure what you're proposing here... the bit about 66/67
> > scares the heck out of me, but I guess that's Microsoft idiocy for you.
> 
> Yes, this is the bad part.  I'd need someone with a functioning WDS
> deployment on WS2008R2 to test (or take some time and try to build it
> myself in a VM or two).  I suspect that the reason chaining wdsnbp.com
> (from WS2008R2) from PXELINUX with pxechain.com failed is that the
> packets didn't contain 1) option 60 with "PXEClient", 2) UUID in
> option 97 and/or 3) the lack of options 66/67 (as options and not just
> the file/sname fields).

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.

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.

-- Jeff




More information about the Syslinux mailing list