Fork of ipxe; additional commands and features https://git.openslx.org/openslx-ng/ipxe.git/atom/src/net/udp?h=v0.9.8 2009-08-11T23:27:08+00:00 2009-08-11T23:27:08+00:00 Michael Brown 2009-08-11T22:44:04+00:00 urn:sha1:444d5550a70fef7735ed1821a0e6f8410f0e03ef 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; } 2009-05-22T04:42:57+00:00 Michael Brown 2009-05-21T09:22:42+00:00 urn:sha1:c345336435b6a7a784e5e7cb54b1c9c1321fa583 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.) 2009-05-20T09:04:50+00:00 Michael Brown 2009-05-20T09:03:13+00:00 urn:sha1:1958974d0a59e0e374751d9d5c1405de0ffc8066 IBM Tivoli PXE Server 5.1.0.3 is reported to send trailing garbage bytes at the end of the OACK packet, which causes gPXE to reject the packet and abort the TFTP transfer. Work around the problem by processing as much as possible of the OACK, and treating name/value parsing errors as non-fatal. Reported-by: Shao Miller <Shao.Miller@yrdsb.edu.on.ca> 2009-05-20T07:47:39+00:00 Michael Brown 2009-05-20T07:16:51+00:00 urn:sha1:3961c1ca02ad3c8ce1dbc725eb07411e1dbee1d8 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> 2009-05-20T06:56:29+00:00 Michael Brown 2009-05-19T14:54:35+00:00 urn:sha1:9119b0c8af15333796e02433677a54e952b1a73d 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> 2009-05-18T07:33:25+00:00 Michael Brown 2009-05-01T14:41:06+00:00 urn:sha1:c44a193d0d147ed6f98741124569864e516e9d4b Add FILE_LICENCE declarations to almost all files that make up the various standard builds of gPXE. 2009-03-30T12:24:56+00:00 Michael Brown 2009-03-30T12:24:56+00:00 urn:sha1:323cdf8c4c510fc6da081b96994d0131c11a29dd When handling a redirection event, we need to close the existing connection before opening the new connection. 2009-03-13T02:10:21+00:00 Michael Brown 2009-03-13T00:13:38+00:00 urn:sha1:3c68ff99eaff6e0d615349bdc85ea12ad8345284 Eliminate the potential for mismatches between table names and the table entry data type by incorporating the data type into the definition of the table, rather than specifying it explicitly in each table accessor method. 2009-03-13T02:06:30+00:00 Michael Brown 2009-03-12T19:41:40+00:00 urn:sha1:1266d7902bf7f2534ee279671d48613ef9b2434c Intel's C compiler (icc) chokes on the zero-length arrays that we currently use as part of the mechanism for accessing linker table entries. Abstract away the zero-length arrays, to make a port to icc easier. Introduce macros such as for_each_table_entry() to simplify the common case of iterating over all entries in a linker table. Represent table names as #defined string constants rather than unquoted literals; this avoids visual confusion between table names and C variable or type names, and also allows us to force a compilation error in the event of incorrect table names. 2009-02-17T22:03:28+00:00 Michael Brown 2009-02-17T22:03:28+00:00 urn:sha1:7b1a5a7997e3673f75bf9eaaaffebd90adec89fc This change makes it possible to break the PXE-chaining infinite loop even when restricted to a Windows DHCP server.