Linux – Strange: why does linux respond to ping with ARP request after last ping reply

arpicmpkernellinuxping

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…

Best Answer

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?

Related Topic