H. Peter Anvin
2012-Feb-12 18:13 UTC
[syslinux] 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.
Gene Cumm
2012-Feb-12 18:37 UTC
[syslinux] dhcp.h/dhcppack.c/dhcpunpack.c: license and enhancement
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