Différence entre arp -a et nmap -sn?

arp -a imprime une liste de les hôtes / périphériques qui ont parlé à cet hôte. Par conséquent, si vous voyez votre prise intelligente et dautres périphériques apparaître dans la sortie, cest la preuve quils parlaient à cet hôte depuis le dernier redémarrage du Pi ou redémarrage de sa « mise en réseau .

En un mot:

Votre nmap effectue un scan OUTWARD du sous-réseau spécifié à partir du Pi qui le fait.

Votre arp la sortie est une liste de IP: mappages dadresses mac dhôtes avec lesquels votre pi a échangé du trafic.

Ainsi, le scan nmap peut afficher de nombreux hôtes, alors que le cache arp vous indique seulement héberge votre Pi a parlé

Le cache arp dun Pi à 192.168.1.21 est montré ci-dessous:

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 sortie arp affichera adresse ip: mac mappages pour (2) types dhôtes:

A) hosts ( » ie pi3Bplus-2 « ) dans le même sous-réseau que votre pi qui peut directement échanger du trafic et

B) Routeurs (« ie passerelle « ) requis pour acheminer le trafic vers des hôtes en dehors du sous-réseau de votre hôte.

Remarquez que 192.168.1. 22 est dans 192.168.1. 21 « s cache: Cest parce que jai envoyé un ping de .22 à partir de .21. Donc une entrée i n le cache arp est la preuve de la bonne connectivité entre les hôtes lors du dépannage. Bien sûr, si ICMP était bloqué dans un pare-feu, le ping échouerait et lhôte « s IP: mac ne serait pas présent dans le cache arp.

Notez également que le cache arp est PAS persistant! si vous redémarrez le Pi ou même le réseau, le cache arp sera détruit. Ce que vous voudrez peut-être faire lors du test.

Commentaires

• Certaines choses dans votre réponse peuvent prêter à confusion. Citation:  » it ‘ preuve ils parlaient à cet hôte depuis le dernier redémarrage du Pi ou le redémarrage de son réseau ‘.  » – Non, ladresse IP est supprimée du cache au bout de 5 minutes sil ny a pas eu de connexion ‘ ta (nouvelle, suite, etc.) auparavant. Si vous poursuivez une connexion après 10 min, il y a un nouvelle requête arp. Même e ough le périphérique distant est actif, vous ne le trouverez pas dans le cache pendant 5 min.
• Citation:  » Donc, une entrée dans le cache arp est preuve de la bonne connectivité entre les hôtes  » – Non, si vous éteignez le périphérique distant et que vous regardez le cache arp dans les 5 minutes, vous trouverez son adresse IP. Tout cela peut dérouter le dépannage car les choses peuvent fonctionner mais peu de temps après, cela ne ‘ t, en particulier si la requête arp dans une direction ne fonctionne pas ‘ t fonctionne correctement.
• @Ingo arp vieillissement devrait fonctionner comme ça, mais mon expérience est que le ramassage des ordures ne ‘ t purge entrées périmées selon la période définie. Les tests de ma réponse ont été effectués à laide de 2 Pi ‘ s adressés sur le même sous-réseau (connectés au même commutateur) qui se pinguent plusieurs fois & arrêter leurs pings. Si vous répétez ce test et exécutez ip -statistics neighbour périodiquement, ‘ verrez les entrées arp marquées  » les  » périmés restent même sils datent de plus de 20 min! Je comprends donc comment le vieillissement de larp est censé fonctionner, mais répétez le et vous ‘ verrez que les entrées peuvent vivre bien au-delà de 5 min. Excellent point cependant !!!
• Je viens de faire différentes expériences;) En travaillant avec proxy arp, je suis tombé sur une situation où la requête arp ne fonctionne que dans une direction, du périphérique distant au RasPi. La connexion ne fonctionnait que lorsque lappareil distant était connecté au RasPi – pendant 5 min.Linverse fonctionnait parfois (dans les 5 minutes après la connexion à distance) et parfois cela ne fonctionnait pas ‘ t. Il était très difficile de trouver cette erreur intermittente (résolue avec le mode promiscuous).
• Quoi quil en soit – ce que notre discussion montre et ce que je crois: demander au cache arp des adresses IP nest pas une solution de sauvegarde, sauf si vous envoyez un ping à ladresse de diffusion avant de consulter le cache arp. Mais cette ‘ est une possibilité que je ne suggérerai pas en raison de la charge du réseau.

Ce nest pas vraiment une question spécifique à Raspberry Pi. Quoi quil en soit, je vais donner une réponse détaillée car trouver ladresse IP dun Raspberry Pi est une question et un problème très souvent posés ici.

nmap est un scanner de réseau et il fait ce que vous attendez: il scanne activement le réseau pour les périphériques.

La commande arp (vous devriez mieux utiliser ip neighbor) nest pas un scanner. Il ne montre que le contenu du cache arp local.

Pour établir des connexions Ethernet, le protocole arp est utilisé. Il demande quels périphériques Ethernet avec une adresse Mac ont quelle adresse IP. Le mappage trouvé de ladresse mac à ladresse IP est stocké dans le cache arp local, par défaut pendant 5 minutes. Ce mappage a lieu pour chaque connexion établie, même lorsque le périphérique distant ne répond pas aux requêtes ping. Mais cela implique aussi que vous ne trouvez pas de périphérique dans le cache arp sil ny a pas eu de connexion les 5 dernières minutes avant.

Votre commande nmap -sn 192.168.1.0/24 effectuez uniquement une analyse ping simple avec une analyse de port désactivée. Cela ne trouvera pas les périphériques qui suppriment les réponses ping. Cela peut entraîner que vous trouviez des adresses IP dans le cache arp mais que vous ne les trouviez pas avec une analyse ping active. Vous pouvez essayer dutiliser:

rpi ~$ nmap -Pn 192.168.1.0/24 

Cela analysera les 1000 premiers ports sur les 255 adresses IP du réseau. Bien sûr, cela prendra très longtemps. Vous pouvez envisager dutiliser un seul port pour scanner ou utiliser dautres options pour nmap pour trouver vos appareils.

Référence à la autres réponses ici, jai créé ce script pour trouver ladresse IP de mon pi:

Attend que la variable denvironnement RASPI_MAC_ADDR soit définie (ladresse MAC de votre pi). Cela utilise arp pour rechercher les valeurs mises en cache, sinon exécute nmap pour essayer de le découvrir.

#!/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 sortie nmap est redirigée vers STDERR, donc je peux faire:

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

Script mis à jour here .

Commentaires

• La question est la suivante: pour une raison quelconque, ma Smart Plug (et certains autres appareils Android) napparaissent que dans lanalyse effectuée avec arp -a. Quelquun en connaît-il la raison?
• Sont-ils sur la plage 192.168.1 …. ou sur la plage 10.1.10 ….? Vous pouvez voir mon script mis à jour ici