UDP sockets can be used for multicast, at which point it becomes
plausible that we could receive packets that aren't destined for us
but that still match on a port number.
Maintain state for the advertised window length, and only ever increase
it (instead of calculating it afresh on each transmit). This avoids
triggering "treason uncloaked" messages on Linux peers.
Respond to zero-length TCP keepalives (i.e. empty data packets
transmitted outside the window). Even if the peer wouldn't otherwise
expect an ACK (because its packet consumed no sequence space), force an
ACK if it was outside the window.
We don't yet generate TCP keepalives. It could be done, but it's unclear
what benefit this would have. (Linux, for example, doesn't start sending
keepalives until the connection has been idle for two hours.)
Return the most appropriate of EACCES, EPERM, ENODEV, ENOTSUP, EIO or
EINVAL depending on the exact error returned by the target, rather than
just always returning EPERM.
Also, ensure that error strings exist for these errors.
From: Viswanath Krishnamurthy <viswa.krish@gmail.com>
The current ipv4 incorrectly checks the IP address for multicast address.
This causes valid IPv4 unicast address to be trated as multicast address
For e.g if the PXE/tftp server IP address is 192.168.4.XXX where XXX is
224 or greater, it gets treated as multicast address and a ethernet
multicast address is sent out on the wire causing timeouts
Some EMC targets will fail if we advertise that we can authenticate with
CHAP, but the target is configured to allow unauthenticated access to that
target. We advertise AuthMethod=CHAP,None; the target should (I think)
select AuthMethod=None for unprotected targets. IETD does this, but an
EMC Celerra NS83 doesn't.
Fix by offering only AuthMethod=None if the user hasn't supplied a
username and password; this means that we won't be offering CHAP
authentication unless the user is expecting to use it (in which case the
target is presumably configured appropriately).
Many thanks to Alessandro Iurlano <alessandro.iurlano@gmail.com> for
reporting and helping to diagnose this problem.
Infiniband devices no longer block waiting for link-up in
register_ibdev().
Hermon driver needs to create an event queue and poll for link-up events.
Infiniband core needs to reread MAD parameters when link state changes.
IPoIB needs to cope with Infiniband link parameters being only partially
available at probe and open time.
gPXE is not compliant with the HTTP/1.1 specification (RFC 2616),
since it lacks support for "Transfer-Encoding: chunked". gPXE is,
however, compliant with the HTTP/1.0 specification (RFC 1945), which
does not require "Transfer-Encoding: chunked" to be supported.
The only HTTP/1.1 feature that gPXE uses is the "Host:" header, but
servers universally accept that one from HTTP/1.0 clients as an
optional extension (it is obligatory for HTTP/1.1). gPXE does not,
for example, appear to support connection caching. Advertising as a
HTTP/1.0 client will typically make the server close the connection
immediately upon sending the last data, which is actually beneficial
if we aren't going to keep the connection alive anyway.
The PXE spec is (as usual) unclear on precisely when ProxyDHCPREQUESTs
should be issued. We adapt the following, slightly paranoid approach:
If an offer contains an IP address, then it is a normal DHCPOFFER.
If an offer contains an option #60 "PXEClient", then it is a
ProxyDHCPOFFER. Note that the same packet can be both a normal
DHCPOFFER and a ProxyDHCPOFFER.
After receiving the normal DHCPACK, if we have received a
ProxyDHCPOFFER, we unicast a ProxyDHCPREQUEST back to the ProxyDHCP
server on port 4011. If we time out waiting for a ProxyDHCPACK, we
treat this as a non-fatal error.
Allow for settings to be described by something other than a DHCP option
tag if desirable. Currently used only for the MAC address setting.
Separate out fake DHCP packet creation code from dhcp.c to fakedhcp.c.
Remove notion of settings from dhcppkt.c.
Rationalise dhcp.c to use settings API only for final registration of the
DHCP options, rather than using {store,fetch}_setting throughout.
Add dedicated functions create_dhcpdiscover(), create_dhcpack() and
create_proxydhcpack() for use by external code such as the PXE preboot
code.
Register ProxyDHCP options under the global scope "proxydhcp".
Unregister previously-acquired DHCP and ProxyDHCP settings when DHCP
succeeds.
Add a configuration settings block for each net device. This will
provide the parent scope for settings applicable only to that network
device (e.g. non-volatile options stored on the NIC, options obtained via
DHCP, etc.).
Expose the MAC address as a setting.
RFC 4390 provides for the DHCP client identifier to contain the link-layer
hardware type and MAC address when the MAC address exceeds 16 bytes.
However, the hardware type field is only 8 bits; we were assuming 16 bits.
Arbel and Hermon cards both have multiple ports. Add the
infrastructure required to register each port as a separate IB
device. Don't yet register more than one port, since registration
will currently fail unless a valid link is detected.
Use ib_*_{set,get}_{drv,owner}data wrappers to access driver- and
owner-private data on Infiniband structures.
Pull out common code for handling management datagrams from arbel.c
and hermon.c into infiniband.c.
Add port number to struct ib_device.
Add open(), close() and mad() methods to struct ib_device_operations.
Allow port numbers in iSCSI redirection.
Wait for SCSI status, not just the final data-in (which may be followed
by an explicit SCSI Response PDU if the S bit is not set).
