[serial] Don't enable serial console without serial support
serial_console_init() would enable serial console support without
knowing if the serial driver succeeded or not. As a result, the
serial console would interfere with a normal keyboard on a system
lacking serial support.
Reported-by: Jan ONDREJ (SAL) <ondrejj(at)salstar.sk>
Signed-off-by: Shao Miller <sha0.miller@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tls] Split received records over multiple I/O buffers
TLS servers are not obliged to implement the RFC3546 maximum fragment
length extension, and many common servers (including OpenSSL, as used
in Apache's mod_ssl) do not do so. iPXE may therefore have to cope
with TLS records of up to 16kB. Allocations for 16kB have a
non-negligible chance of failing, causing the TLS connection to abort.
Fix by maintaining the received record as a linked list of I/O
buffers, rather than a single contiguous buffer. To reduce memory
pressure, we also decrypt in situ, and deliver the decrypted data via
xfer_deliver_iob() rather than xfer_deliver_raw().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Use a generic setting's own type as its default type
When fetching a named setting using a name that does not explicitly
specify a type, default to using the type stored when the setting was
created, rather than always defaulting to "string". This allows the
behaviour of user-defined settings to match the behaviour of
predefined settings (which have a sensible default type).
For example:
set server:ipv4 192.168.0.1
echo ${server}
will now print "192.168.0.1", rather than trying to print out the raw
IPv4 address bytes as a string.
The downside of this change is that existing tricks for printing
special characters within scripts may require (backwards-compatible)
modification. For example, the "clear screen" sequence:
set esc:hex 1b
set cls ${esc}[2J
echo ${cls}
will now have to become
set esc:hex 1b
set cls ${esc:string}[2J # Must now explicitly specify ":string"
echo ${cls}
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ipoib] Expose Ethernet-compatible eIPoIB link-layer addresses and headers
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>
[malloc] Allow allocation of memory with a specified alignment offset
Allow for allocation of memory blocks having a specified offset from a
specified physical alignment, such as being 12 bytes before a 2kB
boundary.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Standardise #include guard in ipxe_download.h
The script include/ipxe/efi/import.pl relies on a particular format
for the #include guard in order to detect EFI headers that are not
imported.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
A window size of 256kB should be sufficient to allow for
full-bandwidth transfers over a Gigabit LAN, and for acceptable
transfer speeds over other typical links.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Discarding the active ARP cache entry in the middle of a download will
substantially disrupt the TCP stream. Try to minimise any such
disruption by treating ARP cache entries as expensive, and discarding
them only when nothing else is available to discard.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[iobuf] Relax alignment requirement for small I/O buffers
iPXE currently aligns all I/O buffers on a 2kB boundary. This is
overkill for transmitted packets, which are typically much smaller
than 2kB.
Align I/O buffers on their own size. This reduces the alignment
requirement for small buffers, while preserving the guarantee that I/O
buffers will never cross boundaries that might cause problems for some
DMA engines.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tls] Request a maximum fragment length of 2048 bytes
The default maximum plaintext fragment length for TLS is 16kB, which
is a substantial amount of memory for iPXE to have to allocate for a
temporary decryption buffer.
Reduce the memory footprint of TLS connections by requesting a maximum
fragment length of 2kB.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The maximum unscaled TCP window (64kB) implies a maximum bandwidth of
around 300kB/s on a WAN link with an RTT of 200ms. Add support for
the TCP window scaling option to remove this upper limit.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tcpip] Allow for architecture-specific TCP/IP checksum routines
Calculating the TCP/IP checksum on received packets accounts for a
substantial fraction of the response latency.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Allow an error margin on X.509 certificate validity periods
iPXE has no concept of the local time zone, mainly because there is no
viable way to obtain time zone information in the absence of local
state. This causes potential problems with newly-issued certificates
and certificates that are about to expire.
Avoid such problems by allowing an error margin of around 12 hours on
certificate validity periods, similar to the error margin already
allowed for OCSP response timestamps.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[dhcp] Request broadcast responses when we already have an IPv4 address
FCoE requires the use of multiple local unicast link-layer addresses.
To avoid the complexity of managing multiple addresses, iPXE operates
in promiscuous mode. As a consequence, any unicast packets with
non-matching IPv4 addresses are rejected at the IPv4 layer (rather
than at the link layer).
This can cause problems when issuing a second DHCP request: if the
address chosen by the DHCP server does not match the existing address,
then the DHCP response will itself be rejected.
Fix by requesting a broadcast response from the DHCP server if the
network interface already has any IPv4 addresses.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE is fundamentally asynchronous in operation: some operations
continue in the background even after the foreground has continued to
a new task. For example, the closing FIN/ACK exchanges of a TCP
connection will take place in the background after an HTTP download
has completed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown