openslx-ng/ipxe.git/src/net/udp, branch v1.0.0

[dhcp] Keep multiple DHCP offers received, and use them intelligently

2010-01-21T23:36:26+00:00

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

[dhcp] Add generic facility for using cached network settings

2010-01-20T22:15:51+00:00

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

[tftp] Abort requests with error code 0

2010-01-18T22:24:38+00:00

There is no defined error code for aborting a request but 0 is commonly used. This patch switches the abort request error code from TFTP_ERR_UNKNOWN_TID (5) to 0. Signed-off-by: Stefan Hajnoczi Signed-off-by: Marty Connor

[tftp] Make TFTP size requests abort transfer with an error

2010-01-18T00:18:28+00:00

pxenv_tftp_get_fsize is an API call that PXE clients can call to obtain the size of a remote file. It is implemented by starting a TFTP transfer with pxe_tftp_open, waiting for the response and then stopping the transfer with pxe_tftp_close(). This leaves the session hanging on the TFTP server and it will try to resend the packet repeatedly (verified with tftpd-hpa) until it times out. This patch adds a method "tftpsize" that will abort the transfer after the first packet is received from the server. This will terminate the session on the server and is the same behaviour as Intel's PXE ROM exhibits. Together with a qemu patch to handle the ERROR packet (submitted to qemu's mailing list), this resolves a specific issue where booting pxegrub with qemu's TFTP server would be slow or hang. I've tested this against qemu's tftp server and against my normal boot infrastructure (tftpd-hpa). Booting pxegrub and loading extra files now produces a trace similar to Intel's PXE client and there are no spurious retransmits from tftpd any more. Signed-off-by: Thomas Horsten Signed-off-by: Milan Plzik Signed-off-by: Stefan Hajnoczi Signed-off-by: Marty Connor

[tftp] Remove unnecessary delay when opening a connection

2010-01-15T21:04:33+00:00

The retry timer is used to retransmit TFTP packets lost on the network, and to start a new connection. There is an unnecessary delay while waiting for name resolution because the timer period is fixed and cannot be shortened when name resolution completes. This patch keeps the timer period at zero while name resolution takes place so that no time is lost once before sending the first packet. Reported-by: Thomas Horsten Signed-off-by: Stefan Hajnoczi Signed-off-by: Marty Connor

[tftp] Allow fetching larger files by wrapping block number

2010-01-15T20:54:36+00:00

This patch adds TFTP support for files larger than 65535 blocks by wrapping the 16-bit block number. Reported-by: Mark Johnson Signed-off-by: Stefan Hajnoczi Signed-off-by: Marty Connor

[dhcp] Assume PXE options are in DHCPOFFER only if boot menu is included

2010-01-14T23:34:55+00:00

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

[dhcp] Accept ProxyDHCP replies of type DHCPOFFER

2010-01-14T23:33:31+00:00

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

[dhcp] Ensure message type is first DHCP option

2010-01-14T16:13:10+00:00

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

[settings] Add Bus ID setting

2009-12-14T17:54:53+00:00

Users can find the bus type and PCI IDs for a network interface with: netX/busid Signed-off-by: Stefan Hajnoczi