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

With the addition of link status codes, we can now display a detailed
error indication if iflinkwait() fails.

Putting the error output in iflinkwait avoids code duplication, and
gains symmetry with the other interface management routines; ifopen()
already prints an error directly if it cannot open its interface.

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

Expand the NETDEV_LINK_UP bit into a link_rc status code field,
allowing specific reasons for link failure to be reported via
"ifstat".

Originally-authored-by: Joshua Oreman <oremanj@rwcr.net>

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

The Symantec UNDI DOS driver fails when run on top of gPXE because we
return our interface type as "gPXE" rather than one of the predefined
NDIS interface type strings.

Fix by returning the standard "DIX+802.3" string; this isn't
necessarily always accurate, but it's highly unlikely that anything
trying to use the UNDI API would understand our IPoIB link-layer
pseudo-header anyway.

The Intel DOS UNDI driver fails when run on top of gPXE because we do
not fill in the ServiceFlags field in PXENV_UNDI_GET_IFACE_INFO.

Fix by filling in the ServiceFlags field with reasonable values
indicating our approximate feature capabilities.

The 3Com DOS UNDI driver fails when run on top of gPXE for two
reasons: firstly because PXENV_UNDI_SET_PACKET_FILTER is unsupported,
and secondly because gPXE enters the NBP without enabling interrupts
on the NIC, and the 3Com driver never calls PXENV_UNDI_OPEN.

Fix by always returning success from PXENV_UNDI_SET_PACKET_FILTER
(which is no worse than the current situation, since we already ignore
the receive packet filter in PXENV_UNDI_OPEN), and by forcibly
enabling interrupts on the NIC within PXENV_UNDI_TRANSMIT.  The latter
is something of a hack, but avoids the need to implement a complete
base-code ISR that we would otherwise need if we were to enter the NBP
with interrupts enabled.

Reported-by: Mark McLoughlin <markmc@redhat.com>

Commit 558c1a4 ("[tcp] Improve robustness in the presence of duplicated
received packets") introduced a regression in that an old duplicate
ACK received while in the ESTABLISHED state would pass through normal
ACK processing, including updating tcp->snd_seq.

Fix by ensuring that ACK processing ignores all duplicate ACKs.

All TCP errors or unusual events should now generate a debugging
message at DBGLVL_LOG, with enough information (SEQ and ACK numbers)
to be able to identify the corresponding packet (or missing packet) in
a network trace from the remote end.

This makes it possible to leave TCP debugging enabled in order to see
interesting TCP events, without flooding the console with at least one
message per packet.

This resolves potential difficulties occurring when more than one script
is used. Total cost: 88 bytes uncompressed.

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

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

In order to construct outgoing link-layer frames or parse incoming
ones properly, some protocols (such as 802.11) need more state than is
available in the existing variables passed to the link-layer protocol
handlers. To remedy this, add struct net_device *netdev as the first
argument to each of these functions, so that more information can be
fetched from the link layer-private part of the network device.

Updated all three call sites (netdevice.c, efi_snp.c, pxe_undi.c) and
both implementations (ethernet.c, ipoib.c) of ll_protocol to use the
new argument.

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

The 93C66 is identical to the 93C56 in programming interface and
addressing, but twice as large in data storage (4096 bits). It's
used in some RTL8185 wireless cards.

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

gPXE responds to duplicated ACKs with an immediate retransmission,
which can lead to a sorceror's apprentice syndrome.  It also responds
to out-of-range (or old duplicate) ACKs with a RST, which can cause
valid connections to be dropped.

Fix the sorceror's apprentice syndrome by leaving the retransmission
timer running (and so inhibiting the immediate retransmission) when we
receive a potential duplicate ACK.  This seems to match the behaviour
of Linux observed via wireshark traces.

Fix the RST issue by sending RST only on out-of-range ACKs that occur
before the connection is fully established, as per RFC 793.

These problems were exposed during development of the 802.11 wireless
link layer; the 802.11 protocol has a failure mode that can easily
cause duplicated packets.  The fixes were tested in a controlled way
by faking large numbers of duplicated packets in the rtl8139 driver.

Originally-fixed-by: Joshua Oreman <oremanj@rwcr.net>

setting_cmp() compares by option tag and then by name.  Empty names
will always match, which gives us a false positive.

Fix by explicitly checking for empty names.

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

MAX_LL_HEADER_LEN is erroneously set to 6 rather than 14, resulting
in possible data corruption whenever we send an ARP packet.

Fix value and add a comment explaining why MAX_LL_ADDR_LEN is greater
than MAX_LL_HEADER_LEN.

Reported-by: Joshua Oreman <oremanj@rwcr.net>

Windows text editors such as Notepad tend to use CRLF line endings,
which breaks gPXE's signature detection for script images.  Since
scripts are usually very small, they end up falling back to being
detected as valid PXE executable images (since there are no signature
checks for PXE executables).  Executing text files as x86 machine code
tends not to work well.

Fix by allowing for any isspace() character to terminate the "#!gpxe"
signature, and by ensuring that CR characters get stripped during
command line parsing.

Suggested-by: Shao Miller <Shao.Miller@yrdsb.edu.on.ca>

Several SPI chips will respond to an SPI read command with a dummy
zero bit immediately prior to the first real data bit.  This can be
used to autodetect the address length, provided that the command
length and data length are already known, and that the MISO data line
is tied high.

Tested-by: Thomas Miletich <thomas.miletich@gmail.com>
Debugged-by: Thomas Miletich <thomas.miletich@gmail.com>

gcc 4.4 defaults to using .cfi assembler directives for debugging
information, which causes unneeded .eh_frame sections to be generated.
These sections are already stripped out by our linker script, so don't
affect the final build, but do distort the output of "size" when run
on individual .o files; the .eh_frame size is included within the size
reported for .text.  This makes it difficult to accurately judge the
effects of source code changes upon object code size.

Fix by adding -fno-dwarf2-cfi-asm to CFLAGS if we detect that this
option is supported by the gcc that we are compiling with.

Tested-by: Daniel Verkamp <daniel@drv.nu>

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

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

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

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

This provides a mechanism for using arbitrarily-named variables within
gPXE, using the existing syntax for settings.

Grub will include the module name as part of the command line, and
some multiboot kernels expect this to be done.

If the ProxyDHCPOFFER already includes PXE options (i.e. option 60 is
set to "PXEClient" and option 43 is present) then assume that the
ProxyDHCPREQUEST can be sent to port 67, rather than port 4011.  This
is a reasonable assumption, since in that case the ProxyDHCP server
has already demonstrated by responding to the DHCPDISCOVER that it is
listening on port 67.  (If the ProxyDHCP server were not listening on
port 67, then the standard DHCP server would have been configured to
respond with option 60 set to "PXEClient" but no option 43 present.)

The PXE specification is ambiguous on this point; the specified
behaviour covers only the cases in which option 43 is *not* present in
the ProxyDHCPOFFER.  In these cases, we will continue to send the
ProxyDHCPREQUEST to port 4011.

This change is required in order to allow us to interoperate with
dnsmasq, which listens only on port 67.  (dnsmasq relies on
unspecified behaviour of the Intel PXE stack, which it seems will
retain the ProxyDHCPOFFER as an options source and never issue a
ProxyDHCPREQUEST, thereby enabling dnsmasq to omit listening on port
4011.)

Tested with COM1 and COM2.

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

IBM Tivoli PXE Server 5.1.0.3 is reported to send trailing garbage
bytes at the end of the OACK packet, which causes gPXE to reject the
packet and abort the TFTP transfer.

Work around the problem by processing as much as possible of the OACK,
and treating name/value parsing errors as non-fatal.

Reported-by: Shao Miller <Shao.Miller@yrdsb.edu.on.ca>

We currently send all boot server discovery requests to port 4011.
Section 2.2.1 of the PXE spec states that boot server discovery
packets should be "sent broadcast (port 67), multicast (port 4011), or
unicast (port 4011)".  Adjust our behaviour so that any boot server
discovery packets that are sent to the broadcast address are directed
to port 67 rather than port 4011.

This is required for operation with dnsmasq as a PXE server, since
dnsmasq listens only on port 67, and relies upon this (specified)
behaviour.

This change may break some setups using the (itself very broken) Linux
PXE server from kano.org.uk.  This server will, in its default
configuration, listen only on port 4011.  It never constructs a boot
server list (PXE_BOOT_SERVERS, option 43.8), and uses the wrong
definitions for the discovery control bits (PXE_DISCOVERY_CONTROL,
option 43.6).  The upshot is that it will always instruct the client
to perform multicast and broadcast discovery only.  In setups lacking
a valid multicast route on the server side, this used to work because
gPXE would eventually give up on the (non-responsive) multicast
address and send a broadcast request to port 4011, which the Linux PXE
server would respond to.  Now that gPXE correctly sends this broadcast
request to port 67 instead, it is never seen by the Linux PXE server,
and the boot fails.  The fix is to either (a) set up a multicast route
correctly on the server side before starting the PXE server, or (b)
edit /etc/pxe.conf to contain the server's unicast address in the
"multicast_address" field (a hack that happens to work).

Suggested-by: Simon Kelley <simon@thekelleys.org.uk>

This prevents gPXE from wasting time attempting to contact a ProxyDHCP
server on port 4011 if the DHCP response already contains the relevant
PXE options.  This behaviour is hinted at (though not explicitly
specified) in the PXE spec, and seems to match what the Intel client
does.

Suggested-by: Simon Kelley <simon@thekelleys.org.uk>

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

It is now possible to run e.g.

  make bin/rtl8139.dsk.licence

in order to see a licensing assessment for any given gPXE build.  The
assessment will either produce a single overall licence for the build
(based on combining all the licences used within the source files for
that build), or will exit with an error stating why a licence
assessment is not possible (for example, if there are files involved
that do not yet contain an explicit FILE_LICENCE() declaration).

For partly historical reasons, various files in the gPXE source tree
are licensed under different, though compatible, terms.  Most of the
code is licensed under GPLv2 with the "or later" clause, but there are
exceptions such as:

  The string.h file, which derives from Linux and is licensed as
  Public Domain.

  The EFI header files, which are taken from the EDK2 source tree and
  are licensed under BSD.

  The 3c90x driver, which has a custom GPL-like licence text.

Introduce a FILE_LICENCE() macro to make licensing more explicit.
This macro should be applied exactly once to each source (.c, .S or
.h) file.  It will cause a corresponding zero-sized common symbol to
be added to any .o files generated from that source file (and hence to
any final gPXE binaries generated from that source file).  Determining
the applicable licences to generated files can then be done using e.g.

  $ objdump -t bin/process.o | grep __licence
  00000000       O *COM*  00000001 .hidden __licence_gpl2_or_later

indicating that bin/process.o is covered entirely by the GPLv2
with the "or later" clause, or

  $ objdump -t bin/rtl8139.dsk.tmp | grep __licence
  00033e8c g     O .bss.textdata  00000000 .hidden __licence_gpl2_only
  00033e8c g     O .bss.textdata  00000000 .hidden __licence_gpl2_or_later
  00033e8c g     O .bss.textdata  00000000 .hidden __licence_public_domain

indicating that bin/rtl8139.dsk includes both code licensed under
GPLv2 (both with and without the "or later" clause) and code licensed
as Public Domain.

Determining the result of licence combinations is currently left as an
exercise for the reader.

Etherboot 5.4 erroneously treats PXENV_UNLOAD_STACK as the "final
shutdown" call, and unhooks INT15.  When using gPXE's undionly.kpxe,
this results in gPXE overwriting the portion of Etherboot located in
high memory, because it is no longer hidden from the system memory map
at the time that gPXE loads.

Work around this by explicitly testing for Etherboot as the underlying
PXE stack (as is already done in undinet.c) and skipping the call to
PXENV_UNLOAD_STACK if necessary.

Commit b149a99 ([build] Round up SUBx deltas) introduced a
signed/unsigned issue that affects gPXE images built on 32-bit hosts.
The zbin fixup utility performed an unsigned division, which led to
.usb images with an incorrect number of sectors to load.

The issue snuck by on 64-bit hosts since uint32_t is promoted to long.
On 32-bit hosts it is promoted to unsigned long.

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

NetBSD kernels are multiboot ELF kernels with an entry point
incorrectly specified as a virtual address rather than a physical
address.

Work around this by looking for the segment that could plausibly
contain the entry point address (interpreted as either a physical or
virtual address), and using that to determine the eventual physical
entry point.

In the event of any ambiguity, precedence is given to interpretation
of the entry point as a physical address.

Solaris kernels are multiboot images with the "raw" flag set,
indicating that the loader should use the raw address fields within
the multiboot header rather than looking for an ELF header.  However,
the Solaris kernel contains garbage data in the raw address fields,
and requires us to use the ELF header instead.

Work around this by always using the ELF header if present.  This
renders the "raw" flag somewhat redundant.