aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-08[dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACKcleardhcpMichael Brown1-0/+6
When a DHCP transaction does not result in the registration of a new "proxydhcp" or "pxebs" settings block, any existing settings blocks are currently left unaltered. This can cause surprising behaviour. For example: when chainloading iPXE, the "proxydhcp" and "pxebs" settings blocks may be prepopulated using cached values from the previous PXE bootloader. If iPXE performs a subsequent DHCP request, then the DHCP or ProxyDHCP servers may choose to respond differently to iPXE. The response may choose to omit the ProxyDHCP or PXEBS stages, in which case no new "proxydhcp" or "pxebs" settings blocks may be registered. This will result in iPXE using a combination of both old and new DHCP responses. Fix by assuming that a successful DHCPACK effectively acquires ownership of the "proxydhcp" and "pxebs" settings blocks, and that any existing settings blocks should therefore be unregistered. Reported-by: Henry Tung <htung@palantir.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-03-07[image] Always unregister currently executing imageMichael Brown5-29/+10
We unregister script images during their execution, to prevent a "boot" command from re-executing the containing script. This also has the side effect of preventing executing scripts from showing up within the Linux magic initrd image (or the Multiboot module list). Additional logic in bzimage.c and efi_file.c prevents a currently executing kernel from showing up within the magic initrd image. Similar logic in multiboot.c prevents the Multiboot kernel from showing up as a Multiboot module. This still leaves some corner cases that are not covered correctly. For example: when using a gzip-compressed kernel image, nothing will currently hide the original compressed image from the magic initrd. Fix by moving the logic that temporarily unregisters the current image from script_exec() to image_exec(), so that it applies to all image types, and simplify the magic initrd and Multiboot module list construction logic on the basis that no further filtering of the registered image list is necessary. This change has the side effect of hiding currently executing EFI images from the virtual filesystem exposed by iPXE. For example, when using iPXE to boot wimboot, the wimboot binary itself will no longer be visible within the virtual filesystem. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-03-06[image] Consistently use for_each_image() to iterate over imagesMichael Brown2-2/+2
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-03-05[intelx] Add PCI IDs for Intel 82599 10GBASE-T NICForest Crossman1-0/+1
Signed-off-by: Forest Crossman <cyrozap@gmail.com>
2023-03-01[params] Allow for arbitrary HTTP request headers to be specifiedMichael Brown5-15/+73
Extend the request parameter mechanism to allow for arbitrary HTTP headers to be specified via e.g.: params param --header Referer http://www.example.com imgfetch http://192.168.0.1/script.ipxe##params Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-03-01[params] Rename "form parameter" to "request parameter"Michael Brown7-29/+29
Prepare for the parameter mechanism to be generalised to specifying request parameters that are passed via mechanisms other than an application/x-www-form-urlencoded form. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-03-01[http] Use POST method only if the form parameter list is non-emptyMichael Brown1-44/+32
An attempt to use an existent but empty form parameter list will currently result in an invalid POST request since the Content-Length header will be missing. Fix by using GET instead of POST if the form parameter list is empty. This is a non-breaking change (since the current behaviour produces an invalid request), and simplifies the imminent generalisation of the parameter list concept to handle both header and form parameters. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-28[efi] Omit EFI_LOAD_FILE2_PROTOCOL for a zero-length initrdnoinitrdMichael Brown1-2/+11
When the Linux kernel is being used with no initrd, iPXE will still provide a zero-length initrd.magic file within the virtual filesystem. As of commit 6a004be ("[efi] Support the initrd autodetection mechanism in newer Linux kernels"), this zero-length file will also be exposed via an EFI_LOAD_FILE2_PROTOCOL instance on a handle with a fixed device path. The correct handling of zero-length files via EFI_LOAD_FILE2_PROTOCOL is unfortunately not well defined. Linux expects the first call to LoadFile() to always fail with EFI_BUFFER_TOO_SMALL. When the initrd is genuinely zero-length, iPXE will return success since the buffer is not too small to hold the (zero-length) file. This causes Linux to immediately report a spurious EFI_LOAD_ERROR boot failure. We could change the logic in iPXE's efi_file_load() to always return EFI_BUFFER_TOO_SMALL if Buffer is NULL on entry. Since the correct behaviour of LoadFile() in the corner case of a zero-length file is left undefined by the UEFI specification, this would be permissible. Unfortunately this approach would not fix the problem. If we return EFI_BUFFER_TOO_SMALL and set the file length to zero, then Linux will call the boot services AllocatePages() method with a zero length. In at least the EDK2 implementation, this combination of parameters will cause AllocatePages() to return EFI_OUT_OF_RESOURCES, and Linux will again report a boot failure. Another approach would be to install the initrd device path handle only if we have a non-empty initrd to offer. Unfortunately this would lead to a failure in yet another corner case: if a previous bootloader has installed an initrd device path handle (e.g. to pass a boot script to iPXE) then we must not leave that initrd in place, since then our loaded kernel would end up seeing the wrong initrd content. The cleanest fix seems to be to ensure that the initrd device path handle is installed with the EFI_DEVICE_PATH_PROTOCOL instance present but with the EFI_LOAD_FILE2_PROTOCOL instance absent (and forcibly uninstalled if necessary), matching the state in which we leave the handle after uninstalling our virtual filesystem. Linux will then not find any handle that supports EFI_LOAD_FILE2_PROTOCOL within the fixed device path, and so will fall through to trying other mechanisms to locate the initrd. Reported-by: Chris Bradshaw <cwbshaw@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-20[efi] Split out EFI_RNG_PROTOCOL as a separate entropy sourceMichael Brown5-92/+130
Commit 7ca801d ("[efi] Use the EFI_RNG_PROTOCOL as an entropy source if available") added EFI_RNG_PROTOCOL as an alternative entropy source via an ad-hoc mechanism specific to efi_entropy.c. Split out EFI_RNG_PROTOCOL to a separate entropy source, and allow the entropy core to handle the selection of RDRAND, EFI_RNG_PROTOCOL, or timer ticks as the active source. The fault detection logic added in commit a87537d ("[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementations") may be removed completely, since the failure will already be detected by the generic ANS X9.82-mandated repetition count test and will now be handled gracefully by the entropy core. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-20[rng] Allow for entropy sources that fail during startup testsMichael Brown3-159/+349
Provide per-source state variables for the repetition count test and adaptive proportion test, to allow for the situation in which an entropy source can be enabled but then fails during the startup tests, thereby requiring an alternative entropy source to be used. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-20[tables] Allow any lvalue to be used as a table iteratorMichael Brown1-12/+12
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-17[rng] Allow entropy source to be selected at runtimeMichael Brown18-591/+512
As noted in commit 3c83843 ("[rng] Check for several functioning RTC interrupts"), experimentation shows that Hyper-V cannot be trusted to reliably generate RTC interrupts. (As noted in commit f3ba0fb ("[hyperv] Provide timer based on the 10MHz time reference count MSR"), Hyper-V appears to suffer from a general problem in reliably generating any legacy interrupts.) An alternative entropy source is therefore required for an image that may be used in a Hyper-V Gen1 virtual machine. The x86 RDRAND instruction provides a suitable alternative entropy source, but may not be supported by all CPUs. We must therefore allow for multiple entropy sources to be compiled in, with the single active entropy source selected only at runtime. Restructure the internal entropy API to allow a working entropy source to be detected and chosen at runtime. Enable the RDRAND entropy source for all x86 builds, since it is likely to be substantially faster than any other source. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-16[iscsi] Limit maximum transfer size to MaxBurstLengthiscsicapMichael Brown3-4/+77
We currently specify only the iSCSI default value for MaxBurstLength and ignore any negotiated value, since our internal block device API allows only for receiving directly into caller-allocated buffers and so we have no intrinsic limit on burst length. A conscientious target may however refuse to attempt a transfer that we request for a number of blocks that would exceed the negotiated maximum burst length. Fix by recording the negotiated maximum burst length and using it to limit the maximum number of blocks per transfer as reported by the SCSI layer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-15[rng] Add RDRAND as an entropy sourcerdrandMichael Brown5-0/+141
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-15[efi] Support the initrd autodetection mechanism in newer Linux kernelsefiinitrdMichael Brown1-0/+190
Linux 5.7 added the ability to autodetect an initrd by searching for a handle via a fixed vendor-specific "Linux initrd device path" and then locating and using the EFI_LOAD_FILE2_PROTOCOL instance on that handle. This maps quite naturally onto our existing concept of a "magic initrd" as introduced for EFI in commit e5f0255 ("[efi] Provide an "initrd.magic" file for use by UEFI kernels"). Add an EFI_LOAD_FILE2_PROTOCOL instance to our EFI virtual files (backed by simply calling the existing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL method to read from the file), and install the protocol instance for the "initrd.magic" virtual file onto a new device handle that also provides the Linux initrd device path. The design choice in Linux of using a single fixed device path makes this unfortunately messy to support, since device paths must be unique within a system. When multiple bootloaders are used (e.g. GRUB loading iPXE loading Linux) then only one bootloader can ever install the device path onto a handle. Subsequent bootloaders must locate the existing handle and replace the load file protocol instance with their own. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-15[efi] Fix debug message when reading from EFI virtual filesMichael Brown1-1/+1
Show the requested range when a caller reads from a virtual file via the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-14[image] Check delimiters when parsing command-line key-value argumentsMichael Brown4-28/+50
The Linux kernel bzImage image format and the CPIO archive constructor will parse the image command line for certain arguments of the form "key=value". This parsing is currently implemented using strstr() in a way that can cause a false positive suffix match. For example, a command line containing "highmem=<n>" would erroneously be treated as containing a value for "mem=<n>". Fix by centralising the logic used for parsing such arguments, and including a check that the argument immediately follows a whitespace delimiter (or is at the start of the string). Reported-by: Filippo Giunchedi <filippo@esaurito.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-11[rng] Check for several functioning RTC interruptsMichael Brown1-3/+11
Commit 74222cd ("[rng] Check for functioning RTC interrupt") added a check that the RTC is capable of generating interrupts via the legacy PIC, since this mechanism appears to be broken in some Hyper-V virtual machines. Experimentation shows that the RTC is sometimes capable of generating a single interrupt, but will then generate no subsequent interrupts. This currently causes rtc_entropy_check() to falsely detect that the entropy gathering mechanism is functional. Fix by checking for several RTC interrupts before declaring that it is a functional entropy source. Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-10[eisa] Check for system board presence before probing for slotseisaMichael Brown1-0/+8
EISA expansion slot I/O port addresses overlap space that may be assigned to PCI devices, which can lead to register reads and writes with unwanted side effects during EISA probing. Reduce the chances of performing EISA probing on PCI devices by probing EISA slot vendor and product ID registers only if the EISA system board vendor ID register indicates that the motherboard supports EISA. Debugged-by: Václav Ovsík <vaclav.ovsik@gmail.com> Tested-by: Václav Ovsík <vaclav.ovsik@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-06[loong64] Add initial support for LoongArch64Xiaotian Wu35-0/+1539
Add support for building a LoongArch64 Linux userspace binary. Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-06[test] Include build architecture in test suite bannerMichael Brown1-1/+1
The test suites for the various architectures are often run back to back, and there is currently nothing to visually distinguish one test run from another. Include the architecture name within the self-test startup banner, to aid in visual identification of test results. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-06[ci] Cache downloaded packages for GitHub actionsMichael Brown1-0/+49
Speed up the "Install packages" step for each CI run by caching the downloaded packages in /var/cache/apt. Do not include libc6-dbg:i386 within the cache, since apt seems to complain if asked to download both gcc-aarch64-linux-gnu and libc6-dbg:i386 at the same time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-06[ioapi] Move PAGE_SHIFT to bits/io.hMichael Brown4-6/+6
The PAGE_SHIFT definition is an architectural property, rather than an aspect of a particular I/O API implementation (of which, in theory, there may be more than one per architecture). Reflect this by moving the definition to the top-level bits/io.h for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-05[build] Allow for per-architecture unprefixed constant operand modifierMichael Brown5-2/+14
Over the years, the undocumented operand modifier used to produce the unprefixed constant values in __einfo_error() has varied from "%c0" to "%a0" in commit 1a77466 ("[build] Fix use of inline assembly on GCC 4.8 ARM64 builds") and back to "%c0" in commit 3fb3ffc ("[build] Fix use of inline assembly on GCC 8 ARM64 builds"), according to the evolving demands of the toolchain. LoongArch64 suffers from a similar issue: GCC 13 will allow either, but the currently released GCC 12 allows only the "%a0" form. Introduce a macro ASM_NO_PREFIX, defined in bits/compiler.h, to abstract away this difference and allow different architectures to use different operand modifiers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-05[xen] Allow for platforms that have no Xen supportMichael Brown3-1/+81
The Xen headers support only x86 and ARM. Allow for platforms such as LoongArch64 to build despite the absence of Xen support by providing an architecture-specific <bits/xen.h> that simply does: #ifndef _BITS_XEN_H #define _BITS_XEN_H #include <ipxe/nonxen.h> #endif /* _BITS_XEN_H */ Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-05[efi] Enable NET_PROTO_LLDP by defaultMichael Brown2-1/+2
Requested-by: Christian I. Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-05[lldp] Add support for the Link Layer Discovery ProtocollldpMichael Brown6-0/+443
Add support for recording LLDP packets and exposing TLV values via the settings mechanism. LLDP settings are encoded as ${netX.lldp/<prefix>.<type>.<index>.<offset>.<length>} where <type> is the TLV type <offset> is the starting offset within the TLV value <length> is the length (or zero to read the from <offset> to the end) <prefix>, if it has a non-zero value, is the subtype byte string of length <offset> to match at the start of the TLV value, up to a maximum matched length of 4 bytes <index> is the index of the entry matching <type> and <prefix> to be accessed, with zero indicating the first matching entry The <prefix> is designed to accommodate both matching of the OUI within an organization-specific TLV (e.g. 0x0080c2 for IEEE 802.1 TLVs) and of a subtype byte as found within many TLVs. This encoding allows most LLDP values to be extracted easily. For example System name: ${netX.lldp/5.0.0.0:string} System description: ${netX.lldp/6.0.0.0:string} Port description: ${netX.lldp/4.0.0.0:string} Port interface name: ${netX.lldp/5.2.0.1.0:string} Chassis MAC address: ${netX.lldp/4.1.0.1.0:hex} Management IPv4 address: ${netX.lldp/5.1.8.0.2.4:ipv4} Port VLAN ID: ${netX.lldp/0x0080c2.1.127.0.4.2:int16} Port VLAN name: ${netX.lldp/0x0080c2.3.127.0.7.0:string} Maximum frame size: ${netX.lldp/0x00120f.4.127.0.4.2:uint16} Originally-implemented-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-03[ci] Update to ubuntu-22.04 GitHub actions runnerubuntu2204Michael Brown2-4/+4
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-03[dhcp] Ignore DHCPNAK unless originating from the selected DHCP serverdhcpnakMichael Brown1-2/+4
RFC 2131 leaves undefined the behaviour of the client in response to a DHCPNAK that comes from a server other than the selected DHCP server. A substantial amount of online documentation suggests using multiple independent DHCP servers with non-overlapping ranges in the same subnet in order to provide some minimal redundancy. Experimentation shows that in this setup, at least ISC dhcpd will send a DHCPNAK in response to the client's DHCPREQUEST for an address that is not within the range defined on that server. (Since the requested address does lie within the subnet defined on that server, this will happen regardless of the "authoritative" parameter.) The client will therefore receive a DHCPACK from the selected DHCP server along with one or more DHCPNAKs from each of the non-selected DHCP servers. Filter out responses from non-selected DHCP servers before checking for a DHCPNAK, so that these arguably spurious DHCPNAKs will not cause iPXE to return to the discovery state. Continue to check for DHCPNAK before filtering out responses for non-selected lease addresses, since experimentation shows that the DHCPNAK will usually have an empty yiaddr field. Reported-by: Anders Blomdell <anders.blomdell@control.lth.se> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-03[efi] Do not attempt to drive PCI bridge devicesefibridgeMichael Brown3-0/+13
The "bridge" driver introduced in 3aa6b79 ("[pci] Add minimal PCI bridge driver") is required only for BIOS builds using the ENA driver, where experimentation shows that we cannot rely on the BIOS to fully assign MMIO addresses. Since the driver is a valid PCI driver, it will end up binding to all PCI bridge devices even on a UEFI platform, where the firmware is likely to have completed MMIO address assignment correctly. This has no impact on most systems since there is generally no UEFI driver for PCI bridges: the enumeration of the whole PCI bus is handled by the PciBusDxe driver bound to the root bridge. Experimentation shows that at least one laptop will freeze at the point that iPXE attempts to bind to the bridge device. No deeper investigation has been carried out to find the root cause. Fix by causing efipci_supported() to return an error unless the configuration space header type indicates a non-bridge device. Reported-by: Marcel Petersen <mp@sbe.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-03[util] Add support for LoongArch64 binariesloongarch64Xiaotian Wu3-0/+38
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-03[ci] Update to actions/checkout@v3 to silence GitHub warningsnodejsMichael Brown2-4/+4
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-02[xen] Update to current Xen headersxenMichael Brown19-874/+2901
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-01[efi] Allow autoexec script to be located alongside iPXE binaryautoexecpathMichael Brown3-22/+75
Try loading the autoexec.ipxe script first from the directory containing the iPXE binary (based on the relative file path provided to us via EFI_LOADED_IMAGE_PROTOCOL), then fall back to trying the root directory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-01[realtek] Explicitly disable VLAN offloadMichael Brown2-2/+7
Some cards seem to have the receive VLAN tag stripping feature enabled by default, which causes received VLAN packets to be misinterpreted as being received by the trunk device. Fix by disabling VLAN tag stripping in the C+ Command Register. Debugged-by: Xinming Lai <yiyihu@gmail.com> Tested-by: Xinming Lai <yiyihu@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-02-01[efi] Update to current EDK2 headersMichael Brown2-12/+12
Update to pick up the upstream commit bda715b ("MdePkg: Fix UINT64 and INT64 word length for LoongArch64"). Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-31[tests] Verify ability to sleep the CPUnaptestMichael Brown2-0/+54
The self-test suite does not currently ever attempt to sleep the CPU. This is an operation that may fail (e.g. by attempting to execute a privileged instruction while running as a Linux userspace binary, or by halting the CPU with all interrupts disabled). Add a trivial self-test to exercise the ability to sleep the CPU without crashing or halting forever. Inspired-by: Xiaotian Wu <wuxiaotian@loongson.cn> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-31[dhcp] Add IANA-defined values for all current EFI client architecturesMichael Brown1-2/+21
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-29[efi] Accept a command line passed to an iPXE image via LoadOptionseficmdlineMichael Brown4-0/+175
Treat a command line passed to iPXE via UEFI LoadOptions as an image to be registered at startup, as is already done for the .lkrn, .pxe, and .exe BIOS images. Originally-implemented-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[la64] Import LoongArch64 ProcessorBind.h from EDK2 headersMichael Brown3-2/+128
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[efi] Update to current EDK2 headersMichael Brown95-15321/+14255
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[efi] Mark ConsoleControl.h as a non-imported headerMichael Brown1-0/+5
The obsolete ConsoleControl.h header is no longer present in the current EDK2 codebase, but is still required for interoperability with old iMacs. Add an iPXE include guard to this file so that the EDK2 header import script will no longer attempt to import it from the EDK2 tree. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[efi] Remove deleted directories from EDK2 header import scriptMichael Brown1-2/+1
The IntelFrameworkPkg and EdkCompatibilityPkg directories have been removed from the EDK2 codebase. Remove these directories from the EDK2 header import script. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[efi] Allow for whitespace before #include in imported EDK2 header filesMichael Brown1-1/+1
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[efi] Detect SPDX licence identifiers in imported EDK2 headersMichael Brown1-2/+2
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[legal] Add missing FILE_LICENCE declaration to efi_path.cMichael Brown1-0/+2
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[legal] Add support for the BSD-2-Clause-Patent licenceMichael Brown2-0/+61
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-28[efi] Build util/efirom as a host-only binaryMichael Brown2-0/+5
As with util/elf2efi32 and util/elf2efi64 in commit a99e435 ("[efi] Do not rely on ProcessorBind.h when building host binaries"), build util/efirom without using any architecture-specific EDK2 headers since the build host's CPU architecture may not be supported by EDK2. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-25[tcp] Update maximum window size to 2MBMichael Brown1-6/+12
The current maximum window size of 256kB was calculated based on rough link bandwidth and RTT measurements taken in 2012, and is too small to avoid filling the TCP window on some modern links. Update the list of typical link bandwidth and RTT figures to reflect the modern world, and increase the maximum window size accordingly. Signed-off-by: Michael Brown <mcb30@ipxe.org>
2023-01-25[pxe] Discard queued PXE UDP packets when under memory pressureMichael Brown1-0/+26
The PXE UDP receive queue may grow without limit if the PXE NBP does not call PXENV_UDP_READ sufficiently frequently. Fix by implementing a cache discarder for received PXE UDP packets (similar to the TCP cache discarder). Reported-by: Tal Shorer <shorer@amazon.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>