summaryrefslogtreecommitdiffstats
path: root/src/net/udp
Commit message (Collapse)AuthorAgeFilesLines
* [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>
* [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>
* [tftp] Explicitly abort connection whenever parent interface is closedMichael Brown2015-02-061-38/+16Star
| | | | | | | | | Fetching the TFTP file size is currently implemented via a custom "tftpsize://" protocol hack. Generalise this approach to instead close the TFTP connection whenever the parent data-transfer interface is closed. 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>
* [dhcpv6] Do not set sin6_scope_id on the unspecified client socket addressMichael Brown2014-05-231-1/+0Star
| | | | | | | | | | | | | | | Setting sin6_scope_id to a non-zero value will cause the check against the "empty socket address" in udp_demux() to fail, and incoming DHCPv6 responses on interfaces other than net0 will be rejected with a spurious "No UDP connection listening on port 546" error. The transmitting network device is specified via the destination address, not the source address. Fix by simply not setting sin6_scope_id on the client socket address. Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Tested-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [syslog] Strip invalid characters from hostnameMichael Brown2014-05-161-6/+31
| | | | | | | | | | Avoid generating syntactically invalid log messages by ensuring that invalid characters are not present in the hostname. In particular, ensure that any whitespace is stripped, since whitespace functions as a field separator for syslog messages. Reported-by: Alex Davies <adavies@jumptrading.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uri] Refactor URI parsing and formattingMichael Brown2014-02-272-14/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | Add support for parsing of URIs containing literal IPv6 addresses (e.g. "http://[fe80::69ff:fe50:5845%25net0]/boot.ipxe"). Duplicate URIs by directly copying the relevant fields, rather than by formatting and reparsing a URI string. This relaxes the requirements on the URI formatting code and allows it to focus on generating human-readable URIs (e.g. by not escaping ':' characters within literal IPv6 addresses). As a side-effect, this allows relative URIs containing parameter lists (e.g. "../boot.php##params") to function as expected. Add validity check for FTP paths to ensure that only printable characters are accepted (since FTP is a human-readable line-based protocol with no support for character escaping). Construct TFTP next-server+filename URIs directly, rather than parsing a constructed "tftp://..." string, Add self-tests for URI functions. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Update end-of-name pointer after processing CNAME recordMichael Brown2014-02-261-2/+12
| | | | | | | | | | | | | | | | | | | | | Commit d4c0226 ("[dns] Support DNS search lists") introduced a regression when handling CNAME records resolving to names longer than the original name. The "end of name" offset stored in dns->offset was not updated to reflect the length of the new name, causing dns_question() to append the (empty) search suffix at an incorrect offset within the name buffer, resulting in a mangled DNS name. In the case of a CNAME record resolving to a name shorter than or equal in length to the original name, then the mangling would occur in an unused portion of the name buffer. In the common case of a name server returning the A (or AAAA) record along with the CNAME record, this would cause name resolution to succeed despite the mangling. (If the name server did not return the A or AAAA record along with the CNAME record, then the mangling would be revealed by the subsequent invalid query packet.) Reported-by: Nicolas Sylvain <nsylvain@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Support DNS search listsMichael Brown2014-02-053-265/+713
| | | | | | | | | | | 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>
* [dhcpv6] Add DHCPv6 "filename" settingMichael Brown2013-12-051-0/+10
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Merge SETTING_IPv4 and SETTING_IPv6Michael Brown2013-12-051-2/+2
| | | | | | | Allow for equivalent IPv4 and IPv6 settings (which requires equivalent settings to be adjacent within the settings list). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Force settings into alphabetical order within sectionsMichael Brown2013-12-053-5/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Use DUID-UUID form of client DUIDMichael Brown2013-12-051-20/+21
| | | | | | Use the system UUID to generate the client DUID-UUID as per RFC 6355. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [syslog] Add support for IPv6 syslog serverMichael Brown2013-12-051-16/+35
| | | | | | | | | | | Note that IANA has not yet assigned a DHCPv6 option code for the syslog server. When a code is assigned, the definition of DHCPV6_LOG_SERVERS should be updated. Until then, an IPv6 address of a syslog server can be configured manually using e.g. set syslog6 3ffe:302:11:2::8309 Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dns] Add support for resolving IPv6 addresses via AAAA recordsMichael Brown2013-12-052-34/+103
| | | | | | | | Our policy is to prefer IPv6 addreses to IPv4 addresses, but to request IPv6 addresses only if we have an IPv6 address for the name server itself. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Allow for IPv6 setting types in non-IPv6 buildsMichael Brown2013-12-051-5/+2Star
| | | | | | | | | Allow for the existence of references to IPv6 setting types without dragging in the whole IPv6 stack, by placing the definition of setting_type_ipv6 in core/settings.c and providing weak stub methods for parse_ipv6_setting() and format_ipv6_setting(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [settings] Explicitly separate the concept of a completed fetched settingMichael Brown2013-12-054-39/+33Star
| | | | | | | | | | 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>
* [console] Allow console input and output to be disabled independentlyMichael Brown2013-11-281-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Pass escape sequence context to ANSI escape sequence handlersMichael Brown2013-11-271-1/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Allow stateful DHCPv6 to apply obtained IPv6 addressesMichael Brown2013-11-151-6/+24
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dhcpv6] Add basic support for stateful and stateless DHCPv6Michael Brown2013-11-141-0/+955
| | | | | | | | | | | | Add support for the stateful and stateless variants of the DHCPv6 protocol. The resulting settings block is registered as "net<x>.dhcpv6", and DHCPv6 options can be obtained using e.g. "${net0.dhcpv6/23:ipv6}" to obtain the IPv6 DNS server address. IPv6 addresses obtained via stateful DHCPv6 are not yet applied to the network device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-05-29 01:18:43 +0200