Garip: Linux neden son ping cevabından sonra ARP isteği ile ping'e cevap veriyor?

Ben (ve bir meslektaşım) bir Linux makinesine ping atıldığında, son ping'ten sonra ICMP ping'i başlatan makineye tek noktaya yayın ARP isteği başlattığını fark ettim ve test ettim . Bir Windows makinesine ping işlemi yaparken, Windows makinesi sonunda bir ARP isteği yayınlamaz.

Herkes bu tek noktaya yayın ARP isteğinin amacının ne olduğunu ve neden Windows'ta değil Linux'ta gerçekleştiğini biliyor mu?

Wireshark izi (10.20.30.45 bir Linux kutusu olacak şekilde):

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

Güncelleme: Tek noktaya yayın ARP istekleri için biraz daha googledim ve bulduğum tek yararlı referans RFC 4436'da "Ağ Ekini Tespit Etme " (2006'dan itibaren). Bu teknik, bir ana bilgisayarın önceden bilinen bir ağa yeniden bağlanıp bağlanmadığını belirlemesine izin vermek için tek noktaya yayın ARP'lerini kullanır. Ancak bunun, bir ping işlemi sonucunda bir ARP isteği için nasıl geçerli olduğunu görmüyorum. Böylece gizem devam ediyor ...

Linux, ARP önbelleğini güncellemek için çeşitli tek noktaya yayın ARP istekleri gönderir. Bu, eski (ve potansiyel olarak kötü amaçlı) ARP önbellek girdilerini önlemektir.

Temel olarak ARP önbelleğini doğrulamak için tek noktaya yayın ARP'nin kullanıldığı birkaç durum vardır. Giriş eskiyse, geri dönüş ARP yayınlamaktır.

Bu RFC1122 2.3.2.1'de tartışılmıştır.

Bence ilk tahminim bir tür sahteciliğe karşı önlem olurdu. ARP paketleri her zaman yönlendirilmez, bu yüzden bunu yerel LAN'ınızda yaptığınızı varsayıyorum? Bu durum, toplantı sahibine her ping attığınızda veya bir kez izlediğinizde tutarlı bir şekilde mi oluyor? Bu durumda, bu ana bilgisayarın ARP önbelleği tesadüfen zaman aşımına uğramış olabilir.

Makineye ping attığınız ana bilgisayarda hangi işletim sistemi çalışıyor?

Bence bu bir hata. Aşağıdaki iz, ping işleminden ARP önbelleğindeki ancak eski olan bir adrese yapılır. Bu kadar kısa sürede ARP'yi iki kez tek noktaya yayınlamak için iyi bir neden düşünemiyorum . Bu 4.14.15 ile ama birçok çekirdek sürümü üzerinde davranış gördüm.

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

Sadece bir tahmin .. ama bu makine bir ping serisine veya belirli sayıda pinge cevap verdiğinde istemcinin MAC adresini kaydetmek için bir 'özellik' olabilir. Ping spam'ını izlemek için yararlı bilgiler olabilir.