Estranho: por que o linux responde ao ping com o pedido ARP após a última resposta do ping?

Question

Eu (e um colega) acabamos de notar e testamos que, quando uma máquina Linux recebe um ping, após o último ping, inicia uma solicitação ARP unicast para a máquina que iniciou o ping ICMP. Ao efetuar o ping para uma máquina Windows, a máquina Windows não emite uma solicitação ARP no final.

Alguém sabe qual é o propósito dessa solicitação ARP unicast e por que ela ocorre no Linux e não no Windows?

O traçado Wireshark (com 10.20.30.45 sendo uma caixa do 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

Atualização: Acabei de pesquisar mais um pouco para solicitação ARP unicast , e a única referência útil que encontrei está em RFC 4436 que é sobre "Detecting Network Attachment" (de 2006). Essa técnica usa ARPs unicast para permitir que um host determine se é reconectado a uma rede conhecida anteriormente. Mas não vejo como isso se aplica a uma solicitação ARP como resultado de um ping. Então o mistério permanece ...

    

Answer 1

O Linux envia várias solicitações ARP unicast para atualizar seu cache ARP. Isso é para evitar entradas de cache ARP obsoletas (e potencialmente maliciosas).

Existem algumas situações em que o ARP unicast é usado, basicamente para validar o cache do ARP. Se a entrada for obsoleta, o substituto será para transmitir ARP.

Isso é discutido em RFC1122 2.3.2.1

Acho que é isso que está fazendo, por que, meu primeiro palpite seria algum tipo de medida antifalsificação. Os pacotes ARP nunca são roteados, por isso presumo que você esteja fazendo isso em sua LAN local? Essa situação ocorre consistentemente toda vez que você faz o ping no host ou você acabou de rastrear uma vez? Nesse caso, o cache ARP para esse host pode ter coincidido por coincidência.

Qual sistema operacional está sendo executado no host do qual você está pingando a máquina?

    

Answer 2

Eu acho que é um bug. O rastreamento a seguir é de um ping para um endereço que está no cache do ARP, mas obsoleto. Não consigo pensar em nenhuma boa razão para unicast ARP duas vezes em tão pouco tempo. Isto é com 4.14.15, mas eu vi o comportamento em muitas versões do kernel.

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

    

Answer 3

Apenas um palpite ... mas isso pode ser um "recurso" para registrar o endereço MAC do cliente sempre que a máquina responder a uma série de ping ou a um determinado número de pings. Pode ser uma informação útil para rastrear spam de ping.