Strange: why does linux respond to ping with ARP request after last ping reply?
I (and a colleague) have just noticed, and tested, that when a Linux machine is pinged, after the last ping it initiates a unicast ARP request to the machine that initiated the ICMP ping. When pinging to a Windows machine, the Windows machine does not issue an ARP request at the end.
Does anybody know what the purpose is of this unicast ARP request, and why it occurs on Linux and not on Windows?
The Wireshark trace (with 10.20.30.45 being a Linux box):
No.Time Source Destination Prot Info
19 10.905277 10.20.30.14 10.20.30.45 ICMP Echo (ping) request
20 10.905339 10.20.30.45 10.20.30.14 ICMP Echo (ping) reply
21 11.904141 10.20.30.14 10.20.30.45 ICMP Echo (ping) request
22 11.904173 10.20.30.45 10.20.30.14 ICMP Echo (ping) reply
23 12.904104 10.20.30.14 10.20.30.45 ICMP Echo (ping) request
24 12.904137 10.20.30.45 10.20.30.14 ICMP Echo (ping) reply
25 13.904078 10.20.30.14 10.20.30.45 ICMP Echo (ping) request
26 13.904111 10.20.30.45 10.20.30.14 ICMP Echo (ping) reply
27 15.901799 D-Link_c5:e7:ea D-Link_33:cb:92 ARP Who has 10.20.30.14? Tell 10.20.30.45
28 15.901855 D-Link_33:cb:92 D-Link_c5:e7:ea ARP 10.20.30.14 is at 00:05:5d:33:cb:92
Update: I've just googled some more for unicast ARP requests, and the only useful reference I've found is in RFC 4436 which is about "Detecting Network Attachment" (from 2006). This technique uses unicast ARPs to allow a host to determine whether it is reconnected to a previously known network. But I don't see how this applies to an ARP request as a result of doing a ping. So the mystery remains...
Solution 1:
Linux sends various unicast ARP requests to update it's ARP cache. This is to prevent stale (and potentially malicious) ARP cache entries.
There are a few situations where unicast ARP is used, basically to validate the ARP cache. If the entry is stale, then the fallback is to broadcast ARP.
This is discussed in RFC1122 2.3.2.1
I think that is what it is doing, as to why, my first guess would be some sort of anti-spoofing measure. ARP packets are always never routed, so I'm presuming you're doing this on your local LAN? Does this situation happen consistently every time you ping the host or have you just traced one time? In which case, the ARP cache for that host may have been timing out coincidentally.
What OS is running on the host you are pinging the machine from?
Solution 2:
I think it's a bug. The following trace is from a ping to an address that is in the ARP cache but stale. I can't think of any good reason to unicast ARP twice in such a short time. This is with 4.14.15 but I've seen the behaviour over many kernel versions.
root@observer:~# tcpdump -nevi eth0 arp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:11:57.362910 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.1 tell 10.1.2.2, length 28
13:11:57.363018 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.1 is-at 42:5f:03:40:00:22, length 28
13:11:57.392890 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.2 tell 10.1.2.1, length 28
13:11:57.393049 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.2 is-at 42:5f:03:40:00:43, length 28