2

I'm wondering why I get the following result :

if I try to access a non-existing host on my local network, for instance using the command ping, I see with the tcpdump arp command that there is every second a who-has request sent by my computer but I get three messages Destination Host Unreachable in a row every three seconds.

Can you please explain me why ?

Simon
  • 137
  • 1
  • 5

2 Answers2

3

From http://linux-ip.net/html/ether-arp.html:

If no ARP cache entry exists for a requested destination IP, the kernel will generate mcast_solicit ARP requests until receiving an answer. During this discovery period, the ARP cache entry will be listed in an incomplete state. If the lookup does not succeed after the specified number of ARP requests, the ARP cache entry will be listed in a failed state. If the lookup does succeed, the kernel enters the response into the ARP cache and resets the confirmation and update timers.

You can find the value of mcast_solicit in e.g. /proc/sys/net/ipv4/neigh/eth0/mcast_solicit. I'm not sure whether the timeout before retransmission of the arp request is tunable but empirically it is 1 second.

As it takes 3 retries before concluding that the host isn't reachable, the ping packets are queued up for 3 seconds, Then they are all rejected together because the state is "unreachable". Then the story begins again, explaing the 3-second clustering of the error messages.

wurtel
  • 3,864
  • 12
  • 15
  • Note also that you can use this to distinguish between a non-existent host and a host that's simply blocking pings on the local network, like Windows systems seem to do a lot lately: the firewalled host will respond to the ARP so no "host unreachable error", but also no ping response. – wurtel Jul 23 '15 at 09:41
  • Thank you very much, I understand well now. I'm just not totally sure to understand why it takes 3 retries before concluding that the host isn't reachable. Can you please briefly explain it ? – Simon Jul 23 '15 at 13:55
  • There is always some level of retry involved in such operations. I don't know where the 1 second timeout comes from, but the 3 times retry is defined in `/proc/sys/net/ipv4/neigh/eth0/mcast_solicit` as I wrote above. – wurtel Jul 24 '15 at 11:53
0

The host does not exist to respond to the ARP query. So your client is unable to even craft an ICMP packet, destined to the "would be" MAC address of the IP you are trying to ping. In fact, nothing your computer can do would enable it to craft such a packet if it is unable to resolve the MAC address through ARP. As such, that destination host is unequivocally unreachable.

Had that host existed, it would have responded to the ARP request, and your client would then be able to form the ICMP Echo packet. IF the host then chose not to respond (maybe because it is dropping ICMP traffic), your client would have successfully sent the ICMP Echo, but never received an ICMP Echo Reply. Your Ping would then report something along the lines of Request Timed Out.

Eddie
  • 193
  • 6
  • Okay, but why do I get the ping responses three by three ? (That's the point of my question.) – Simon Jul 22 '15 at 22:44
  • Ahh, I misunderstood. I thought you were inquiring about "destination host unreachable" vs "request timed out". It might be a display issue. If you manually set the delay between each ping to 5s, how often do you get the Destination Host Unreachables? – Eddie Jul 22 '15 at 22:53
  • If I set the delay between each ping to 5 seconds I get a message "destination host unreachable" every 5 seconds but there is an ARP request sent every seconds during 3 seconds then a break of 3 seconds and it starts again... Any ideas ? – Simon Jul 22 '15 at 23:03