奇怪:为什么在最后的ping回复后,linux响应ping请求呢?

我(和一位同事)刚刚注意到并testing过,当一台Linux机器被ping通时,在最后一次ping之后,它向发起ICMP ping的机器发起一个单播 ARP请求。 对Windows机器执行ping操作时,Windows机器最终不会发出ARP请求。

有人知道这个单播ARP请求的目的是什么,为什么它发生在Linux而不是Windows?

Wireshark跟踪(Linux 10.20.30.45):

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 

更新:我刚刚search了更多的单播ARP请求 ,我发现唯一有用的参考是在RFC 4436是关于“检测networking附件”(从2006年)。 该技术使用单播ARP来允许主机确定它是否重新连接到先前已知的networking。 但我不明白这是如何适用于一个ARP请求作为一个ping的结果。 所以这个谜还是…

Linux发送各种单播ARP请求来更新它的ARPcaching。 这是为了防止陈旧的(和潜在的恶意)ARP高速caching条目。

有几种情况使用单播ARP,基本上是validationARPcaching。 如果条目陈旧,则回退是广播ARP。

这在RFC1122 2.3.2.1中进行了讨论

我认为这就是为什么,我的第一个猜测是某种反欺骗措施。 ARP数据包永远不会路由,所以我假设你正在你的本地局域网上做这个? 这种情况是否在每次ping主机时都一致发生,或者您只是追踪一次? 在这种情况下,该主机的ARPcaching可能是巧合超时的。

在主机上运行什么操作系统?

只是猜测..但是这可能是一个“function”来logging客户端的MAC地址,只要机器应答ping系列或一定数量的ping。 这可能是有用的信息来追踪ping垃圾邮件。