Syslinux - Feb 2012 - dhcp.h/dhcppack.c/dhcpunpack.c: license and enhancement

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

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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