summaryrefslogtreecommitdiffstats
path: root/src/net/udp
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-142-0/+2
| | | | | | | | | 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 <mcb30@ipxe.org>
* [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-144-0/+4
| | | | | | | | | | | | 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 <mcb30@ipxe.org>
* [ipv4] Add support for classless static routesMichael Brown2025-06-101-1/+1
| | | | | | | | | Add support for RFC 3442 classless static routes provided via DHCP option 121. Originally-implemented-by: Hazel Smith <hazel.smith@leicester.ac.uk> Originally-implemented-by: Raphael Pour <raphael.pour@hetzner.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove redundant copy_from_user() and copy_to_user()Michael Brown2025-04-301-0/+1
| | | | | | | Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Expose router address for DHCPv6 leased addressesMichael Brown2024-06-271-16/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <guevenc.guelce@sap.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tftp] Add error table entry for TFTP "file not found" error codeMichael Brown2024-03-291-1/+10
| | | | | | | | | 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 <mcb30@ipxe.org>
* [dhcp] Request NTP server optionCornelius Hoffmann2023-07-191-3/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ntp] Define NTP server settingMichael Brown2023-07-191-0/+10
| | | | | | | | | | | 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 <mcb30@ipxe.org>
* [dhcp] Unregister ProxyDHCP and PXEBS settings on a successful DHCPACKMichael Brown2023-03-141-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>
* [dhcp] Ignore DHCPNAK unless originating from the selected DHCP serverMichael Brown2023-02-031-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>
* [dhcp] Simplify platform-specific client architecture definitionsMichael Brown2023-01-222-2/+2
| | | | | | | | | | | | | | | | Move the platform-specific DHCP client architecture definitions to header files of the form <ipxe/$(PLATFORM)/dhcparch.h>. This simplifies the directory structure and allows the otherwise unused arch/$(ARCH)/include/$(PLATFORM) to be removed from the include directory search path, which avoids the confusing situation in which a header file may potentially be accessed through more than one path. For Linux userspace binaries on any architecture, use the EFI values for that architecture by delegating to the EFI header file. This avoids the need to explicitly select values for Linux userspace binaries for each architecture. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Separate concept of scope ID from network device name indexMichael Brown2023-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | | The network device index currently serves two purposes: acting as a sequential index for network device names ("net0", "net1", etc), and acting as an opaque unique integer identifier used in socket address scope IDs. There is no particular need for these usages to be linked, and it can lead to situations in which devices are named unexpectedly. For example: if a system has two network devices "net0" and "net1", a VLAN is created as "net1-42", and then a USB NIC is connected, then the USB NIC will be named "net3" rather than the expected "net2" since the VLAN device "net1-42" will have consumed an index. Separate the usages: rename the "index" field to "scope_id" (matching its one and only use case), and assign the name without reference to the scope ID by finding the first unused name. For consistency, assign the scope ID by similarly finding the first unused scope ID. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Always start DNS queries using the first configured DNS serverMichael Brown2022-02-241-5/+4Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently define the active DNS server as a global variable. All queries will start by attempting to contact the active DNS server, and the active DNS server will be changed only if we fail to get a response. This effectively treats the DNS server list as expressing a weak preference ordering: we will try servers in order, but once we have found a working server we will stick with that server for as long as it continues to respond to queries. Some sites are misconfigured to hand out DNS servers that do not have a consistent worldview. For example: the site may hand out two DNS server addresses, the first being an internal DNS server (which is able to resolve names in private DNS domains) and the second being a public DNS server such as 8.8.8.8 (which will correctly return NXDOMAIN for any private DNS domains). This type of configuration is fundamentally broken and should never be used, since any DNS resolver performing a query for a name within a private DNS domain may obtain a spurious NXDOMAIN response for a valid private DNS name. Work around these broken configurations by treating the DNS server list as expressing a strong preference ordering, and always starting DNS queries from the first server in the list (rather than maintaining a global concept of the active server). This will have the debatable benefit of converting permanent spurious NXDOMAIN errors into transient spurious NXDOMAIN errors, which can at least be worked around at a higher level (e.g. by retrying a download in a loop within an iPXE script). The cost of always starting DNS queries from the first server in the list is a slight delay introduced when the first server is genuinely unavailable. This should be negligible in practice since DNS queries are relatively infrequent and the failover expiry time is short. Treating the DNS server list as a preference ordering is permitted by the language of RFC 2132, which defines DHCP option 6 as a list in which "[DNS] servers SHOULD be listed in order of preference". No specification defines a precise algorithm for how this preference order should be applied in practice: this new approach seems as good as any. Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Handle DHCPNAK by returning to discovery stateMichael Brown2021-03-111-9/+31
| | | | | | | | | | | | | Handle a DHCPNAK by returning to the discovery state to allow iPXE to attempt to obtain a replacement IPv4 address. Reuse the existing logic for deferring discovery when the link is blocked: this avoids hammering a misconfigured DHCP server with a non-stop stream of requests and allows the DHCP process to eventually time out and fail. Originally-implemented-by: Blake Rouse <blake.rouse@canonical.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Reduce debug verbosity for DNS server listMichael Brown2021-03-021-9/+9
| | | | | | | | | | The DNS server list is currently printed as a debug message whenever settings are applied. This can result in some very noisy debug logs when a script makes extensive use of settings. Move the DNS server list debug messages to DBGLVL_EXTRA. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tftp] Allow for profiling of client and server turnaround timesMichael Brown2021-01-221-1/+23
| | | | | | | | Provide some visibility into the turnaround times on both client and server sides as perceived by iPXE, to assist in debugging inexplicably slow TFTP transfers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Continue transmitting DHCPDISCOVER while link is blockedMichael Brown2021-01-191-12/+11Star
| | | | | | | | | Continue to transmit DHCPDISCOVER while waiting for a blocked link, in order to support mechanisms such as Cisco MAC Authentication Bypass that require repeated transmission attempts in order to trigger the action that will result in the link becoming unblocked. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Use all configured DNS serversMichael Brown2020-07-151-49/+130
| | | | | | | When no response is obtained from the first configured DNS server, fall back to attempting the other configured servers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [slam] Allow for the possibility of IPv6 multicast addressesMichael Brown2020-02-161-4/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [slam] Eliminate variable-length stack allocationMichael Brown2020-02-161-5/+19
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tftp] Eliminate unnecessary variable-length stack allocationMichael Brown2020-02-161-11/+6Star
| | | | | | | | Eliminate an unnecessary variable-length stack allocation and memory copy by allowing TFTP option processors to modify the option string in-place. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tftp] Prevent potential division by zeroMichael Brown2018-03-181-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Ensure DNS names are NUL-terminated when used as diagnostic stringsMichael Brown2017-09-071-3/+9
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Report current DNS query as job progress status messageMichael Brown2017-09-061-0/+18
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [slam] Avoid NULL pointer dereference in slam_pull_value()Michael Brown2017-03-211-5/+9
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [slam] Fix resource leak on error pathMichael Brown2017-03-211-4/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Allow vendor class to be changed in DHCP requestsMichael Brown2017-03-201-11/+23
| | | | | | | Allow the DHCPv4 vendor class to be specified via the "vendor-class" setting. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allow MTU to be changed at runtimeMichael Brown2017-01-231-3/+3
| | | | | | | | | | | | Provide a settings applicator to modify netdev->max_pkt_len in response to changes to the "mtu" setting (DHCP option 26). Note that as with MAC address changes, drivers are permitted to completely ignore any changes in the MTU value. The net result will be that iPXE effectively uses the smaller of either the hardware default MTU or the software configured MTU. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Create routing table based on IPv6 settingsMichael Brown2016-07-201-16/+1Star
| | | | | | | | | | | | | | | | | | | | | | Use the IPv6 settings to construct the routing table, in a matter analogous to the construction of the IPv4 routing table. This allows for manual assignment of IPv6 addresses via e.g. set net0/ip6 2001:ba8:0:1d4::6950:5845 set net0/len6 64 set net0/gateway6 fe80::226:bff:fedd:d3c0 The prefix length ("len6") may be omitted, in which case a default prefix length of 64 will be assumed. Multiple IPv6 addresses may be assigned manually by implicitly creating child settings blocks. For example: set net0/ip6 2001:ba8:0:1d4::6950:5845 set net0.ula/ip6 fda4:2496:e992::6950:5845 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Match user expectations for IPv6 settings prioritiesMichael Brown2016-07-191-0/+1
| | | | | | | | | | | | | | A reasonable user expectation is that ${net0/ip6} should show the "highest-priority" of the IPv6 addresses, even when multiple IPv6 addresses are active. The expected order of priority is likely to be manually-assigned addresses first, then stateful DHCPv6 addresses, then SLAAC addresses, and lastly link-local addresses. Using ${priority} to enforce an ordering is undesirable since that would affect the priority assigned to each of the net<N> blocks as a whole, so use the sibling ordering capability instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Expose IPv6 address setting acquired through DHCPv6Michael Brown2016-07-191-18/+49
| | | | | | Originally-implemented-by: Hannes Reinecke <hare@suse.de> Originally-implemented-by: Marin Hannache <git@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Rename ipv6_scope to dhcpv6_scopeMichael Brown2016-07-163-6/+6
| | | | | | | | The settings scope ipv6_scope refers specifically to IPv6 settings that have a corresponding DHCPv6 option. Rename to dhcpv6_scope to more accurately reflect this purpose. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Create space for IPv6 in settings display orderMichael Brown2016-07-151-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Automatically generate vendor class identifier stringMichael Brown2016-07-042-2/+6
| | | | | | | | | | | | The vendor class identifier strings in DHCP_ARCH_VENDOR_CLASS_ID are out of sync with the (correct) client architecture values in DHCP_ARCH_CLIENT_ARCHITECTURE. Fix by removing all definitions of DHCP_ARCH_VENDOR_CLASS_ID, and instead generating the vendor class identifier string automatically based on DHCP_ARCH_CLIENT_ARCHITECTURE and DHCP_ARCH_CLIENT_NDI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Include vendor class identifier option in DHCPv6 requestsMichael Brown2016-07-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | RFC3315 defines DHCPv6 option 16 (vendor class identifier) but does not define any direct relationship with the roughly equivalent DHCPv4 option 60. The PXE specification predates IPv6, and the UEFI specification is expectedly vague on the subject. Examination of the reference EDK2 codebase suggests that the DHCPv6 vendor class identifier will be formatted in accordance with RFC3315, using a single vendor-class-data item in which the opaque-data field is the string as would appear in DHCPv4 option 60. RFC3315 requires the vendor class identifier to specify an IANA enterprise number, as a way of disambiguating the vendor-class-data namespace. The EDK2 code uses the value 343, described as: // TODO: IANA TBD: temporarily using Intel's Since this "TODO" has been present since at least 2010, it is probably safe to assume that it has now become a de facto standard. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Include RFC5970 client architecture options in DHCPv6 requestsMichael Brown2016-07-041-17/+19
| | | | | | | | RFC5970 defines DHCPv6 options 61 (client system architecture type) and 62 (client network interface identifier), with contents equivalent to DHCPv4 options 93 and 94 respectively. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Allow for variable encapsulation of architecture-specific optionsMichael Brown2016-07-041-3/+3
| | | | | | | | | | | | | DHCPv4 and DHCPv6 share some values in common for the architecture- specific options (such as the client system architecture type), but use different encapsulations: DHCPv4 has a single byte for the option length while DHCPv6 has a 16-bit field for the option length. Move the containing DHCP_OPTION() and related wrappers from the individual dhcp_arch.h files to dhcp.c, thus allowing for the architecture-specific values to be reused in dhcpv6.c. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ntp] Add simple NTP clientMichael Brown2016-06-131-0/+275
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [slam] Avoid potential division by zeroMichael Brown2016-01-281-7/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tftp] Mangle initial slash on TFTP URIsMichael Brown2016-01-211-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TFTP URIs are intrinsically problematic, since: - TFTP servers may use either normal slashes or backslashes as a directory separator, - TFTP servers allow filenames to be specified using relative paths (with no initial directory separator), - TFTP filenames present in a DHCP filename field may use special characters such as "?" or "#" that prevent parsing as a generic URI. As of commit 7667536 ("[uri] Refactor URI parsing and formatting"), we have directly constructed TFTP URIs from DHCP next-server and filename pairs, avoiding the generic URI parser. This eliminated the problems related to special characters, but indirectly made it impossible to parse a "tftp://..." URI string into a TFTP URI with a non-absolute path. Re-introduce the convention of requiring an extra slash in a "tftp://..." URI string in order to specify a TFTP URI with an initial slash in the filename. For example: tftp://192.168.0.1/boot/pxelinux.0 => RRQ "boot/pxelinux.0" tftp://192.168.0.1//boot/pxelinux.0 => RRQ "/boot/pxelinux.0" This is ugly, but there seems to be no other sensible way to provide the ability to specify all possible TFTP filenames. A side-effect of this change is that format_uri() will no longer add a spurious initial "/" when formatting a relative URI string. This improves the console output when fetching an image specified via a relative URI. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tftp] Do not change current working URI when TFTP server is clearedMichael Brown2016-01-091-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For historical reasons, iPXE sets the current working URI to the root of the TFTP server whenever the TFTP server address is changed. This was originally implemented in the hope of allowing a DHCP-provided TFTP filename to be treated simply as a relative URI. This usage turns out to be impractical since DHCP-provided TFTP filenames may include characters which would have special significance to the URI parser, and so the DHCP next-server+filename combination is now handled by the dedicated pxe_uri() function instead. The practice of setting the current working URI to the root of the TFTP server is potentially helpful for interactive uses of iPXE, allowing a user to type e.g. iPXE> dhcp Configuring (net0 52:54:00:12:34:56)... ok iPXE> chain pxelinux.0 and have the URI "pxelinux.0" interpreted as being relative to the root of the TFTP server provided via DHCP. The current implementation of tftp_apply_settings() has an unintended flaw. When the "dhcp" command is used to renew a DHCP lease (or to pick up potentially modified DHCP options), the old settings block will be unregistered before the new settings block is registered. This causes tftp_apply_settings() to believe that the TFTP server has been changed twice (to 0.0.0.0 and back again), and so the current working URI will always be set to the root of the TFTP server, even if the DHCP response provides exactly the same TFTP server as previously. Fix by doing nothing in tftp_apply_settings() whenever there is no TFTP server address. Debugged-by: Andrew Widdersheim <awiddersheim@inetu.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Limit maximum number of DHCP discovery deferralsMichael Brown2015-11-101-2/+6
| | | | | | | | | For switches which remain permanently in the non-forwarding state (or which erroneously report a non-forwarding state), ensure that iPXE will eventually give up waiting for the link to become unblocked. Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Reset start time when deferring discoveryMichael Brown2015-10-301-0/+1
| | | | | | | | | | | | | | | | | | If we detect (via STP) that a switch port is in a non-forwarding state, then the link is marked as being temporarily blocked and DHCP discovery will be deferred until the link becomes unblocked. The timer used to decide when to give up waiting for ProxyDHCPOFFERs is currently based on the time that DHCP discovery was started, and makes no allowances for any time spent waiting for the link to become unblocked. Consequently, if STP is used then the timeout for ProxyDHCPOFFERs becomes essentially zero. Fix by resetting the recorded start time whenever DHCP discovery is deferred due to a blocked link. Debugged-by: Sebastian Roth <sebastian.roth@zoho.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Do not skip ProxyDHCPREQUEST if next-server is emptyMichael Brown2015-08-261-2/+3
| | | | | | | | | | | | | | We attempt to mimic the behaviour of Intel's PXE ROM by skipping the separate ProxyDHCPREQUEST if the ProxyDHCPOFFER already contains a boot filename or a PXE boot menu. Experimentation reveals that Intel's PXE ROM will also check for a non-empty next-server address alongside the boot filename. Update our test to match this behaviour. Reported-by: Wissam Shoukair <wissams@mellanox.com> Tested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Ignore ProxyDHCPACKs without PXE optionsMichael Brown2015-08-181-0/+4
| | | | | Suggested-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Allow pseudo-DHCP servers to use pseudo-identifiersMichael Brown2015-08-181-27/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some ProxyDHCP servers and PXE boot servers do not specify a DHCP server identifier via option 54. We currently work around this in a variety of ad-hoc ways: - if a ProxyDHCPACK has no server identifier then we treat it as having the correct server identifier, - if a boot server ACK has no server identifier then we use the packet's source IP address as the server identifier. Introduce the concept of a DHCP server pseudo-identifier, defined as being: - the server identifier (option 54), or - if there is no server identifier, then the next-server address (siaddr), - if there is no server identifier or next-server address, then the DHCP packet's source IP address. Use the pseudo-identifier in place of the server identifier when handling ProxyDHCP and PXE boot server responses. Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Defer discovery if link is blockedMichael Brown2015-06-251-0/+9
| | | | | | | | If the link is blocked (e.g. due to a Spanning Tree Protocol port not yet forwarding packets) then defer DHCP discovery until the link becomes unblocked. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [retry] Rewrite unrelicensable portions of retry.cMichael Brown2015-03-051-2/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-023-3/+15
| | | | | | | | | | These files cannot be automatically relicensed by util/relicense.pl since they either contain unusual but trivial contributions (such as the addition of __nonnull function attributes), or contain lines dating back to the initial git revision (and so require manual knowledge of the code's origin). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-023-3/+15
| | | | | | | Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-05 06:49:43 +0100