Syslinux - Dec 2011 - PXELINUX: DHCP field giaddr (pxe_bootp_t.gip)

Right now, I almost have pxechn.c32 in a fully functional state by
adding a parameter to allow pure hex input of an option and its data.
It allows uppercase and lowercase entry with or without octet
delimiters (which must not match [0-9A-Fa-f]) and requires 2-digit
entry for the octet.  This is an extremely loose input format such
that users may utilize it in their preferred format.

After adding this, I believe I have about everything implemented
except I'm uncertain about the DHCP field giaddr (pxe_bootp_t.gip).
My current test environment doesn't utilize this (just 0).  I'm mostly
looking to see if it's something that it might be desirable to modify.
 DHCP fields sname and siaddr are already adjusted as needed.

-- 
-Gene

On Fri, Dec 23, 2011 at 08:57, Gene Cumm <gene.cumm at gmail.com>
wrote:
> Right now, I almost have pxechn.c32 in a fully functional state by
> adding a parameter to allow pure hex input of an option and its data.
> It allows uppercase and lowercase entry with or without octet
> delimiters (which must not match [0-9A-Fa-f]) and requires 2-digit
> entry for the octet. ?This is an extremely loose input format such
> that users may utilize it in their preferred format.
>
> After adding this, I believe I have about everything implemented
> except I'm uncertain about the DHCP field giaddr (pxe_bootp_t.gip).
> My current test environment doesn't utilize this (just 0). ?I'm
mostly
> looking to see if it's something that it might be desirable to modify.
> ?DHCP fields sname and siaddr are already adjusted as needed.
Rereading RFC 2131 and finally finding an old capture, it's the
subnet-local IP address for the DHCP relay agent.

RFC 3396 allows for the encoding of options that exceed 255 octets or
otherwise must be split.  I'm assuming that PXELINUX and
dhcp_unpack_packet()/dhcp_pack_packet() have currently no way to deal
with this data and that it's likely not planned as there has been no
use case for it.

-- 
-Gene