Jeg scanner mit netværk for at finde ud af IP-adresser ved hjælp af disse to kommandoer.
arp -a nmap -sn 192.168.1.0/24 Af en eller anden grund vises mit Smart Plug (og nogle andre Android-enheder) kun i scanningen udført med arp -a. Kender nogen årsagen?
Svar
arp -a udskriver en cache-liste over værter / enheder, der har talt med denne vært. Derfor, hvis du ser dit smarte stik og andre enheder vises i output, er det bevis for, at de talte med denne vært siden den sidste genstart af Pi eller genstart af dens “netværk .
I en nøddeskal:
Din nmap laver UDVENDIG scanning af det angivne undernet fra Pien ved at gøre det.
Din arp output er en liste over IP: mac-adressetilknytninger af værter, som din pi har udvekslet trafik med.
Så nmap scanningen kan vise mange værter, mens arp cachen fortæller dig kun er vært for din Pi har talt med
Arp-cachen for en Pi ved 192.168.1.21 vises nedenfor:
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 Arp-output viser ip: mac-adresse -tilknytninger til (2) værttyper:
A) hosts (” dvs. pi3Bplus-2 “) inden for det samme undernet som dit pi, som direkte kan udveksle trafik og
B) Routere (“dvs. gateway “) kræves for at dirigere trafik til værter uden for din værts undernet.
Bemærk, at 192.168.1. 22 er i 192.168.1. 21 “s cache: Det skyldes, at jeg pingede .22 fra .21. Så en post i n arp-cachen er bevis for korrekt forbindelse mellem værter ved fejlfinding. Selvfølgelig, hvis ICMP blev blokeret i en firewall, ville ping mislykkes, og værten “s IP: mac mapping ville ikke være til stede i arp-cachen.
Bemærk også, at arp-cachen er IKKE vedvarende! hvis du genstarter Pi eller endda netværket, blæser det arp-cachen væk. Hvilket du måske vil gøre, når du tester.
Kommentarer
- Der er nogle ting i dit svar, der kan være forvirrende. Citat: ” det ‘ s bevis de talte med denne vært siden sidste genstart af Pi eller genstart af dets ‘ netværk. ” – Nej, ip-adressen fjernes fra cachen efter 5 minutter, hvis der ikke var ‘ ta (ny, fortsat osv.) forbindelse før. Hvis du fortsætter en forbindelse efter 10 minutter, er der en ny arp-anmodning. Selv th hvis fjernenheden er aktiv, finder du den ikke i cachen i 5 minutter.
- Citat: ” Så en post i arp-cachen er bevis for korrekt forbindelse mellem værter ” – Nej, hvis du lukker fjernenheden og ser på arp-cachen inden for 5 minutter, finder du dens ip-adresse. Alt dette kan forvirre fejlfinding, fordi ting kan fungere, men kort tid senere ‘ t, især hvis arp-anmodning i en retning ikke ‘ t fungerer korrekt.
- @Ingo arp aldring skal arbejde sådan, men min erfaring er, at affaldssamling ikke renser ‘ uaktuelle poster i henhold til den definerede periode. Test i mit svar blev udført ved hjælp af 2 Pi ‘ s adresseret på samme undernet (forbundet til samme switch) pingede hinanden et par gange & standse deres pinger. Hvis du gentager denne test og kører
ip -statistics neighbourmed jævne mellemrum, vil du ‘ se arp-poster markeret ” forældet ” forbliver, selvom det er ældre end 20 minutter! Så jeg får din mening om, hvordan arp aldring formodes at fungere, men gentag, og du ‘ ser poster kan leve langt ud over 5 min. Fremragende punkt dog !!! - Jeg har lige gjort forskellige oplevelser;) Når jeg arbejdede med proxy-arp, snublede jeg om en situation, hvor arp-anmodning kun fungerer i en retning, fra den eksterne enhed til RasPi. Forbindelsen fungerede kun, når den eksterne enhed sluttede til RasPi – i 5 min.Omvendt fungerede det undertiden (inden for 5 minutter efter tilslutning fra fjernbetjening), og nogle gange fungerer det ikke ‘ t. Det var meget vanskeligt at finde denne intermitterede fejl (løst det med promiskuøs tilstand).
- Alligevel – hvad vores diskussion viser, og hvad jeg tror: at bede arp-cachen om ip-adresser er ikke en gem-løsning, medmindre du ping udsendelsesadressen, inden du kigger på arp-cachen. Men den ‘ en mulighed vil jeg ikke foreslå på grund af netværksbelastning.
Svar
Dette er ikke rigtig et specifikt spørgsmål til Raspberry Pi. Under alle omstændigheder vil jeg give et detaljeret svar, fordi det er et meget ofte stillet spørgsmål og problem at finde ip-adressen på en Raspberry Pi.
nmap er en netværksscanner, og den gør, hvad du forventer: den scanner aktivt netværket efter enheder.
Kommandoen arp (du bør hellere bruge ip neighbor) er ikke en scanner. Det viser kun indholdet af den lokale arp-cache.
For at etablere Ethernet-forbindelser bruges arp-protokollen. Det spørger, hvilke Ethernet-enheder med mac-adresse, der har hvilken ip-adresse. Den fundne kortlægning af mac-adresse til ip-adresse gemmes i den lokale arp-cache som standard i 5 minutter. Denne kortlægning finder sted for hver etableret forbindelse, selv når den eksterne enhed ikke reagerer på ping forespørgsler. Men dette indebærer også, at du ikke finder en enhed i arp-cachen, hvis der ikke blev oprettet en forbindelse de sidste 5 minutter før.
Din kommando nmap -sn 192.168.1.0/24 udfør kun en simpel ping-scanning med deaktiveret port-scanning. Dette finder ikke enheder, der undertrykker ping-svar. Dette kan resultere i, at du finder ip-adresser i arp-cachen, men ikke finder det med aktiv ping-scanning. Du kan prøve at bruge:
rpi ~$ nmap -Pn 192.168.1.0/24 Dette scanner de første 1000 porte på alle 255 ip-adresser på netværket. Dette vil naturligvis tage meget lang tid. Du kan overveje kun at bruge en port til at scanne eller bruge andre indstillinger til nmap til at finde dine enheder.
Svar
Henvisning til andre svar her, jeg kom op med dette script for at finde IP-adressen på min pi:
Forventer, at RASPI_MAC_ADDR miljøvariablen skal indstilles (MAC-adressen på dit pi). Dette bruger arp til at søge i de cachelagrede værdier, ellers kører nmap for at prøve at opdage det.
#!/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 "()" nmap output omdirigeres til STDERR, så jeg kan gøre:
alias pi="ssh pi@$(findpi-ip)"
Opdateret script here .
Kommentarer
- Spørgsmålet er: Af en eller anden grund vises mit Smart Plug (og nogle andre Android-enheder) kun i scanningen udført med arp -a. Kender nogen årsagen?
- Er de i området 192.168.1 …. eller 10.1.10 ….? Du kan se mit opdaterede script her