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

[Gene Cumm]

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

I think forcibly adding options 66/67 should probably be the last
ditch effort to get it running.

>> If object size were a concern, these features could be implemented in
>> a new set of functions such that the original stays compact and
>> intact.  It would increase the running memory requirements 50% but
>> 1024B is so small it shouldn't be a concern.
>
> I don't think it matters.
>
>> If you feel you want this on the list, feel free to reply on-list.
>
> Yes, please.

Thanks.

-- 
-Gene