summaryrefslogtreecommitdiffstats
path: root/src/net/udp/dhcp.c
Commit message (Collapse)AuthorAgeFilesLines
* [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-021-1/+5
| | | | | | | | | | 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>
* [dhcp] Extract timing parameters out to config/dhcp.hAlex Williamson2015-02-251-13/+19
| | | | | | | | | | | | | | iPXE uses DHCP timeouts loosely based on values recommended by the specification, but often abbreviated to reduce timeouts for reliable and/or simple network topologies. Extract the DHCP timing parameters to config/dhcp.h and document them. The resulting default iPXE behavior is exactly the same, but downstreams are now afforded the opportunity to implement spec-compliant behavior via config file overrides. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Remove obsolete dhcp_chaddr() functionMichael Brown2014-09-221-75/+5Star
| | | | | | | | | | | | | | | As of commit 03f0c23 ("[ipoib] Expose Ethernet-compatible eIPoIB link-layer addresses and headers"), all link layers have used addresses which fit within the DHCP chaddr field. The dhcp_chaddr() function was therefore made obsolete by this commit, but was accidentally left present (though unused) in the source code. Remove the dhcp_chaddr() function and the only remaining use of it, unnecessarily introduced in commit 08bcc0f ("[dhcp] Check for matching chaddr in received DHCP packets"). Reported-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Check for matching chaddr in received DHCP packetsMichael Brown2014-09-221-0/+37
| | | | | | | | On large networks a DHCP XID collision is possible. Fix by explicitly checking the chaddr in received DHCP packets. Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Support DNS search listsMichael Brown2014-02-051-0/+1
| | | | | | | | | | | Update the DNS resolver to support DNS search lists (as provided by DHCP option 119, DHCPv6 option 24, or NDP option 31). Add validation code to ensure that parsing of DNS packets does not overrun the input, get stuck in infinite loops, or (worse) write beyond the end of allocated buffers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Force settings into alphabetical order within sectionsMichael Brown2013-12-051-1/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Explicitly separate the concept of a completed fetched settingMichael Brown2013-12-051-19/+25
| | | | | | | | | | The fetch_setting() family of functions may currently modify the definition of the specified setting (e.g. to add missing type information). Clean up this interface by requiring callers to provide an explicit buffer to contain the completed definition of the fetched setting, if required. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Move user-class setting from dhcp.c to settings.cMichael Brown2013-11-141-8/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Add DHCP network device configuratorMichael Brown2013-11-051-0/+6
| | | | | | | Provide an interface to DHCP via the generic network device configurator mechanism. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pxe] Always retrieve cached DHCPACK and apply to relevant network deviceMichael Brown2013-10-251-26/+1Star
| | | | | | | | | | | | When chainloading, always retrieve the cached DHCPACK packet from the underlying PXE stack, and apply it as the original contents of the "net<X>.dhcp" settings block. This allows cached DHCP settings to be used for any chainloaded iPXE binary (not just undionly.kkpxe). This change eliminates the undocumented "use-cached" setting. Issuing the "dhcp" command will now always result in a fresh DHCP request. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uuid] Abstract UUID mangling code out to a separate uuid_mangle() functionMichael Brown2013-03-201-3/+1Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Use PXE byte ordering for UUID in DHCP option 97Michael Brown2013-03-201-1/+8
| | | | | | | | The PXE spec does not specify a byte ordering for UUIDs, but RFC4578 suggests that it follows the EFI spec, in which the first three fields are little-endian. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Include version number within only a single object fileMichael Brown2012-11-021-3/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipoib] Expose Ethernet-compatible eIPoIB link-layer addresses and headersMichael Brown2012-08-311-2/+10
| | | | | | | | | | | | | 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>
* [legal] Update FSF mailing address in GPL licence textsMichael Brown2012-07-201-1/+2
| | | | | Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Request broadcast responses when we already have an IPv4 addressMichael Brown2012-06-201-0/+7
| | | | | | | | | | | | | | | | | 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>
* [dhcp] Add PXE-mandated DHCP options [128,135] to parameter request listMichael Brown2011-12-061-0/+1
| | | | | | | | The PXE specification requires us to request DHCP options 128 to 135 inclusive, although these have no defined purpose. Suggested-by: Ralf Buettner <rab@bootix.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Use a random DHCP transaction identifier (xid)Michael Brown2011-09-191-23/+24
| | | | | | | | | iPXE currently uses the last four bytes of the MAC address as the DHCP transaction identifier. Reduce the probability of collisions by generating a random transaction identifier. Originally-implemented-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Match terminology in online documentationMichael Brown2011-03-231-3/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Impose a fixed order on settingsMichael Brown2011-03-231-3/+3
| | | | | | | Improve the appearance of the "config" user interface by ensuring that settings appear in some kind of logical order. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Remove redundant length fields in struct dhcp_packetMichael Brown2011-01-101-1/+1
| | | | | | | | The max_len field is never used, and the len field is used only by dhcp_tx(). Remove these two fields, and perform the necessary trivial calculation in dhcp_tx() instead. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Use Ethernet-compatible chaddr, if possibleMichael Brown2010-12-151-21/+27
| | | | | | | | | | | | | | | For IPoIB, we currently use the hardware address (i.e. the eight-byte GUID) as the DHCP chaddr. This works, but some PXE servers (notably Altiris RDP) refuse to respond if the chaddr field is anything other than six bytes in length. We already have the notion of an Ethernet-compatible link-layer address, which is used in the iBFT (the design of which similarly fails to account for non-Ethernet link layers). Use this as the first preferred alternative to the actual link-layer address when constructing the DHCP chaddr field. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Apply settings block name in register_settings()Michael Brown2010-12-011-8/+8
| | | | | | | | Pass the settings block name as a parameter to register_settings(), rather than defining it with settings_init() (and then possibly changing it by directly manipulating settings->name). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Include session state metadata in packet tracesMichael Brown2010-10-091-0/+10
| | | | | | | | | | | | | | | | | (Ab)use the "secs" field in transmitted DHCP packets to convey metadata about the DHCP session state. In particular: bit 0 represents the receipt of a ProxyDHCPOFFER bit 1 represents the receipt of a DHCPOFFER bits 2+ represent the transmitted packet sequence number This allows some relevant information about the internal state of the DHCP session to be read out from a packet trace from a non-debug build of iPXE. It also potentially allows replies to be correlated to their requests (for servers that copy the "secs" field from request to reply). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Omit ProxyDHCPREQUEST if PXE options are present in ProxyDHCPOFFERMichael Brown2010-10-081-37/+67
| | | | | | | | | | | | Some ProxyDHCP implementations seem to violate the PXE specification by expecting the client to retain options from the ProxyDHCPOFFER rather than issuing a separate ProxyDHCPREQUEST. Work around such broken clients by retaining the ProxyDHCPOFFER packet, and proceeding to a ProxyDHCPREQUEST only if the ProxyDHCPOFFER does not already contain PXE options. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Ignore DHCPACKs containing incorrect IP addressesMichael Brown2010-10-081-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Revert various patchesMichael Brown2010-10-081-254/+88Star
| | | | | | | | | | | | | | | | A recent patch series breaks compatibility with various common DHCP implementations. Revert "[dhcp] Don't consider invalid offers to be duplicates" This reverts commit 905ea567534bbb67b83b2be41bfcd42209681e6a. Revert "[dhcp] Honor PXEBS_SKIP option in discovery control" This reverts commit 620b98ee4b9d8fa87c56bfa72b4391c1eed9dce6. Revert "[dhcp] Keep multiple DHCP offers received, and use them intelligently" This reverts commit 5efc2fcb602864e82de2cd7414e3828f589034e5. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [retry] Hold reference while timer is running and during expiry callbackMichael Brown2010-09-031-2/+2
| | | | | | | | | Guarantee that a retry timer cannot go out of scope while the timer is running, and provide a guarantee to the expiry callback that the timer will remain in scope during the entire callback (similar to the guarantee provided to interface methods). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [compiler] Prevent empty weak function stubs from being removedJoshua Oreman2010-08-191-1/+1
| | | | | | | | | | | | | | | | | Even with the noinline specifier added by commit 1a260f8, gcc may skip calls to non-inlinable functions that it knows have no side effects. This caused the get_cached_dhcpack() call in start_dhcp(), the weak stub of which has no code in its body, to be removed, preventing cached DHCP from working. Fix by adding a __keepme macro to compiler.h expanding to asm(""), as recommended by gcc's info page, and using it in the weak stub for get_cached_dhcpack(). Reported-by: Aaron Brooks <aaron@brooks1.net> Tested-by: Aaron Brooks <aaron@brooks1.net> Signed-off-by: Joshua Oreman <oremanj@rwcr.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Convert all data-xfer interfaces to generic interfacesMichael Brown2010-06-221-20/+17Star
| | | | | | | | | | | | | | Remove data-xfer as an interface type, and replace data-xfer interfaces with generic interfaces supporting the data-xfer methods. Filter interfaces (as used by the TLS layer) are handled using the generic pass-through interface capability. A side-effect of this is that deliver_raw() no longer exists as a data-xfer method. (In practice this doesn't lose any efficiency, since there are no instances within the current codebase where xfer_deliver_raw() is used to pass data to an interface supporting the deliver_raw() method.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Convert all job-control interfaces to generic interfacesMichael Brown2010-06-221-30/+16Star
| | | | | | | | | Remove job-control as an interface type, and replace job-control interfaces with generic interfaces supporting the close() method. (Both done() and kill() are absorbed into the function of close(); kill() is merely close(-ECANCELED).) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [retry] Add timer_init() wrapper functionMichael Brown2010-06-221-2/+2
| | | | | | | Standardise on using timer_init() to initialise an embedded retry timer, to match the coding style used by other embedded objects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [refcnt] Add ref_init() wrapper functionMichael Brown2010-06-221-2/+2
| | | | | | | Standardise on using ref_init() to initialise an embedded reference count, to match the coding style used by other embedded objects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Use correct DHCP options on EFI systemsGeoff Lywood2010-05-291-8/+5Star
| | | | | | | | See RFC 4578 for details. Signed-off-by: Joshua Oreman <oremanj@rwcr.net> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Don't consider invalid offers to be duplicatesJoshua Oreman2010-05-271-3/+3
| | | | | | | | | This fixes a regression in BOOTP support; since BOOTP requests often have the `siaddr' field set to 0.0.0.0, they would be considered duplicates of the first zeroed-out offer slot. Signed-off-by: Joshua Oreman <oremanj@rwcr.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Use weak definitions instead of weak declarationsJoshua Oreman2010-05-271-0/+5
| | | | | | | | | | | | | | | This removes the need for inline safety wrappers, marginally reducing the size penalty of weak functions, and works around an apparent binutils bug that causes undefined weak symbols to not actually be NULL when compiling with -fPIE (as EFI builds do). A bug in versions of binutils prior to 2.16 (released in 2005) will cause same-file weak definitions to not work with those toolchains. Update the README to reflect our new dependency on binutils >= 2.16. Signed-off-by: Joshua Oreman <oremanj@rwcr.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Honor PXEBS_SKIP option in discovery controlJoshua Oreman2010-05-271-2/+26
| | | | | | | | | | | | | | | | It is permissible for a DHCP packet containing PXE options to specify only "discovery control", instead of the more typical boot menu + prompt options. This is the strategy used by older versions of dnsmasq; by specifying the discovery control as PXEBS_SKIP, they cause vendor PXE ROMs to ignore boot server discovery and just use the filename and next-server options in the initial (Proxy)DHCP packet. Modify iPXE to accept this behavior, to be more compatible with the Intel firmware. Signed-off-by: Joshua Oreman <oremanj@rwcr.net> Tested-by: Kyle Kienapfel <kyle@shadowmage.org> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Rename gPXE to iPXEMichael Brown2010-04-201-16/+16
| | | | | | | | | | | Access to the gpxe.org and etherboot.org domains and associated resources has been revoked by the registrant of the domain. Work around this problem by renaming project from gPXE to iPXE, and updating URLs to match. Also update README, LOG and COPYRIGHTS to remove obsolete information. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Keep multiple DHCP offers received, and use them intelligentlyJoshua Oreman2010-01-221-86/+228
| | | | | | | | | | | | | | | | | | | | | | Instead of keeping only the best IP and PXE offers, store all of them, and pick the best to use just before a request is sent. This allows priority differentiation to work even when lower-priority offers provide PXE options, and improves robustness at sites with broken PXE servers intermingled with working ones: when a ProxyDHCP request times out, instead of giving up, we try the next PXE offer we've received. It also allows us to avoid breaking up combined IP+PXE offers, which can be important with some firewall configurations. This behavior matches that of most vendor PXE ROMs. Store a reference to the DHCPOFFER packet in the offer structure, so that when registering settings after a successful ACK we can register the proxy PXE settings we originally received; this removes the need for a nonstandard duplicate REQUEST/ACK to port 67 of proxy servers like dnsmasq that provide PXE options in the OFFER. Total cost: 450 bytes uncompressed. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [dhcp] Add generic facility for using cached network settingsJoshua Oreman2010-01-201-1/+21
| | | | | | | | | | | | | | | | | | | | | | When a DHCP session is started (using autoboot or a command-line `dhcp net0'), check whether the new setting use-cached (DHCP option 175.178) is TRUE; if so, skip DHCP and rely on currently registered settings. This lets one combine a static IP with autoboot. Before checking the use-cached setting, call a weak get_cached_dhcpack() hook that can be implemented by particular builds of gPXE supporting some fashion of retrieving a cached DHCPACK packet. If one is available, it is registered as an options source, and then either that packet's option 175.178 or the user's prior manual use-cached setting can allow skipping duplicate DHCP. Using cached packets is not the default because DHCP servers are often configured to give gPXE different options than they give a vendor PXE client; in order to break the infinite loop of PXE chaining, one would need to load a gPXE with an embedded image that does something more than autoboot. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [dhcp] Assume PXE options are in DHCPOFFER only if boot menu is includedJoshua Oreman2010-01-151-2/+2
| | | | | | | | | | | | | IBM's Tivoli Provisioning Manager for OS Deployment, when acting as a ProxyDHCP server, sends an initial offer with a vendor class of "PXEClient" and vendor-encapsulated options that have nothing to do with PXE. To differentiate between this case and the case of a ProxyDHCP server that sends all PXE options in its initial offer, modify gPXE to check for the presence of an encapsulated PXE boot menu option (43.9) instead of simply checking for the existence of any encapsulated options at all. This is the same check used by the Intel vendor PXE ROM. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [dhcp] Accept ProxyDHCP replies of type DHCPOFFERJoshua Oreman2010-01-151-1/+1
| | | | | | | | | | The PXE standard provides examples of ProxyDHCP responses being encoded both as type DHCPOFFER and DHCPACK, but currently we only accept DHCPACKs. Since there are PXE servers in existence that respond to ProxyDHCPREQUESTs with DHCPOFFERs, modify gPXE's ProxyDHCP pruning logic to treat both types of responses equally. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [dhcp] Ensure message type is first DHCP optionShao Miller2010-01-141-0/+1
| | | | | | | | | | | Apparently, the DHCP relay logic on a Nortel 470-48T layer 2 switch cares about the order of DHCP options. Specifically, it requires that the DHCP message type option be the first option present in the DHCP packet. We achieve this by having this option appear first in our dhcp_request_options_data array, which pre-populates DHCP requests. Signed-off-by: Marty Connor <mdc@etherboot.org>
* [settings] Add Bus ID settingShao Miller2009-12-141-4/+2Star
| | | | | | | | Users can find the bus type and PCI IDs for a network interface with: netX/busid Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
* [pxebs] Correct endianness of PXE typeJoshua Oreman2009-10-241-2/+2
| | | | | | | | | | The PXE type field is canonically little-endian, but the pxebs command treats it as big-endian in converting the type number passed on the command line to a field value to search against. Fix, to prevent the necessity of incantations like "pxebs net0 1536" to select menu item #6. Signed-off-by: Michael Brown <mcb30@etherboot.org> Modified-by: Michael Brown <mcb30@etherboot.org>
* [dhcp] Fall back to using the hardware address to populate the chaddr fieldMichael Brown2009-08-121-11/+43
| | | | | | | | | | | | | | | | | | | | | | | | For IPoIB, the chaddr field is too small (16 bytes) to contain the 20-byte IPoIB link-layer address. RFC4390 mandates that we should pass an empty chaddr field and rely on the DHCP client identifier instead. This has many problems, not least of which is that a client identifier containing an IPoIB link-layer address is not very useful from the point of view of creating DHCP reservations, since the QPN component is assigned at runtime and may vary between boots. Leave the DHCP client identifier as-is, to avoid breaking existing setups as far as possible, but expose the real hardware address (the port GUID) via the DHCP chaddr field, using the broadcast flag to instruct the DHCP server not to use this chaddr value as a link-layer address. This makes it possible (at least with ISC dhcpd) to create DHCP reservations using host declarations such as: host duckling { fixed-address 10.252.252.99; hardware unknown-32 00:02:c9:02:00:25:a1:b5; }
* [dhcp] Choose ProxyDHCP port based on presence of PXE optionsMichael Brown2009-05-221-6/+22
| | | | | | | | | | | | | | | | | | | | | | | 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.)
* [dhcp] Send broadcast PXE boot server discovery requests to port 67Michael Brown2009-05-201-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [dhcp] Perform ProxyDHCP only if we do not already have PXE optionsMichael Brown2009-05-201-2/+6
| | | | | | | | | | 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-27 12:48:39 +0100