aboutsummaryrefslogtreecommitdiffstats
path: root/src/net
Commit message (Collapse)AuthorAgeFilesLines
* [fcoe] Use driver-private data to hold FCoE port structurenetstateMichael Brown2023-09-131-64/+21
| | | | | | | Simplify the FCoE code by using driver-private data to hold the FCoE port for each network device, instead of using a separate allocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Use driver-private data to hold link-local IPv6 settings blockMichael Brown2023-09-131-29/+10
| | | | | | | | Simplify the IPv6 link-local settings code by using driver-private data to hold the settings block, instead of using a separate allocation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lldp] Use driver-private data to hold LLDP settings blockMichael Brown2023-09-131-63/+31
| | | | | | | | | | | | | | | | | | | | Simplify the LLDP code by using driver-private data to hold the LLDP settings block, instead of using a separate allocation. This avoids the need to maintain a list of LLDP settings blocks (since the LLDP settings block pointer can always be obtained using netdev_priv()) and obviates several failure paths. Any recorded LLDP data is now freed when the network device is unregistered, since there is no longer a dedicated reference counter for the LLDP settings block. To minimise surprise, we also now explicitly unregister the settings block. This is not strictly necessary (since the block will be automatically unregistered when the parent network device settings block is unregistered), but it maintains symmetry between lldp_probe() and lldp_remove(). The overall reduction in the size of the LLDP code is around 15%. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allocate private data for each network upper-layer driverMichael Brown2023-09-137-23/+81
| | | | | | | | | | | | | | | | | Allow network upper-layer drivers (such as LLDP, which attaches to each network device in order to provide a corresponding LLDP settings block) to specify a size for private data, which will be allocated as part of the network device structure (as with the existing private data allocated for the underlying device driver). This will allow network upper-layer drivers to be simplified by omitting memory allocation and freeing code. If the upper-layer driver requires a reference counter (e.g. for interface initialisation), then it may use the network device's existing reference counter, since this is now the reference counter for the containing block of memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcp] Request NTP server optionntpsettingCornelius 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>
* [netdevice] Stop link block timer when device is closedMichael Brown2023-07-051-1/+4
| | | | | | | | | | | | | | | A running link block timer holds a reference to the network device and will prevent it from being freed until the timer expires. It is impossible for free_netdev() to be called while the timer is still running: the call to stop_timer() therein is therefore a no-op. Stop the link block timer when the device is closed, to allow a link-blocked device to be freed immediately upon unregistration of the device. (Since link block state is updated in response to received packets, the state is effectively undefined for a closed device: there is therefore no reason to leave the timer running.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Handle fragmented handshake recordsMichael Brown2023-03-301-18/+24
| | | | | Originally-implemented-by: Christopher Schenk <christopher@cschenk.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Pass I/O buffer to received record handlersMichael Brown2023-03-301-58/+98
| | | | | | | | Prepare for the possibility that a record handler may choose not to consume the entire record by passing the I/O buffer and requiring the handler to mark consumed data using iob_pull(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Clean up change cipher spec record handlingMichael Brown2023-03-301-4/+15
| | | | | | | Define and use data structures and constants for the (single-byte) change cipher spec records. 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>
* [params] Allow for arbitrary HTTP request headers to be specifiedMichael Brown2023-03-011-9/+34
| | | | | | | | | | | 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>
* [http] Use POST method only if the form parameter list is non-emptyMichael Brown2023-03-011-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>
* [iscsi] Limit maximum transfer size to MaxBurstLengthiscsicapMichael Brown2023-02-161-4/+61
| | | | | | | | | | | | | | | | | 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>
* [lldp] Add support for the Link Layer Discovery ProtocollldpMichael Brown2023-02-051-0/+340
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [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] Ensure consistent interpretation of "netX" device nameMichael Brown2023-01-171-2/+2
| | | | | | | | Ensure that the "${netX/...}" settings mechanism always uses the same interpretation of the network device corresponding to "netX" as any other mechanism that performs a name-based lookup of a network device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vlan] Support automatic VLAN device creationMichael Brown2023-01-151-0/+48
| | | | | | | Add the ability to automatically create a VLAN device for a specified trunk device link-layer address and VLAN tag. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allow duplicate MAC addressesMichael Brown2023-01-151-33/+0
| | | | | | | | | | | | | | | | | | | | | | | | Many laptops now include the ability to specify a "system-specific MAC address" (also known as "pass-through MAC"), which is supposed to be used for both the onboard NIC and for any attached docking station or other USB NIC. This is intended to simplify interoperability with software or hardware that relies on a MAC address to recognise an individual machine: for example, a deployment server may associate the MAC address with a particular operating system image to be deployed. This therefore creates legitimate situations in which duplicate MAC addresses may exist within the same system. As described in commit 98d09a1 ("[netdevice] Avoid registering duplicate network devices"), the Xen netfront driver relies on the rejection of duplicate MAC addresses in order to inhibit registration of the emulated PCI devices that a Xen PV-HVM guest will create to shadow each of the paravirtual network devices. Move the code that rejects duplicate MAC addresses from the network device core to the Xen netfront driver, to allow for the existence of duplicate MAC addresses in non-Xen setups. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Separate concept of scope ID from network device name indexMichael Brown2023-01-146-25/+28
| | | | | | | | | | | | | | | | | | | | | 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>
* [efi] Provide VLAN configuration protocolMichael Brown2022-12-141-2/+1
| | | | | | | | | | | | | | | | | | | | | | | UEFI implements VLAN support within the Managed Network Protocol (MNP) driver, which may create child VLAN devices automatically based on stored UEFI variables. These child devices do not themselves provide a raw-packet interface via EFI_SIMPLE_NETWORK_PROTOCOL, and may be consumed only via the EFI_MANAGED_NETWORK_PROTOCOL interface. The device paths constructed for these child devices may conflict with those for the EFI_SIMPLE_NETWORK_PROTOCOL instances that iPXE attempts to install for its own VLAN devices. The upshot is that creating an iPXE VLAN device (e.g. via the "vcreate" command) will fail if the UEFI Managed Network Protocol has already created a device for the same VLAN tag. Fix by providing our own EFI_VLAN_CONFIG_PROTOCOL instance on the same device handle as EFI_SIMPLE_NETWORK_PROTOCOL. This causes the MNP driver to treat iPXE's device as supporting hardware VLAN offload, and it will therefore not attempt to install its own instance of the protocol. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vlan] Allow external code to identify VLAN priority as well as tagMichael Brown2022-12-142-6/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Allow handshake digest algorithm to be specified by cipher suiteMichael Brown2022-11-091-63/+114
| | | | | | | | | | | | | | | | | | | All existing cipher suites use SHA-256 as the TLSv1.2 and above handshake digest algorithm (even when using SHA-1 as the MAC digest algorithm). Some GCM cipher suites use SHA-384 as the handshake digest algorithm. Allow the cipher suite to specify the handshake (and PRF) digest algorithm to be used for TLSv1.2 and above. This requires some restructuring to allow for the fact that the ClientHello message must be included within the handshake digest, even though the relevant digest algorithm is not yet known at the point that the ClientHello is sent. Fortunately, the ClientHello may be reproduced verbatim at the point of receiving the ServerHello, so we rely on reconstructing (rather than storing) this message. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Always send maximum supported version in ClientHelloMichael Brown2022-11-091-1/+1
| | | | | | | | | | | | Always send the maximum supported version in our ClientHello message, even when performing renegotiation (in which case the current version may already be lower than the maximum supported version). This is permitted by the specification, and allows the ClientHello to be reconstructed verbatim at the point of selecting the handshake digest algorithm in tls_new_server_hello(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add support for AEAD ciphersMichael Brown2022-11-081-2/+39
| | | | | | | | Allow for AEAD cipher suites where the MAC length may be zero and the authentication is instead provided by an authenticating cipher, with the plaintext authentication tag appended to the ciphertext. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Treat invalid block padding as zero length paddingMichael Brown2022-11-081-2/+2
| | | | | | | | Harden against padding oracle attacks by treating invalid block padding as zero length padding, thereby deferring the failure until after computing the (incorrect) MAC. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Allow for arbitrary-length initialisation vectorsMichael Brown2022-11-081-186/+144
| | | | | | | | | Restructure the encryption and decryption operations to allow for the use of ciphers where the initialisation vector is constructed by concatenating the fixed IV (derived as part of key expansion) with a record IV (prepended to the ciphertext). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add MAC length as a cipher suite parameterMichael Brown2022-11-081-16/+18
| | | | | | | | | | | | | | | TLS stream and block ciphers use a MAC with a length equal to the output length of the digest algorithm in use. For AEAD ciphers there is no MAC, with the equivalent functionality provided by the cipher algorithm's authentication tag. Allow for the existence of AEAD cipher suites by making the MAC length a parameter of the cipher suite. Assume that the MAC key length is equal to the MAC length, since this is true for all currently supported cipher suites. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Abstract out concept of a TLS authentication headerMichael Brown2022-11-081-21/+19
| | | | | | | | | | | | | All TLS cipher types use a common structure for the per-record data that is authenticated in addition to the plaintext itself. This data is used as a prefix in the HMAC calculation for stream and block ciphers, or as additional authenticated data for AEAD ciphers. Define a "TLS authentication header" structure to hold this data as a contiguous block, in order to meet the alignment requirement for AEAD ciphers such as GCM. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Ensure cipher alignment size is respectedMichael Brown2022-11-071-0/+18
| | | | | | | | Adjust the length of the first received ciphertext data buffer to ensure that all decryption operations respect the cipher's alignment size. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Formalise notions of fixed and record initialisation vectorsMichael Brown2022-11-071-3/+24
| | | | | | | | | | | | | | | | | | | | | TLS block ciphers always use CBC (as per RFC 5246 section 6.2.3.2) with a record initialisation vector length that is equal to the cipher block size, and no fixed initialisation vector. The initialisation vector for AEAD ciphers such as GCM is less straightforward, and requires both a fixed and per-record component. Extend the definition of a cipher suite to include fixed and record initialisation vector lengths, and generate the fixed portion (if any) as part of key expansion. Do not add explicit calls to cipher_setiv() in tls_assemble_block() and tls_split_block(), since the constraints imposed by RFC 5246 are specifically chosen to allow implementations to avoid doing so. (Instead, add a sanity check that the record initialisation vector length is equal to the cipher block size.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Remove support for TLSv1.0Michael Brown2022-11-071-31/+6
| | | | | | | | | | | | | | | | The TLSv1.0 protocol was deprecated by RFC 8996 (along with TLSv1.1), and has been disabled by default in iPXE since commit dc785b0fb ("[tls] Default to supporting only TLSv1.1 or above") in June 2020. While there is value in continuing to support older protocols for interoperability with older server appliances, the additional complexity of supporting the implicit initialisation vector for TLSv1.0 is not worth the cost. Remove support for the obsolete TLSv1.0 protocol, to reduce complexity of the implementation and simplify ongoing maintenance. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow initialisation vector length to vary from cipher blocksizeMichael Brown2022-10-252-3/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add support for Ephemeral Diffie-Hellman key exchangeMichael Brown2022-10-111-0/+246
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Add key exchange mechanism to definition of cipher suiteMichael Brown2022-10-111-3/+25
| | | | | | | Allow for the key exchange mechanism to vary depending upon the selected cipher suite. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Record ServerKeyExchange record, if providedMichael Brown2022-10-111-0/+36
| | | | | | | Accept and record the ServerKeyExchange record, which is required for key exchange mechanisms such as Ephemeral Diffie-Hellman (DHE). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Generate pre-master secret at point of sending ClientKeyExchangeMichael Brown2022-10-111-16/+24
| | | | | | | | | | | | | | The pre-master secret is currently constructed at the time of instantiating the TLS connection. This precludes the use of key exchange mechanisms such as Ephemeral Diffie-Hellman (DHE), which require a ServerKeyExchange message to exchange additional key material before the pre-master secret can be constructed. Allow for the use of such cipher suites by deferring generation of the master secret until the point of sending the ClientKeyExchange message. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Generate master secret at point of sending ClientKeyExchangeMichael Brown2022-10-111-8/+13
| | | | | | | | | | | | | | The master secret is currently constructed upon receiving the ServerHello message. This precludes the use of key exchange mechanisms such as Ephemeral Diffie-Hellman (DHE), which require a ServerKeyExchange message to exchange additional key material before the pre-master secret and master secret can be constructed. Allow for the use of such cipher suites by deferring generation of the master secret until the point of sending the ClientKeyExchange message. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Simplify internal HMAC APIMichael Brown2022-10-104-46/+34
| | | | | | | | | | | | Simplify the internal HMAC API so that the key is provided only at the point of calling hmac_init(), and the (potentially reduced) key is stored as part of the context for later use by hmac_final(). This simplifies the calling code, and avoids the need for callers such as TLS to allocate a potentially variable length block in order to retain a copy of the unmodified key. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Ignore SLAAC on prefixes with an incompatible prefix lengthMichael Brown2022-09-131-11/+25
| | | | | | | | | | | | | Experience suggests that routers are often misconfigured to advertise SLAAC even on prefixes that do not have a SLAAC-compatible prefix length. iPXE will currently treat this as an error, resulting in the prefix being ignored completely. Handle this misconfiguration by ignoring the autonomous address flag when the prefix length is unsuitable for SLAAC. Reported-by: Malte Janduda <mail@janduda.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Fix mask calculation when prefix length is not a multiple of 8Michael Brown2022-09-061-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Always start DNS queries using the first configured DNS serverdns_primaryMichael Brown2022-02-231-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [xsigo] Avoid storing unused uninitialised fields in gateway addressMichael Brown2022-02-161-0/+1
| | | | | | | | | | | As reported by Coverity, xsmp_rx_xve_modify() currently passes a partially initialised struct ib_address_vector to xve_update_tca() and thence to eoib_set_gateway(), which uses memcpy() to store the whole structure including the (unused and unneeded) uninitialised fields. Silence the Coverity warning by zeroing the whole structure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Retain original encodings for path, query, and fragment fieldsMichael Brown2021-11-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | iPXE decodes any percent-encoded characters during the URI parsing stage, thereby allowing protocol implementations to consume the raw field values directly without further decoding. When reconstructing a URI string for use in an HTTP request line, the percent-encoding is currently reapplied in a reversible way: we guarantee that our reconstructed URI string could be decoded to give the same raw field values. This technically violates RFC3986, which states that "URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent". Experiments show that several HTTP server applications will attach meaning to the choice of whether or not a particular character was percent-encoded, even when the percent-encoding is unnecessary from the perspective of parsing the URI into its component fields. Fix by storing the originally encoded substrings for the path, query, and fragment fields and using these original encoded versions when reconstructing a URI string. The path field is also stored as a decoded string, for use by protocols such as TFTP that communicate using raw strings rather than URI-encoded strings. All other fields (such as the username and password) continue to be stored only in their decoded versions since nothing ever needs to know the originally encoded versions of these fields. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Make URI schemes case-insensitiveMichael Brown2021-07-011-1/+2
| | | | | | | | | | | RFC 3986 section 3.1 defines URI schemes as case-insensitive (though the canonical form is always lowercase). Use strcasecmp() rather than strcmp() to allow for case insensitivity in URI schemes. Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [peerdist] Assume that most recently discovered peer can be reusedMichael Brown2021-06-221-0/+23
| | | | | | | | | | | | | | | | | | | The peer discovery time has a significant impact on the overall PeerDist download speed, since each block requires an individual discovery attempt. In most cases, a peer that responds for block N will turn out to also respond for block N+1. Assume that the most recently discovered peer (for any block) probably has a copy of the next block to be discovered, thereby allowing the peer download attempt to begin immediately. In the case that this assumption is incorrect, the existing error recovery path will allow for fallback to newly discovered peers (or to the origin server). Suggested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Ensure driver transmit() and poll() will not be re-enteredMichael Brown2021-04-101-7/+32
| | | | | | | | | | | | | | When CONSOLE_SYSLOG is used, a DBG() from within a network device driver may cause its transmit() or poll() methods to be unexpectedly re-entered. Since these methods are not intended to be re-entrant, this can lead to undefined behaviour. Add an explicit re-entrancy guard to both methods. Note that this must operate at a per-netdevice level, since there are legitimate circumstances under which the netdev_tx() or netdev_poll() functions may be re-entered (e.g. when using VLAN devices). 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>
generated by cgit (git 2.34.1) at 2025-02-24 03:57:46 +0000