Some older operating systems (e.g. RHEL6) use a non-default filename
on the root disk and rely on setting an EFI variable to point to the
bootloader.  This does not work when performing a SAN boot on a
machine where the EFI variable is not present.

Fix by allowing a non-default filename to be specified via the
"sanboot --filename" option or the "san-filename" setting.  For
example:

  sanboot --filename \efi\redhat\grub.efi \
          iscsi:192.168.0.1::::iqn.2010-04.org.ipxe.demo:rhel6

or

  option ipxe.san-filename code 188 = string;
  option ipxe.san-filename "\\efi\\redhat\\grub.efi";
  option root-path "iscsi:192.168.0.1::::iqn.2010-04.org.ipxe.demo:rhel6";

Originally-implemented-by: Vishvananda Ishaya Abrams <vish.ishaya@oracle.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Allow the SAN retry count to be configured via the ${san-retry}
setting, defaulting to the current value of 10 retries if not
specified.

Note that setting a retry count of zero is inadvisable, since iSCSI
targets in particular will often report spurious errors such as "power
on occurred" for the first few commands.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Provide a settings applicator to modify netdev->max_pkt_len in
response to changes to the "mtu" setting (DHCP option 26).

Note that as with MAC address changes, drivers are permitted to
completely ignore any changes in the MTU value.  The net result will
be that iPXE effectively uses the smaller of either the hardware
default MTU or the software configured MTU.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

The vendor class identifier strings in DHCP_ARCH_VENDOR_CLASS_ID are
out of sync with the (correct) client architecture values in
DHCP_ARCH_CLIENT_ARCHITECTURE.

Fix by removing all definitions of DHCP_ARCH_VENDOR_CLASS_ID, and
instead generating the vendor class identifier string automatically
based on DHCP_ARCH_CLIENT_ARCHITECTURE and DHCP_ARCH_CLIENT_NDI.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

There has been a longstanding disagreement between RFC4578 and the
IANA "Processor Architecture Types" registry.  RFC4578 section 2.1
defines type 7 as "EFI BC" and type 9 as "EFI x86-64"; the IANA
registry quotes RFC4578 as its source but has these values erroneously
swapped.  The EDK2 codebase uses the IANA values.

As of March 2016, RFC4578 has been modified by an errata to match the
values as recorded in the IANA registry.

Fix our definitions to match the consensus values.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Signed-off-by: Michael Brown <mcb30@ipxe.org>

The DHCP option 175.189 has been defined (by us) since 2006 as
containing the drive number to be used for a SAN boot, but has never
been automatically used as such by iPXE.

Use this option (if specified) to override the default SAN drive
number.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

These files cannot be automatically relicensed by util/relicense.pl
since they either contain unusual but trivial contributions (such as
the addition of __nonnull function attributes), or contain lines
dating back to the initial git revision (and so require manual
knowledge of the code's origin).

Signed-off-by: Michael Brown <mcb30@ipxe.org>

iPXE uses DHCP timeouts loosely based on values recommended by the
specification, but often abbreviated to reduce timeouts for reliable
and/or simple network topologies.  Extract the DHCP timing parameters
to config/dhcp.h and document them.  The resulting default iPXE
behavior is exactly the same, but downstreams are now afforded the
opportunity to implement spec-compliant behavior via config file
overrides.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Update the DNS resolver to support DNS search lists (as provided by
DHCP option 119, DHCPv6 option 24, or NDP option 31).

Add validation code to ensure that parsing of DNS packets does not
overrun the input, get stuck in infinite loops, or (worse) write
beyond the end of allocated buffers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

When chainloading, always retrieve the cached DHCPACK packet from the
underlying PXE stack, and apply it as the original contents of the
"net<X>.dhcp" settings block.  This allows cached DHCP settings to be
used for any chainloaded iPXE binary (not just undionly.kkpxe).

This change eliminates the undocumented "use-cached" setting.  Issuing
the "dhcp" command will now always result in a fresh DHCP request.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Almost all clients of the raw-packet interfaces (UNDI and SNP) can
handle only Ethernet link layers.  Expose an Ethernet-compatible link
layer to local clients, while remaining compatible with IPoIB on the
wire.  This requires manipulation of ARP (but not DHCP) packets within
the IPoIB driver.

This is ugly, but it's the only viable way to allow IPoIB devices to
be driven via the raw-packet interfaces.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Automatically attempt to download any required cross-signing
certificates from http://ca.ipxe.org/auto, in order to enable the use
of standard SSL certificates issued by public CAs.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Changing the trusted root certificate currently requires a rebuild of
the iPXE binary, which may be inconvenient or impractical.

Allow the list of trusted root certificate fingerprints to be
overridden using the "trust" setting, but only at the point of iPXE
initialisation.  This prevents untrusted sources of settings
(e.g. DHCP) from subverting the chain of trust, while allowing
trustworthy sources to change the trusted root certificate without
requiring a rebuild.

The basic idea is that if you are able to manipulate a trustworthy
source of settings (e.g. VMware GuestInfo or non-volatile stored
options), then you would be able to replace the iPXE binary anyway,
and so no security is lost by allowing such sources to override the
list of trusted root certificates.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Encrypted syslog seems not yet to be standardised, but is supported by
some existing syslog servers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Make the non-standard but extremely useful macro VA_ARG_COUNT()
available outside of dhcp.h.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

iPXE currently uses the last four bytes of the MAC address as the DHCP
transaction identifier.  Reduce the probability of collisions by
generating a random transaction identifier.

Originally-implemented-by: Amos Kong <akong@redhat.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Signed-off-by: Michael Brown <mcb30@ipxe.org>

A scriptlet is a single iPXE command that can be stored in
non-volatile option storage and used to override the default
"autoboot" behaviour without having to reflash the iPXE image.

For example, a scriptlet could contain

    autoboot || reboot

to instruct iPXE to reboot the system if booting fails.

Unlike an embedded image, the presence of a scriptlet does not inhibit
the initial "Press Ctrl-B..." prompt.  This allows the user to recover
from setting a faulty scriptlet.

Originally-implemented-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

For IPoIB, we currently use the hardware address (i.e. the eight-byte
GUID) as the DHCP chaddr.  This works, but some PXE servers (notably
Altiris RDP) refuse to respond if the chaddr field is anything other
than six bytes in length.

We already have the notion of an Ethernet-compatible link-layer
address, which is used in the iBFT (the design of which similarly
fails to account for non-Ethernet link layers).  Use this as the first
preferred alternative to the actual link-layer address when
constructing the DHCP chaddr field.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

For some install-to-SAN scenarios, the OS needs to be able to reboot
to reread the partition table.  On this second boot attempt, the SAN
disk will not be empty and so iPXE will attempt to boot from it,
rather than falling back to the OS' installation media.

Work around this problem by introducing the "skip-san-boot" option,
similar in spirit to "keep-san".

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Remove job-control as an interface type, and replace job-control
interfaces with generic interfaces supporting the close() method.
(Both done() and kill() are absorbed into the function of close();
kill() is merely close(-ECANCELED).)

Signed-off-by: Michael Brown <mcb30@ipxe.org>

This removes the need for inline safety wrappers, marginally reducing
the size penalty of weak functions, and works around an apparent
binutils bug that causes undefined weak symbols to not actually be
NULL when compiling with -fPIE (as EFI builds do).

A bug in versions of binutils prior to 2.16 (released in 2005) will
cause same-file weak definitions to not work with those
toolchains. Update the README to reflect our new dependency on
binutils >= 2.16.

Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Access to the gpxe.org and etherboot.org domains and associated
resources has been revoked by the registrant of the domain.  Work
around this problem by renaming project from gPXE to iPXE, and
updating URLs to match.

Also update README, LOG and COPYRIGHTS to remove obsolete information.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

When a DHCP session is started (using autoboot or a command-line `dhcp
net0'), check whether the new setting use-cached (DHCP option 175.178)
is TRUE; if so, skip DHCP and rely on currently registered
settings. This lets one combine a static IP with autoboot.

Before checking the use-cached setting, call a weak
get_cached_dhcpack() hook that can be implemented by particular builds
of gPXE supporting some fashion of retrieving a cached DHCPACK packet.
If one is available, it is registered as an options source, and then
either that packet's option 175.178 or the user's prior manual
use-cached setting can allow skipping duplicate DHCP.

Using cached packets is not the default because DHCP servers are often
configured to give gPXE different options than they give a vendor PXE
client; in order to break the infinite loop of PXE chaining, one would
need to load a gPXE with an embedded image that does something more
than autoboot.

Signed-off-by: Marty Connor <mdc@etherboot.org>

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.