openslx-ng/ipxe.git/src/net/udp, branch openslx

[build] Mark known reviewed files as permitted for UEFI Secure Boot

2026-01-14T16:10:29+00:00

Some past security reviews carried out for UEFI Secure Boot signing submissions have covered specific drivers or functional areas of iPXE. Mark all of the files comprising these areas as permitted for UEFI Secure Boot. Signed-off-by: Michael Brown

[build] Mark core files as permitted for UEFI Secure Boot

2026-01-14T13:25:34+00:00

Mark all files used in a standard build of bin-x86_64-efi/snponly.efi as permitted for UEFI Secure Boot. These files represent the core functionality of iPXE that is guaranteed to have been included in every binary that was previously subject to a security review and signed by Microsoft. It is therefore legitimate to assume that at least these files have already been reviewed to the required standard multiple times. Signed-off-by: Michael Brown

[ipv4] Add support for classless static routes

2025-06-10T17:22:32+00:00

Add support for RFC 3442 classless static routes provided via DHCP option 121. Originally-implemented-by: Hazel Smith Originally-implemented-by: Raphael Pour Signed-off-by: Michael Brown

[uaccess] Remove redundant copy_from_user() and copy_to_user()

2025-04-30T14:32:03+00:00

Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown

[ipv6] Expose router address for DHCPv6 leased addresses

2024-06-27T12:43:37+00:00

The DHCPv6 protocol does not itself provide a router address or a prefix length. This information is instead obtained from the router advertisements. Our IPv6 minirouting table construction logic will first construct an entry for each advertised prefix, and later update the entry to include an address assigned within that prefix via stateful DHCPv6 (if applicable). This logic fails if the address assigned via stateful DHCPv6 does not fall within any of the advertised prefixes (e.g. if the network is configured to use DHCPv6-assigned /128 addresses with no advertised on-link prefixes). We will currently treat this situation as equivalent to having a manually assigned address with no corresponding router address or prefix length: the routing table entry will use the default /64 prefix length and will not include the router address. DHCPv6 is triggered only in response to a router advertisement with the "Managed Address Configuration (M)" or "Other Configuration (O)" flags set, and a router address is therefore available at the point that we initiate DHCPv6. Record the router address when initiating DHCPv6, and expose this router address as part of the DHCPv6 settings block. This allows the routing table entry for any address assigned via stateful DHCPv6 to correctly include the router address, even if the assigned address does not fall within an advertised prefix. Also provide a fixed /128 prefix length as part of the DHCPv6 settings block. When an address assigned via stateful DHCPv6 does not fall within an advertised prefix, this will cause the routing table entry to have a /128 prefix length as expected. (When such an address does fall within an advertised prefix, it will continue to use the advertised prefix length.) Originally-fixed-by: Guvenc Gulce Signed-off-by: Michael Brown

[tftp] Add error table entry for TFTP "file not found" error code

2024-03-29T14:46:13+00:00

Add an abbreviated "Not found" error message for a TFTP "file not found" error code, so that any automatic attempt to download a non-existent autoexec.ipxe script produces only a minimal error message. Signed-off-by: Michael Brown

[dhcp] Request NTP server option

2023-07-19T10:13:52+00:00

Signed-off-by: Michael Brown

[ntp] Define NTP server setting

2023-07-19T10:10:15+00:00

Define the IPv4 NTP server setting to simplify the use of a DHCP-provided NTP server in scripts, using e.g. #!ipxe dhcp ntp ${ntp} Signed-off-by: Michael Brown

[dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACK

2023-03-14T11:35:30+00:00

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 Signed-off-by: Michael Brown

[dhcp] Ignore DHCPNAK unless originating from the selected DHCP server

2023-02-03T19:51:58+00:00

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 Signed-off-by: Michael Brown