openslx-ng/ipxe.git/src/net/arp.c, branch v1.20.1

[arp] Validate length of ARP packet

2016-03-12T01:24:03+00:00

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

[ipoib] Attempt to generate ARPs as needed to repopulate REMAC cache

2015-06-29T13:50:16+00:00

The only way to map an eIPoIB MAC address (REMAC) to an IPoIB MAC address is to intercept an incoming ARP request or reply. If we do not have an REMAC cache entry for a particular destination MAC address, then we cannot transmit the packet. This can arise in at least two situations: - An external program (e.g. a PXE NBP using the UNDI API) may attempt to transmit to a destination MAC address that has been obtained by some method other than ARP. - Memory pressure may have caused REMAC cache entries to be discarded. This is fairly likely on a busy network, since REMAC cache entries are created for all received (broadcast) ARP requests. (We can't sensibly avoid creating these cache entries, since they are required in order to send an ARP reply, and when we are being used via the UNDI API we may have no knowledge of which IP addresses are "ours".) Attempt to ameliorate the situation by generating a semi-spurious ARP request whenever we find a missing REMAC cache entry. This will hopefully trigger an ARP reply, which would then provide us with the information required to populate the REMAC cache. Signed-off-by: Michael Brown

[legal] Relicense files under GPL2_OR_LATER_OR_UBDL

2015-03-02T16:35:29+00:00

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

[neighbour] Generalise concept of neighbour discovery

2013-09-03T01:02:58+00:00

Split the protocol-independent portions of arp.c into a separate file neighbour.c, to allow for sharing of functionality between IPv4+ARP and IPv6+NDP. Signed-off-by: Michael Brown

[arp] Increase robustness of ARP discarder

2012-10-19T22:03:38+00:00

Take ownership from the ARP cache at the start of arp_destroy(), to ensure that no code path can lead to arp_destroy() being re-entered. Signed-off-by: Michael Brown

[legal] Update FSF mailing address in GPL licence texts

2012-07-20T18:55:45+00:00

Suggested-by: Daniel P. Berrange Signed-off-by: Michael Brown

[arp] Try to avoid discarding ARP cache entries

2012-07-09T09:08:38+00:00

Discarding the active ARP cache entry in the middle of a download will substantially disrupt the TCP stream. Try to minimise any such disruption by treating ARP cache entries as expensive, and discarding them only when nothing else is available to discard. Signed-off-by: Michael Brown

[arp] Prevent ARP cache entries from being deleted mid-transmission

2012-07-01T17:31:23+00:00

Each ARP cache entry maintains a transmission queue, which is sent out as soon as the link-layer address is known. If multiple packets are queued, then it is possible for memory pressure to cause the ARP cache discarder to be invoked during transmission of the first packet, which may cause the ARP cache entry to be deleted before the second packet can be sent. This results in an invalid pointer dereference. Avoid this problem by reference-counting ARP cache entries and ensuring that an extra reference is held while processing the transmission queue, and by using list_first_entry() rather than list_for_each_entry_safe() to traverse the queue. Signed-off-by: Michael Brown

[arp] Maintain an ARP transmission queue

2012-03-02T23:46:29+00:00

Allow packet transmission to be deferred pending successful ARP resolution. This avoids the time spent waiting for a higher-level protocol (e.g. TCP or TFTP) to attempt retransmission. Signed-off-by: Michael Brown

[netdevice] Allow link layer to report broadcast/multicast packets via pull()

2011-07-15T17:48:46+00:00

Allow the link layer to directly report whether or not a packet is multicast or broadcast at the time of calling pull(), rather than relying on heuristics to determine this at a later stage. Signed-off-by: Michael Brown