summaryrefslogtreecommitdiffstats
path: root/src/net
Commit message (Collapse)AuthorAgeFilesLines
...
* [http] Cleanly shut down potentially looped interfacesMichael Brown2017-02-021-15/+6Star
| | | | | | | | | | | | | Use intfs_shutdown() and intfs_restart() to cleanly shut down multiple interfaces that may loop back to the same object. This fixes a regression introduced by commit daa8ed9 ("[interface] Provide intf_reinit() to reinitialise nullified interfaces") which broke the use of HTTP Basic and Digest authentication. Reported-by: murmansk <murmansk@hotmail.com> Reported-by: Brett Waldo <brettwaldo@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [time] Allow timer to be selected at runtimeMichael Brown2017-01-263-6/+6
| | | | | | | | | | | | | | | | | | | | | | Allow the active timer (providing udelay() and currticks()) to be selected at runtime based on probing during the INIT_EARLY stage of initialisation. TICKS_PER_SEC is now a fixed compile-time constant for all builds, and is independent of the underlying clock tick rate. We choose the value 1024 to allow multiplications and divisions on seconds to be converted to bit shifts. TICKS_PER_MS is defined as 1, allowing multiplications and divisions on milliseconds to be omitted entirely. The 2% inaccuracy in this definition is negligible when using the standard BIOS timer (running at around 18.2Hz). TIMER_RDTSC now checks for a constant TSC before claiming to be a usable timer. (This timer can be tested in KVM via the command-line option "-cpu host,+invtsc".) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Limit MTU by hardware maximum frame lengthMichael Brown2017-01-254-9/+23
| | | | | | | | | | | | | | | | Separate out the concept of "hardware maximum supported frame length" and "configured link MTU", and limit the latter according to the former. In networks where the DHCP-supplied link MTU is inconsistent with the hardware or driver capabilities (e.g. a network using jumbo frames), this will result in iPXE advertising a TCP MSS consistent with a size that can actually be received. Note that the term "MTU" is typically used to refer to the maximum length excluding the link-layer headers; we adopt this usage. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allow MTU to be changed at runtimeMichael Brown2017-01-232-3/+64
| | | | | | | | | | | | 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>
* [cloud] Add ability to retrieve Google Compute Engine metadataMichael Brown2017-01-231-0/+72
| | | | | | | | | | | | | | | | | | | | | | | For some unspecified "security" reason, the Google Compute Engine metadata server will refuse any requests that do not include the non-standard HTTP header "Metadata-Flavor: Google". Attempt to autodetect such requests (by comparing the hostname against "metadata.google.internal"), and add the "Metadata-Flavor: Google" header if applicable. Enable this feature in the CONFIG=cloud build, and include a sample embedded script allowing iPXE to boot from a script configured as metadata via e.g. # Create shared boot image make bin/ipxe.usb CONFIG=cloud EMBED=config/cloud/gce.ipxe # Configure per-instance boot script gcloud compute instances add-metadata <instance> \ --metadata-from-file ipxeboot=boot.ipxe Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Return const char * from uuid_ntoa()David Decotigny2017-01-221-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv4] Accept unicast packets for the local network broadcast addressMichael Brown2017-01-221-0/+1
| | | | | | | | | | | | | The ISC Kea DHCP server transmits its DHCPOFFER as a unicast packet with a broadcast IPv4 destination address (255.255.255.255). This combination is currently rejected by iPXE. Fix by explicitly accepting the local network broadcast address (255.255.255.255) as a valid unicast destination address. Reported-by: Roy Ledochowski <roy.ledochowski@hpe.com> Tested-by: Roy Ledochowski <roy.ledochowski@hpe.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Avoid potential infinite loops during shutdownMichael Brown2016-11-171-0/+1
| | | | | | | | The command and data interfaces may be connected to the same object. Nullify the data interface before shutting down the control interface to avoid potential infinite loops. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Provide intf_reinit() to reinitialise nullified interfacesMichael Brown2016-11-161-4/+1Star
| | | | | | | Provide an abstraction intf_reinit() to restore the descriptor of a previously nullified interface. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Generalise X.509 "valid" field to a "flags" fieldMichael Brown2016-08-251-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Allow for multiple routersMichael Brown2016-07-251-49/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Select the IPv6 source address and corresponding router (if any) using a very simplified version of the algorithm from RFC6724: - Ignore any source address that has a smaller scope than the destination address. For example, do not use a link-local source address when sending to a global destination address. - If we have a source address which is on the same link as the destination address, then use that source address. - If we are left with multiple possible source addresses, then choose the address with the smallest scope. For example, if we are sending to a site-local destination address and we have both a global source address and a site-local source address, then use the site-local source address. - If we are still left with multiple possible source addresses, then choose the address with the longest matching prefix. For the purposes of this algorithm, we treat RFC4193 Unique Local Addresses as having organisation-local scope. Since we use only link-local scope for our multicast transmissions, this approximation should remain valid in all practical situations. Originally-implemented-by: Thomas Bächler <thomas@archlinux.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Rename ipv6_scope to ipv6_settings_scopeMichael Brown2016-07-212-7/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Create routing table based on IPv6 settingsMichael Brown2016-07-203-187/+132Star
| | | | | | | | | | | | | | | | | | | | | | 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-193-2/+19
| | | | | | | | | | | | | | 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>
* [ipv6] Expose IPv6 link-local address settingsMichael Brown2016-07-191-0/+113
| | | | | | Originally-implemented-by: Hannes Reinecke <hare@suse.de> Originally-implemented-by: Marin Hannache <git@mareo.fr> 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] Expose IPv6 settings acquired through NDPMichael Brown2016-07-192-5/+273
| | | | | | | | | Expose the IPv6 address (or prefix) as ${ip6}, the prefix length as ${len6}, and the router address as ${gateway6}. 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] Allow settings to comprise arbitrary subsets of NDP optionsMichael Brown2016-07-191-35/+67
| | | | 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-153-6/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Perform SLAAC only during autoconfigurationMichael Brown2016-07-151-8/+14
| | | | | | | | | | | | | | | | | | We currently perform IPv6 stateless address autoconfiguration (SLAAC) in response to any router advertisement with the relevant flags set. This can result in the local IPv6 source address changing midway through a TCP connection, since our connections bind only to a local port number and do not store a local network address. In addition, this behaviour for SLAAC is inconsistent with that for DHCPv4 and stateful DHCPv6, both of which will be performed only as a result of an explicit autoconfiguration action (e.g. via the default autoboot sequence, or the "ifconf" command). Fix by ignoring router advertisements arriving outside the context of an ongoing autoconfiguration attempt. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv4] Send gratuitous ARPs whenever a new IPv4 address is appliedMichael Brown2016-07-121-20/+80
| | | | | | | | | | | | | | | | | | | | In a busy network (such as a public cloud), IPv4 addresses may be recycled rapidly. When this happens, unidirectional traffic (such as UDP syslog) will succeed, but bidirectional traffic (such as TCP connections) may fail due to stale ARP cache entries on other nodes. The remote ARP cache expiry timeout is likely to exceed iPXE's connection timeout, meaning that boot attempts can fail before the problem is automatically resolved. Fix by sending gratuitous ARPs whenever an IPv4 address is changed, to attempt to update stale remote ARP cache entries. Note that this is not a guaranteed fix, since ARP is an unreliable protocol. We avoid sending gratuitous ARPs unconditionally, since otherwise any unrelated settings change (e.g. "set dns 192.168.0.1") would cause unexpected gratuitous ARPs to be sent. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Treat redirection failures as fatalMichael Brown2016-07-041-1/+10
| | | | | Debugged-by: Robin Smidsrød <robin@smidsrod.no> 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>
* [tcp] Send TCP keepalives on idle established connectionsMichael Brown2016-06-131-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | In some circumstances, intermediate devices may lose state in a way that temporarily prevents the successful delivery of packets from a TCP peer. For example, a firewall may drop a NAT forwarding table entry. Since iPXE spends most of its time downloading files (and hence purely receiving data, sending only TCP ACKs), this can easily happen in a situation in which there is no reason for iPXE's TCP stack to generate any retransmissions. The temporary loss of connectivity can therefore effectively become permanent. Work around this problem by sending TCP keepalives after a period of inactivity on an established connection. TCP keepalives usually send a single garbage byte in sequence number space that has already been ACKed by the peer. Since we do not need to elicit a response from the peer, we instead send pure ACKs (with no garbage data) in order to keep the transmit code path simple. Originally-implemented-by: Ladi Prosek <lprosek@redhat.com> Debugged-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [http] Accept headers with no whitespace following the colonMichael Brown2016-06-091-2/+6
| | | | | Reported-by: Raphael Cohn <raphael.cohn@stormmq.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [http] Ignore unrecognised "Connection" header tokensMichael Brown2016-05-251-13/+11Star
| | | | | | | | | | Some HTTP/2 servers send the header "Connection: upgrade, close". This currently causes iPXE to fail due to the unrecognised "upgrade" token. Fix by ignoring any unrecognised tokens in the "Connection" header. Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Fix failure path in register_netdev()Michael Brown2016-05-231-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ethernet] Make LACP support configurable at build timeMichael Brown2016-04-181-3/+0Star
| | | | | | | Add a build configuration option NET_PROTO_LACP to control whether or not LACP support is included for Ethernet devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Return ENOENT for an unknown bus typeMichael Brown2016-03-291-1/+2
| | | | | | | | | | | | | It is possible for the preloaded UNDI device to end up with no specified bus type, since it may not be recognised as either a PCI or an ISAPnP device. This will result in a bus type value of zero, which currently results in NULL being treated as a string pointer by netdev_fetch_bustype(). Fix by returning ENOENT if an unknown bus type is specified. Reported-by: Todd Stansell <todd@stansell.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow cross-certificate source to be configured at build timeMichael Brown2016-03-241-1/+2
| | | | | | | | | Provide a build option CROSSCERT in config/crypto.h to allow the default cross-signed certificate source to be configured at build time. The ${crosscert} setting may still be used to reconfigure the cross-signed certificate source at runtime. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [arp] Validate length of ARP packetMichael Brown2016-03-121-0/+7
| | | | | | | | | | | | There is no practical way to generate an underlength ARP packet since an ARP packet is always padded up to the minimum Ethernet frame length (or dropped by the receiving Ethernet hardware if incorrectly padded), but the absence of an explicit check causes warnings from some analysis tools. Fix by adding an explicit check on the I/O buffer length. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [tls] Avoid potential out-of-bound reads in length fieldsMichael Brown2016-03-111-44/+67
| | | | | | | | | | | | | | | | | | Many TLS records contain variable-length fields. We currently validate the overall record length, but do so only after reading the length of the variable-length field. If the record is too short to even contain the length field, then we may read uninitialised data from beyond the end of the record. This is harmless in practice (since the subsequent overall record length check would fail regardless of the value read from the uninitialised length field), but causes warnings from some analysis tools. Fix by validating that the overall record length is sufficient to contain the length field before reading from the length field. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xsigo] Add support for Xsigo virtual Ethernet (XVE) EoIB devicesMichael Brown2016-03-091-0/+1858
| | | | | | | | | Add support for EoIB devices as implemented by Xsigo. Based on the public (but out-of-tree) Linux kernel drivers at https://oss.oracle.com/git/?p=linux-uek.git;a=log;h=v4.1.12-32.2.1 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Make IPoIB support configurable at build timeMichael Brown2016-03-091-3/+0Star
| | | | | | | Add a build configuration option VNIC_IPOIB to control whether or not IPoIB support is included for Infiniband devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Retrieve GID flag from cached path entriesMichael Brown2016-03-081-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Assign names to queue pairsMichael Brown2016-03-083-9/+14
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Assign names to CMRC connectionsMichael Brown2016-03-082-36/+50
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Allow for the creation of multicast groupsMichael Brown2016-03-081-9/+16
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Parse MLID, rate, and SL from multicast membership recordMichael Brown2016-03-081-27/+30
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Record multicast GID attachment as part of group membershipMichael Brown2016-03-081-1/+9
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Do not use GRH for local pathsMichael Brown2016-03-081-7/+6Star
| | | | | | | Avoid including an unnecessary GRH in packets sent to unicast destinations within the local subnet. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Use correct transaction identifier in CM responsesMichael Brown2016-03-082-16/+24
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Use connection's local ID as debug message identifierMichael Brown2016-03-082-25/+33
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Use "%d" as format specifier for LIDsMichael Brown2016-03-082-4/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Use "%#lx" as format specifier for queue pair numbersMichael Brown2016-03-084-12/+12
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-05-28 20:16:36 +0200