Diferença entre arp -a e nmap -sn?

arp -a imprime uma lista em cache de hosts / dispositivos que estão se comunicando com este host. Portanto, se você vir seu plugue inteligente e outros dispositivos aparecendo na saída, é a prova de que eles estavam se comunicando com este host desde a última reinicialização do Pi ou reinício do sua “rede .

Em poucas palavras:

Seu nmap está fazendo varredura OUTWARD da sub-rede especificada do Pi.

Seu arp a saída é uma lista de IP: mapeamentos de endereços mac de hosts com os quais seu pi trocou tráfego.

Assim, a varredura nmap pode mostrar muitos hosts, enquanto o cache arp informa apenas hospeda seu Pi está se comunicando

O cache ARP de um Pi em 192.168.1.21 é mostrado abaixo:

arp -av gateway (192.168.1.18) at d4:ca:6d:XX:XX:5e [ether] on eth0 gateway (192.168.3.126) at d6:ca:6d:XX:XX:26 [ether] on wlan0 pi3Bplus-2 (192.168.1.22) at b8:27:eb:XX:XX:3c [ether] on eth0 

A saída arp mostrará ip: endereço mac mapeamentos para (2) tipos de hosts:

A) hosts (” ou seja, pi3Bplus-2 “) dentro da mesma sub-rede do seu pi, que pode trocar tráfego diretamente e

B) Roteadores (“isto é, gateway “) necessários para rotear o tráfego para hosts fora da sub-rede do seu host.

Observe que 192.168.1. 22 está em 192.168.1. 21 “cache: Isso é porque eu pinguei 0,22 de 0,21. Então, uma entrada i n o cache arp é a prova da conectividade correta entre os hosts ao solucionar problemas. Obviamente, se o ICMP fosse bloqueado em um firewall, o ping falharia e o host “s IP: mac não estaria presente no cache arp.

Observe também que o cache arp NÃO persistente! se você reiniciar o Pi ou mesmo a rede, ele irá explodir o cache arp. O que você pode realmente querer fazer ao testar.

Comentários

• Há algumas coisas em sua resposta que podem ser confusas. Citação: ” it ‘ s prova eles estavam conversando com este host desde a última reinicialização do Pi ou reinício de sua ‘ rede. ” – Não, o endereço IP é removido do cache após 5 minutos se não havia ‘ ta (nova, continuada, etc.) conexão antes. Se você continuar uma conexão após 10 min, então há uma novo pedido ARP. Even th se o dispositivo remoto estiver ativo, você não o encontrará no cache por 5 minutos.
• Citação: ” Portanto, uma entrada no cache arp é prova de conectividade correta entre hosts ” – Não, se você desligar o dispositivo remoto e olhar o cache arp em 5 minutos, encontrará seu endereço IP. Isso tudo pode confundir a solução de problemas porque as coisas podem funcionar, mas pouco tempo depois não ‘ t, em particular se a solicitação ARP em uma direção não ‘ t funciona corretamente.
• @Ingo arp envelhecimento deveria funcionar assim, mas minha experiência é que a coleta de lixo não ‘ purga entradas obsoletas de acordo com o período definido. Os testes em minha resposta foram feitos usando 2 Pi ‘ s endereçados na mesma sub-rede (conectado ao mesmo switch) pingando um ao outro algumas vezes & interrompendo seus pings. Se você repetir este teste e executar ip -statistics neighbour periodicamente, ‘ verá as entradas arp marcadas como ” obsoleto ” permanece mesmo se tiver mais de 20 minutos! Portanto, entendi como o envelhecimento do arp deve funcionar, mas repita o e você ‘ verá que as entradas podem durar muito mais que 5 minutos. Excelente ponto, entretanto !!!
• Acabei de fazer experiências diferentes;) Ao trabalhar com arp proxy me deparei com uma situação em que a solicitação arp só funciona em uma direção, do dispositivo remoto para o RasPi. A conexão só funcionou quando o dispositivo remoto foi conectado ao RasPi – por 5 min.O contrário às vezes funcionou (dentro de 5 minutos após a conexão remota) e às vezes não ‘ t. Foi muito difícil encontrar esse erro intermitente (resolvido com o modo promíscuo).
• De qualquer forma – o que nossa discussão mostra e o que eu acredito: pedir endereços IP ao cache arp não é uma solução segura, a menos que você execute ping no endereço de broadcast antes de olhar para o cache arp. Mas essa ‘ é uma possibilidade que não vou sugerir por causa da carga da rede.

Esta não é uma pergunta específica do Raspberry Pi. De qualquer forma, darei uma resposta detalhada porque encontrar o endereço IP de um Raspberry Pi é uma pergunta e um problema muito frequentes aqui.

nmap é um scanner de rede e faz o que você espera: verifica ativamente a rede em busca de dispositivos.

O comando arp (é melhor usar ip neighbor) não é um scanner. Mostra apenas o conteúdo do cache arp local.

Para estabelecer conexões ethernet, o protocolo arp é usado. Ele pergunta quais dispositivos ethernet com endereço mac têm qual endereço IP. O mapeamento encontrado do endereço mac para o endereço IP é armazenado no cache arp local, por padrão, por 5 minutos. Este mapeamento ocorre para cada conexão estabelecida, mesmo quando o dispositivo remoto não responde a ping consultas. Mas isso também implica que você não encontrará um dispositivo no cache arp se não tiver havido uma conexão nos últimos 5 minutos.

Seu comando nmap -sn 192.168.1.0/24 faça apenas uma varredura de ping simples com varredura de porta desabilitada. Isso não encontrará dispositivos que suprimem as respostas de ping. Isso pode resultar em que você encontre endereços IP no cache arp, mas não os encontre com a varredura de ping ativa. Você pode tentar usar:

rpi ~$ nmap -Pn 192.168.1.0/24 

Isso fará a varredura das primeiras 1000 portas em todos os 255 endereços IP da rede. Claro que isso vai demorar muito. Você pode considerar usar apenas uma porta para escanear ou usar outras opções do nmap para encontrar seus dispositivos.

Referenciando o outras respostas aqui, eu vim com este script para encontrar o endereço IP do meu pi:

Espera que a variável de ambiente RASPI_MAC_ADDR seja definida (o endereço MAC de seu pi). Este usa arp para pesquisar os valores em cache, caso contrário, executa nmap para tentar descobri-lo.

#!/bin/bash search_for_pi() { PI_IP_ADDR_LINE="$(arp -a | grep -m1 "$RASPI_MAC_ADDR")" } # run `arp -a` to find the pi"s mac address readonly RASPI_MAC_ADDR="${RASPI_MAC_ADDR:?Could not find RASPI_MAC_ADDR environment variable}" search_for_pi [[ -z "$PI_IP_ADDR_LINE" ]] && { # if the pi IP is not in cache, run an outward nmap scan to try and find it nmap -sP 192.168.1.0/24 >&2 search_for_pi [[ -z "$PI_IP_ADDR_LINE" ]] && { printf "Couldn"t find a device on the network with the mac address: %s\n" "${RASPI_MAC_ADDR}" >&2 exit 1 } } grep -oP "\([\d\.]+\)" <<<"$PI_IP_ADDR_LINE" | tr -d "()" 

A saída nmap é redirecionada para STDERR, então eu posso fazer:

alias pi="ssh pi@$(findpi-ip)"

Script atualizado here .

Comentários

• A pergunta é: Por alguma razão, meu Smart Plug (e alguns outros dispositivos Android) só aparecem na varredura feita com arp -a. Alguém sabe a razão?
• Estão na faixa 192.168.1 …. ou na faixa 10.1.10 ….? Você pode ver meu script atualizado aqui