Some applications/devices seem to forget their MAC address when
performing some kind of a failover which triggers (something that
looks like) a gratuities arp.
The ARP packet looks something like this:
Address Resolution Protocol (reply)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reply (2)
Sender MAC address: 00:00:00:00:00:00
Sender IP address: 10.0.0.1
Target MAC address: 00:00:00:00:00:00
Target IP address: 255.255.255.255
This will result in existing arp entries being overwritten with an all
zero mac address. Until the arp entry times out this host can no
longer initiate a connection to this device.
Checking for and ignoring invalid mac addresses will solve this
problem.
Signed-off-by: Eelco Chaudron <echau...@redhat.com>
---
net/ipv4/arp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index a8d7c5a9fb05..e60c88b203e9 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -750,6 +750,16 @@ static int arp_process(struct net *net, struct sock *sk,
struct sk_buff *skb)
case ARPHRD_IEEE1394:
break;
#endif
+ case ARPHRD_ETHER:
+ case ARPHRD_FDDI:
+ case ARPHRD_IEEE802:
+ /*
+ * Check for bad sender hardware addresses. An all zero MAC
+ * address is not valid for Ethernet, FDDI or IEEE802.
+ */
+ if (is_zero_ether_addr(sha))
+ goto out_free_skb;
+ break;
default:
tha = arp_ptr;
arp_ptr += dev->addr_len;
--
2.13.6
