6

This problem was presented to me by one of my professors because it only happened after switching from 100Mb cards to Gigabit NICs. The second arp request that comes from the computer being pinged (to send a reply back) doesn't get sent until after the pings have gone through.

I decided to do some testing at home with a couple VMs and see if I could find the cause.

Wireshark Capture Example

After clearing the arp cache on both machines (arp -d) and pinging I got the same results as my professor, but I can't seem to figure out why.

I did some googling and found someone with a similar issue using linux (I'm using Windows 10), it said something about there being a stale entry within the arp table as well as something called a first probe delay, but I was never able to find any information about either of those things for Windows.

Does anyone know why this might be happening? Or what that second arp request is for if it isn't to find the first device?

SkyParrillo
  • 61
  • 2
  • Yeah it is interesting. The ping reply was done without an arp, because the origin was on the same network and so the reply mac address was on the incoming packet. Then later, there is a unicast arp (rather than the traditional broadcast) - so the destination device already had an arp entry (extracted from the ping) and looks like it was validating it. Perhaps arp entries are marked to go stale faster when gathered through this method. – Paul Sep 24 '18 at 02:11
  • Is there anyway to prove this is what is happening? Or any way to view how long an entry is stale for on windows? Is it the same on Linux as windows? – SkyParrillo Sep 24 '18 at 10:42
  • I am just surmising. Going by Appleoddity's answer below, the destination is populating its arp table. But note that it specifically asks the mac address rather than broadcast, so layer 2 must have kept the mac from the ping. I don't know the inner workings of the Windows stack to be certain, hence the comment rather than answer. – Paul Sep 24 '18 at 10:49

1 Answers1

2

This appears to be what Bruce Hartpence calls a “Return ARP.” As described in this excerpt from Packet Guide to Core Network Protocols.

The conversation shown in Figure 4-12 illustrates another important facet of ARP—only the host originating the conversation (generating the ARP request) will place an entry for the destination host in its local ARP table. That is, other stations hearing the exchange, even if they are receiving the ARP request, will not add these stations to their own ARP tables. However, many hosts (especially routers) are aggressive when it comes to populating their tables and, upon hearing ARP traffic or being involved in ARP messages, will subsequently generate their own ARP requests to populate their tables.

Short answer. The destination host is populating it’s own ARP table now that it knows about the other host.

Appleoddity
  • 11,565
  • 2
  • 24
  • 40
  • Would this still explain why there used to be two arp requests at the beginning of the ping before the NICs were changed? – SkyParrillo Sep 24 '18 at 10:35