DHCPD and Windows RIS in particular).

structures.

DHCP still broken and #if 0'd out.

output buffering defintions and the like)

will enable us to cascade async operations, which is necessary in order to
properly support DNS.  (For example, an HTTP request may have to redirect
to a new location and will have to perform a new DNS lookup, so we can't
just rely on doing the name lookup at the time of parsing the initial
URL).

Anything other than HTTP is probably broken right now; I'll fix the others
up asap.

http://www.microsoft.com/whdc/winlogo/hwrequirements.mspx as required
for iSCSI boot.  Note that options 204-206 are listed in the document
but don't seem to be defined anywhere on the web.

information in NVS.

list.

create_dhcp_packet() from pxe_preboot.c, after the dhcp_session is long
gone.

Expose the functions required by pxe_preboot.c

Added test code to configure the interface for IPv4 after DHCP.

cycle.  :)

(apart from the bad UDP checksum).

parsed DHCP responses.

structure, and populating it with options.  This should allow us to
use the same basic options list for both DHCPDISCOVER and DHCPREQUEST,
plus making it much easier to set the non-constant parameters
(e.g. requested IP address) in request packets.

to search through all registered option blocks.

Move some static inlines that are likely to be used frequently into
dhcpopts.c as normal functions, to save space.

derived is a 16-bit big-endian field, but htype is only 8 bits wide.

is a DHCP option" data structures.

We need this code in order to be able to return a DHCP packet to a PXE NBP
which reflects options from our multiple sources (e.g. NVS and DHCP
server).  This is expensive, but necessary.  Having paid this cost, we may
as well try to use the same code to generate our DHCP request packets,
since the process is similar.

DHCP options block from the contents.

encapsulated option; this will be needed for modifications to the options
block.

multiple option sources (e.g. multiple DHCP replies, non-volatile
storage etc.)