Дивно: чому Linux відповідає на ping запитом ARP після останньої відповіді ping?

Я (і колега) щойно помітили і перевірили, що коли машина Linux працює під пінг, після останнього пінгу вона ініціює одноадресний запит ARP до машини, яка ініціювала пінг ICMP. Під час пінг-пам’яті на машині Windows машина в кінці не видає запит ARP.

Хтось знає, яка мета цього одноадресного запиту ARP, і чому він виникає в Linux, а не в Windows?

Слід Wireshark (коли 10.20.30.45 є вікном Linux):

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

Оновлення: я лише погуглив ще кілька запитів на одноадресний ARP-запит , і єдина корисна посилання, яку я знайшла, - це RFC 4436, який стосується "Виявлення мережевого вкладення" (з 2006 р.). Ця методика використовує одноадресні ARP, щоб хост міг визначити, чи він підключений до раніше відомої мережі. Але я не бачу, як це стосується запиту ARP в результаті виконання ping. Тож таємниця залишається ...

Linux надсилає різні одноадресні ARP-запити для оновлення кешу ARP. Це робиться для запобігання устарених (і потенційно шкідливих) записів кешу ARP.

Є кілька ситуацій, коли використовується одноадресований ARP, в основному для перевірки кешу ARP. Якщо запис несвіжий, тоді резервна передача - це трансляція ARP.

Про це йдеться в RFC1122 2.3.2.1

Я думаю, що це робиться, і чому, моя перша здогадка була б якоюсь мірою проти підробки. Пакети ARP завжди не маршрутизуються, тому я припускаю, що ви робите це у вашій локальній локальній мережі? Чи трапляється ця ситуація послідовно кожного разу, коли ви звертаєтесь до хазяїна чи ви один раз простежуєте це? У цьому випадку кеш ARP для цього хоста, можливо, вийшов випадково.

Яка ОС працює на хості, з якого ви пінг-машини?

Я думаю, що це помилка. Наступний слід - від ping до адреси, яка знаходиться в кеші ARP, але несвіжа. Я не можу придумати жодної вагомої причини, щоб зняти ARP двічі за такий короткий час. Це з 4.14.15, але я бачив поведінку у багатьох версіях ядра.

root@observer:~# tcpdump -nevi eth0 arp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:11:57.362910 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.1 tell 10.1.2.2, length 28
13:11:57.363018 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.1 is-at 42:5f:03:40:00:22, length 28
13:11:57.392890 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.2 tell 10.1.2.1, length 28
13:11:57.393049 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.2 is-at 42:5f:03:40:00:43, length 28

Лише здогадка .. але це може бути "особливістю" для реєстрації MAC-адреси клієнта, коли машина відповідає на серію ping або певну кількість пінгів. Це може бути корисною інформацією для відстеження пінг-спаму.