¿Diferencia entre arp -a y nmap -sn?

arp -a imprime una lista en caché de hosts / dispositivos que han estado hablando con este host. Por lo tanto, si ve su enchufe inteligente y otros dispositivos que aparecen en la salida, es una prueba de que estaban hablando con este host desde el último reinicio del Pi o reinicio de su «networking .

En pocas palabras:

Su nmap está haciendo un escaneo HACIA FUERA de la subred especificada desde el Pi.

Su arp la salida es una lista de IP: asignaciones de direcciones mac de hosts con los que su pi ha intercambiado tráfico.

Entonces, el escaneo de nmap puede mostrar muchos hosts, mientras que la caché de arp le dice solo hosts con los que su Pi ha estado hablando

La caché arp de una Pi en 192.168.1.21 se muestra a continuación:

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 

La salida de arp mostrará ip: dirección mac asignaciones para (2) tipos de hosts:

A) hosts (» es decir, pi3Bplus-2 «) dentro de la misma subred que su pi, que puede intercambiar tráfico directamente y

B) Enrutadores («es decir, puerta de enlace «) necesarios para enrutar el tráfico a los hosts fuera de la subred de su host.

Observe que 192.168.1. 22 está en 192.168.1. 21 «s caché: Eso es porque hice ping .22 desde .21. Así que una entrada i n la caché arp es una prueba de la conectividad correcta entre hosts al solucionar problemas. Por supuesto, si ICMP estuviera bloqueado en un firewall, el ping fallaría y el host «s IP: mac no estaría presente en la caché de arp.

También tenga en cuenta que la caché de arp es NO persistent! Si reinicia el Pi o incluso la red, volará el caché arp. Lo que en realidad podría querer hacer al probar.

Comentarios

• Hay algunas cosas en su respuesta que pueden ser confusas. Cita: » it ‘ s prueba estaban hablando con este host desde el último reinicio del Pi o reinicio de su ‘ red. » – No, la dirección IP se elimina de la caché después de 5 minutos si no había ‘ ta (nueva, continuada, etc.) conexión antes. Si continúa una conexión después de 10 minutos, entonces hay una nueva solicitud de arp. Incluso uando el dispositivo remoto esté activo, no lo encontrará en el caché durante 5 minutos.
• Cita: » Por lo tanto, una entrada en el caché arp es prueba de conectividad correcta entre hosts » – No, si apagas el dispositivo remoto y miras el caché arp en 5 minutos encontrarás su dirección IP. Todo esto puede confundir la solución de problemas porque las cosas pueden funcionar, pero poco tiempo después no ‘ t, en particular si la solicitud arp en una dirección no ‘ t funciona correctamente.
• @Ingo arp envejecimiento debería funcionar así, pero mi experiencia es que la recolección de basura no ‘ t purga Entradas obsoletas según el período definido. Las pruebas en mi respuesta se realizaron usando 2 Pi ‘ s direccionados en la misma subred (conectados al mismo conmutador) haciendo ping entre sí varias veces & deteniendo sus pings. Si repite esta prueba y ejecuta ip -statistics neighbour periódicamente, ‘ verá las entradas arp marcadas » » obsoletos permanecen incluso si tienen más de 20 minutos. Así que entiendo tu punto sobre cómo se supone que funciona el envejecimiento de arp, pero repite y ‘ verás que las entradas pueden durar más de 5 minutos. Sin embargo, ¡¡¡excelente punto !!!
• Acabo de tener diferentes experiencias;) Al trabajar con proxy arp, me topé con una situación en la que la solicitud de arp solo funciona en una dirección, desde el dispositivo remoto hasta la RasPi. La conexión solo funcionó cuando el dispositivo remoto se conectó a la RasPi, durante 5 minutos.A veces funcionaba al revés (dentro de los 5 minutos posteriores a la conexión desde el control remoto) ya veces no ‘ t. Fue muy difícil encontrar este error intermitente (lo resolvió con el modo promiscuo).
• De todos modos, lo que muestra nuestra discusión y lo que creo: pedir al caché arp por direcciones IP no es una solución para guardar, a menos que usted haga ping a la dirección de transmisión antes de mirar la caché arp. Pero esa ‘ es una posibilidad que no sugeriré debido a la carga de la red.

Esta no es realmente una pregunta específica de Raspberry Pi. De todos modos, daré una respuesta detallada porque encontrar la dirección IP de una Raspberry Pi es una pregunta y un problema muy frecuentes aquí.

nmap es un escáner de red y hace lo que usted espera: escanea activamente la red en busca de dispositivos.

El comando arp (es mejor usar ip neighbor) no es un escáner. Solo muestra el contenido de la caché arp local.

Para establecer conexiones ethernet, se usa el protocolo arp. Pregunta qué dispositivos Ethernet con dirección mac tienen qué dirección IP. La asignación encontrada de la dirección mac a la dirección IP se almacena en la caché arp local, de forma predeterminada durante 5 minutos. Esta asignación tiene lugar para cada conexión establecida, incluso cuando el dispositivo remoto no responde a las consultas ping. Pero esto también implica que no encontrará un dispositivo en la caché arp si no se hizo una conexión los últimos 5 minutos antes.

Su comando nmap -sn 192.168.1.0/24 Solo haga un escaneo de ping simple con escaneo de puertos deshabilitado. Esto no encontrará dispositivos que supriman las respuestas de ping. Esto puede resultar en que encuentre direcciones IP en el caché arp pero no las encuentre con escaneo de ping activo. Puede intentar usar:

rpi ~$ nmap -Pn 192.168.1.0/24 

Esto escaneará los primeros 1000 puertos en las 255 direcciones IP de la red. Por supuesto, esto llevará mucho tiempo. Puede considerar usar solo un puerto para escanear o usar otras opciones para que nmap encuentre sus dispositivos.

Haciendo referencia al otras respuestas aquí, se me ocurrió este script para encontrar la dirección IP de mi pi:

Espera que se establezca la variable de entorno RASPI_MAC_ADDR (la dirección MAC de tu pi). Esto usa arp para buscar los valores en caché; de lo contrario, ejecuta nmap para intentar descubrirlo.

#!/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 "()" 

La salida nmap se redirige a STDERR, así que puedo hacer:

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

Secuencia de comandos actualizada here .

Comentarios

• La pregunta es: por alguna razón, mi Smart Plug (y algunos otros dispositivos Android) solo aparecen en el escaneo realizado con arp -a. ¿Alguien sabe la razón?
• ¿Están en el rango 192.168.1 …. o en el rango 10.1.10 ….? Puede ver mi secuencia de comandos actualizada aquí