Windows – ny way to ARP ping on Windows

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?

After testing it does seem that Hotfix 2582281 fixes the issue. You can get the hotfix without having to pay support by using their hotfix request page.

I ran a test of this using arping and unpatched windows 2008 R2. I added a secondary IP, 64.34.119.80, to a machine with in the same network L2 segment. I then issued the following command from a different machine the network (sudo arping -U 64.34.119.80 -I bond0 -c1). Right after that, I pinged 64.34.119.80 from the windows box after seeing it recieve the arp in wireshark. I then applied the hotfix and repeated the test.

Also, it seems that the arping command needs to not use unicast MAC address but rather the broadcast MAC because this is the only type of GARP ignored from my tests.

Before the patch:

In this wireshark capture, the ping after the GARP request is not sent to the MAC Destination that the GARP came from, so you can see that GARP is being ignored.

After the patch:

In this test, after the patch, the GARP request seems to be honored as the ping is sent to the MAC address that GARP came from.

So from these tests it seems hotfix 2582281 fixes the issue of GARP broadcasts being ignored.