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

Gene Cumm gene.cumm at gmail.com
Sun Feb 12 12:31:09 PST 2012


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.

> 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.

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.  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).

-- 
-Gene




More information about the Syslinux mailing list