[ipv6] Fix definition of IN6_IS_ADDR_LINKLOCAL()

Fix an erroneous htonl() in the definition of IN6_IS_ADDR_LINKLOCAL(),
and add self-tests for the IN6_IS_ADDR_xxx() family of macros.

Reported-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[dhcpv6] Do not set sin6_scope_id on the unspecified client socket address

Setting sin6_scope_id to a non-zero value will cause the check against
the "empty socket address" in udp_demux() to fail, and incoming DHCPv6
responses on interfaces other than net0 will be rejected with a
spurious "No UDP connection listening on port 546" error.

The transmitting network device is specified via the destination
address, not the source address.  Fix by simply not setting
sin6_scope_id on the client socket address.

Reported-by: Anton D. Kachalov <mouse@yandex-team.ru>
Tested-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ipv6] Do not set sin6_scope_id on source address

The transmitting network device is specified via the destination
address, not the source address.  There is no reason to set
sin6_scope_id on the source address.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ipv6] Include network device when transcribing multicast addresses

Destination multicast addresses require a sin6_scope_id, which should
therefore be transcribed to a network device name by ipv6_sock_ntoa().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ipv6] Avoid potentially copying from a NULL pointer in ipv6_tx()

If ipv6_tx() is called with a non-NULL network device, a NULL or
unspecified source address, and a destination address which does not
match any routing table entry, then it will attempt to copy the source
address from a NULL pointer.

I don't think that there is currently any code path which could
trigger this behaviour, but we should probably ensure that it can
never happen.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[librm] Allow for the PIC interrupt vector offset to be changed

Some external code (observed with FreeBSD's bootloader) will continue
to make INT 13 calls after reconfiguring the 8259 PIC to change the
vector offsets for IRQs.  If an IRQ (e.g. the timer IRQ) subsequently
occurs while iPXE is in protected mode, this will cause a general
protection fault since the corresponding IDT entry is empty.

A general protection fault is INT 0x0d, which happens to overlap with
the original IRQ5.  We therefore do have an ISR set up to handle a
general protection fault, but this ISR simply reflects the interrupt
down to the real-mode INT 0x0d and then attempts to return.  Since our
ISR is expecting a hardware interrupt rather than a general protection
fault, it doesn't remove the error code from the stack before issuing
the iret instruction; it therefore attempts to return to a garbage
address.  Since the segment part of this address is likely to be
invalid, a second general protection fault occurs.  This cycle
continues until we run out of stack space and triple fault.

Fix by reflecting all INTs down to real mode.  This actually reduces
the code size by four bytes (but increases the bss size by almost
2kB).

Reported-by: Brian Rak <dn@devicenull.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ifmgmt] Do not sleep CPU while configuring network devices

iPXE currently calls cpu_nap() while performing DHCP, in order to
reduce CPU utilisation on virtual machines.  Under mild broadcast load
(~100 packets per second), this can cause received packets to be
dropped because the receive descriptor ring is overrun before the next
18Hz timer interrupt wakes up the CPU.  The result is that DHCP is
likely to intermittently fail on networks with appreciable amounts of
broadcast (or multicast) traffic.

This behaviour was introduced in the series of commits which
generalised the "dhcp" command to the "ifconf" command.  The earlier
code (which did not handle IPv6 configuration) had no call to
cpu_nap() and so did not suffer from this problem.

Fix by removing the call to cpu_nap() in ifpoller_progress().  This
has the undesirable side effect that CPU utilisation will remain at
100% while waiting for DHCP to complete (which can take several
seconds, if we have to wait around for potential ProxyDHCP offers to
arrive).

Reported-by: Alex Davies <adavies@jumptrading.com>
Reported-by: Christoffer Stokbæk <christoffers@easyspeedy.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ethernet] Provide eth_random_addr() to generate random Ethernet addresses

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[scsi] Improve sense code parsing

Parse the sense data to extract the reponse code, the sense key, the
additional sense code, and the additional sense code qualifier.

Originally-implemented-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[iscsi] Read IPv4 settings only from the relevant network device

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[iscsi] Include IP address origin in iBFT

The iBFT includes an "origin" field to indicate the source of the IP
address.  We use the heuristic of assuming that the source should be
"manual" if the IP address originates directly from the network device
settings block, and "DHCP" otherwise.  This is an imperfect guess, but
is likely to be correct in most common situations.

Originally-implemented-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[igbvf] Assign random MAC address if none is set

If the VF doesn't have a MAC address assigned we should create a
random MAC address.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[igbvf] Allow changing of MAC address

The VF might not have assigned a MAC address upon startup, and will
end up with a random MAC address during probe().  With this patch the
MAC address can be changed later on.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[smbios] Expose board serial number as ${board-serial}

With blade servers, the chassis serial number (exposed via ${serial})
may not be unique.  Expose ${board-serial} as a named setting to
provide easy access to a more meaningful serial number.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Check if git index actually exists

If iPXE is used as a git submodule then the ../.git/index file will
not exist, and the build will fail.  Fix by checking that the git
index file exists before adding it as a build dependency.

Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[debug] Allow debug message colours to be customised via DBGCOL=...

When multiple iPXE binaries are running concurrently (e.g. in the case
of undionly.kpxe using an underlying iPXE driver via the UNDI
interface) it would be helpful to be able to visually distinguish
debug messages from each binary.

Allow the range of debug colours used to be customised via the
DBGCOL=...  build parameter.  For example:

  # Restrict to colours 31-33 (red, green, yellow)
  make DBGCOL=31-33

  # Restrict to colours 34-36 (blue, magenta, cyan)
  make DBGCOL=34-36

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Expose build timestamp, build name, and product names

Expose the build timestamp (measured in seconds since the Epoch) and
the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the
product name and product short name in a single centralised location.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Allow device paths to be easily included in debug messages

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Provide a meaningful EFI SNP device name

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Restructure EFI driver model

Provide a single instance of EFI_DRIVER_BINDING_PROTOCOL (attached to
our image handle); this matches the expectations scattered throughout
the EFI specification.

Open the underlying hardware device using EFI_OPEN_PROTOCOL_BY_DRIVER
and EFI_OPEN_PROTOCOL_EXCLUSIVE, to prevent other drivers from
attaching to the same device.

Do not automatically connect to devices when being loaded as a driver;
leave this task to the platform firmware (or to the user, if loading
directly from the EFI shell).

When running as an application, forcibly disconnect any existing
drivers from devices that we want to control, and reconnect them on
exit.

Provide a meaningful driver version number (based on the build
timestamp), to allow platform firmware to automatically load newer
versions of iPXE drivers if multiple drivers are present.

Include device paths within debug messages where possible, to aid in
debugging.

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