For IPoIB, the chaddr field is too small (16 bytes) to contain the
20-byte IPoIB link-layer address.  RFC4390 mandates that we should
pass an empty chaddr field and rely on the DHCP client identifier
instead.  This has many problems, not least of which is that a client
identifier containing an IPoIB link-layer address is not very useful
from the point of view of creating DHCP reservations, since the QPN
component is assigned at runtime and may vary between boots.

Leave the DHCP client identifier as-is, to avoid breaking existing
setups as far as possible, but expose the real hardware address (the
port GUID) via the DHCP chaddr field, using the broadcast flag to
instruct the DHCP server not to use this chaddr value as a link-layer
address.

This makes it possible (at least with ISC dhcpd) to create DHCP
reservations using host declarations such as:

    host duckling {
        fixed-address 10.252.252.99;
        hardware unknown-32 00:02:c9:02:00:25:a1:b5;
    }

Add FILE_LICENCE declarations to almost all files that make up the
various standard builds of gPXE.

Various combinations of options 43.6, 43.7 and 43.8 dictate which
servers we send Boot Server Discovery requests to, and which servers
we should accept responses from.  Obey these options, and remove the
explicit specification of a single Boot Server from start_pxebs() and
dependent functions.

Option 43.6 can direct us to skip PXE boot server discovery and just
perform a standard DHCP filename boot.

The DHCP client code now implements only the mechanism of the DHCP and
PXE Boot Server protocols.  Boot Server Discovery can be initiated
manually using the "pxebs" command.  The menuing code is separated out
into a user-level function on a par with boot_root_path(), and is
entered in preference to a normal filename boot if the DHCP vendor
class is "PXEClient" and the PXE boot menu option exists.

PXE dictates a mechanism for boot menuing, involving prompting the
user with a variable message, waiting for a predefined keypress,
displaying a boot menu, and waiting for a selection.

This breaks the currently desirable abstraction that DHCP is a process
that can happen in the background without any user interaction.

Remove the lazy assumption that ProxyDHCP == "DHCP with option 60 set
to PXEClient", and explicitly separate the notion of ProxyDHCP from
the notion of packets containing PXE options.

Pick out the first boot menu item from the boot menu (option 43.9) and
pass it to the boot server as the boot menu item (option 43.71).

Also improve DHCP debug messages to include more details of the
packets being transmitted.

Some PXE configurations require us to perform a third DHCP transaction
(in addition to the real DHCP transaction and the ProxyDHCP
transaction) in order to retrieve information from a "Boot Server".

This is an experimental implementation, since the actual behaviour is
not well specified in the PXE spec.

New min_timeout and max_timeout fields in struct retry_timer allow
users of this timer to set their own desired minimum and maximum
timeouts, without being constrained to a single global minimum and
maximum. Users of the timer can still elect to use the default global
values by leaving the min_timeout and max_timeout fields as 0.

Allow initiator to verify target authentication using CHAP.

Add yet another ugly hack to iscsiboot.c, this time to allow the user to
inhibit the shutdown/removal of the iSCSI INT13 device (and the network
devices, since they are required for the iSCSI device to function).

On the plus side, the fact that shutdown() now takes flags to
differentiate between shutdown-for-exit and shutdown-for-boot means that
another ugly hack (to allow returning via the PXE stack on BIOSes that
have broken INT 18 calls) will be easier.

I feel dirty.

The PXE spec is (as usual) unclear on precisely when ProxyDHCPREQUESTs
should be issued.  We adapt the following, slightly paranoid approach:

  If an offer contains an IP address, then it is a normal DHCPOFFER.

  If an offer contains an option #60 "PXEClient", then it is a
  ProxyDHCPOFFER.  Note that the same packet can be both a normal
  DHCPOFFER and a ProxyDHCPOFFER.

  After receiving the normal DHCPACK, if we have received a
  ProxyDHCPOFFER, we unicast a ProxyDHCPREQUEST back to the ProxyDHCP
  server on port 4011.  If we time out waiting for a ProxyDHCPACK, we
  treat this as a non-fatal error.

Allow for settings to be described by something other than a DHCP option
tag if desirable.  Currently used only for the MAC address setting.

Separate out fake DHCP packet creation code from dhcp.c to fakedhcp.c.

Remove notion of settings from dhcppkt.c.

Rationalise dhcp.c to use settings API only for final registration of the
DHCP options, rather than using {store,fetch}_setting throughout.

Add dedicated functions create_dhcpdiscover(), create_dhcpack() and
create_proxydhcpack() for use by external code such as the PXE preboot
code.

Register ProxyDHCP options under the global scope "proxydhcp".

Unregister previously-acquired DHCP and ProxyDHCP settings when DHCP
succeeds.

Convert DHCP option applicators in dns.c and iscsi.c to settings
applicators.

Kill off DHCP option applicators.

Add a configuration settings block for each net device.  This will
provide the parent scope for settings applicable only to that network
device (e.g. non-volatile options stored on the NIC, options obtained via
DHCP, etc.).

Expose the MAC address as a setting.

Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>

also avoid waiting for ProxyDHCP offers).

Also reduce the ProxyDHCP timeout, because it's already irritating me.

to construct DHCP packets suitable for Infiniband.

to construct DHCP packets suitable for Infiniband.

and generate DHCP options to indicate features to DHCP server (and to
PXE NBPs).

applied.

not apply DHCP options in dhcp_configure_netdev().

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