Unterschied zwischen arp -a und nmap -sn?

arp -a druckt eine zwischengespeicherte Liste von Hosts / Geräte, die mit diesem Host gesprochen haben. Wenn Sie also Ihren Smart Plug und andere Geräte in der Ausgabe sehen, ist dies ein Beweis dafür, dass sie seit dem letzten Neustart des Pi oder Neustart von mit diesem Host gesprochen haben seine „Vernetzung .

Kurz gesagt:

Ihre nmap scannt das angegebene Subnetz vom Pi aus nach außen.

Ihre arp Ausgabe ist eine Liste von IP: Mac-Adresszuordnungen der Hosts, mit denen Ihr Pi Datenverkehr ausgetauscht hat.

Der nmap -Scan kann also viele Hosts anzeigen, während der arp -Cache Ihnen nur Hosts, mit denen Ihr Pi gesprochen hat

Der Arp-Cache eines Pi bei 192.168.1.21 wird unten angezeigt:

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 

Die Arp-Ausgabe zeigt ip: mac address Zuordnungen für (2) Hosttypen:

A) hosts (“ dh pi3Bplus-2 „) innerhalb desselben Subnetzes wie Ihr pi, das Datenverkehr direkt austauschen kann und

B) Router („dh Gateway „), die zum Weiterleiten des Datenverkehrs an Hosts außerhalb des Subnetzes Ihres Hosts erforderlich sind.

Beachten Sie, dass 192.168.1. 22 befindet sich in 192.168.1. 21 „s Cache: Das liegt daran, dass ich .22 von .21 gepingt habe. Also ein Eintrag i n Der Arp-Cache ist ein Beweis für die korrekte Konnektivität zwischen Hosts bei der Fehlerbehebung. Wenn ICMP in einer Firewall blockiert würde, würde der Ping natürlich fehlschlagen und der Host IP: mac Zuordnung wäre im Arp-Cache nicht vorhanden.

Beachten Sie auch, dass der Arp-Cache NICHT persistent! Wenn Sie den Pi oder sogar das Netzwerk neu starten, wird der Arp-Cache weggeblasen. Dies möchten Sie möglicherweise beim Testen tatsächlich tun.

Kommentare

• Es gibt einige Dinge in Ihrer Antwort, die verwirrend sein können. Zitat: “ es ‚ ist der Beweis Sie sprachen mit diesem Host seit dem letzten Neustart des Pi oder dem Neustart seines ‚ -Netzwerks. “ – Nein, Die IP-Adresse wird nach 5 Minuten aus dem Cache entfernt, wenn zuvor keine ‚ ta (neue, fortgesetzte usw.) Verbindung bestand. Wenn Sie nach 10 Minuten eine Verbindung fortsetzen, gibt es eine neue arp anfrage. Auch th Obwohl das Remote-Gerät aktiv ist, wird es 5 Minuten lang nicht im Cache gefunden.
• Zitat: “ Ein Eintrag im Arp-Cache ist also Nachweis der korrekten Konnektivität zwischen Hosts “ – Nein, wenn Sie das Remote-Gerät herunterfahren und den Arp-Cache innerhalb von 5 Minuten überprüfen, finden Sie dessen IP-Adresse. Dies alles kann zu einer verwirrenden Fehlerbehebung führen, da die Dinge möglicherweise funktionieren, aber kurze Zeit später nicht ‚ t, insbesondere wenn eine Arp-Anforderung in eine Richtung nicht ‚ funktioniert nicht richtig.
• @Ingo arp ageing sollte so funktionieren, aber meiner Erfahrung nach wird die Garbage Collection nicht ‚ nicht gelöscht veraltete Einträge gemäß dem definierten Zeitraum. Tests in meiner Antwort wurden mit 2 Pi ‚ durchgeführt, die in demselben Subnetz (mit demselben Switch verbunden) adressiert waren und einige Male & pingen ihre Pings stoppen. Wenn Sie diesen Test wiederholen und ip -statistics neighbour regelmäßig ausführen, werden ‚ Arp-Einträge mit der Bezeichnung “ angezeigt veraltet “ bleiben auch bei einem Alter von mehr als 20 Minuten! Ich verstehe also, wie das Arp-Altern funktionieren soll , aber wiederholen Sie das und ‚ Sie werden sehen, dass Einträge weit über 5 Minuten hinaus leben können. Hervorragender Punkt jedoch !!!
• Ich habe gerade verschiedene Erfahrungen gemacht;) Bei der Arbeit mit Proxy-Arp bin ich auf eine Situation gestoßen, in der Arp-Anfrage nur in eine Richtung funktioniert, vom Remote-Gerät zum RasPi. Die Verbindung funktionierte nur, wenn das Remote-Gerät 5 Minuten lang mit dem RasPi verbunden war.Umgekehrt funktionierte es manchmal (innerhalb von 5 Minuten nach dem Herstellen einer Verbindung von der Fernbedienung) und manchmal nicht ‚ t. Es war sehr schwierig, diesen unterbrochenen Fehler zu finden (im promiskuitiven Modus behoben).
• Wie auch immer – was unsere Diskussion zeigt und was ich glaube: Das Fragen des Arp-Cache nach IP-Adressen ist keine sichere Lösung, es sei denn, Sie Pingen Sie die Broadcast-Adresse, bevor Sie sich den Arp-Cache ansehen. Aber diese ‚ ist eine Möglichkeit, die ich wegen der Netzwerklast nicht vorschlagen werde.

Verweisen auf die Bei anderen Antworten habe ich mir dieses Skript ausgedacht, um die IP-Adresse meines Pi zu ermitteln:

Erwartet, dass die Umgebungsvariable RASPI_MAC_ADDR festgelegt wird (die MAC-Adresse von dein pi). Dies verwendet arp, um die zwischengespeicherten Werte zu durchsuchen, andernfalls wird nmap ausgeführt, um zu versuchen, sie zu ermitteln.

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

Die Ausgabe nmap wird an STDERR umgeleitet, sodass ich Folgendes tun kann:

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

Aktualisiertes Skript here .

Kommentare

• Die Frage ist: Aus irgendeinem Grund wird mein Smart Plug (und einige andere Android-Geräte) nur in dem mit arp -a durchgeführten Scan angezeigt. Kennt jemand den Grund?
• Befinden sich diese im Bereich 192.168.1 …. oder im Bereich 10.1.10 ….? Sie können mein aktualisiertes Skript hier