Skillnad mellan arp -a och nmap -sn?

arp -a skriver ut en cachad lista med värdar / enheter som har pratat med den här värden. Därför om du ser din smarta kontakt och andra enheter visas i utgången är det ett bevis på att de pratade med den här värden sedan den senaste omstarten av Pi eller omstart av dess ”nätverk .

I ett nötskal:

Din nmap gör OUTWARD-skanning av det angivna undernätet från Pi och gör det.

Ditt arp utdata är en lista över IP: mappning av mac-adress av värdar som din pi har utbytt trafik med.

Så nmap skanningen kan visa många värdar, medan arp cachen säger till dig endast är värd för din Pi har pratat med

Arp-cache för en Pi vid 192.168.1.21 visas nedan:

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-utgången visar ip: mac-adress mappningar för (2) värdtyper:

A) värdar (” dvs pi3Bplus-2 ”) inom samma undernät som ditt pi som direkt kan utbyta trafik och

B) Routrar (”dvs. gateway ”) krävs för att dirigera trafik till värdar utanför din värdns undernät.

Observera att 192.168.1. 22 är 192.168.1. 21 ”s cache: Det beror på att jag pingade .22 från .21. Så en post i n arp-cache är ett bevis på korrekt anslutning mellan värdar vid felsökning. Naturligtvis om ICMP blockerades i en brandvägg skulle ping misslyckas och värden ”s IP: mac mapping skulle inte finnas i arp-cachen.

Observera också att arp-cachen är INTE ihållande! om du startar om Pi eller till och med nätverket kommer det att spränga bort arp-cache. Vilket du faktiskt kanske vill göra när du testar.

Kommentarer

• Det finns några saker i ditt svar som kan vara förvirrande. Citat: ” det ’ s bevis de pratade med den här värden sedan den sista omstarten av Pi eller omstart av dess ’ nätverk. ” – Nej, ip-adressen tas bort från cachen efter 5 minuter om det inte fanns ’ ta (ny, fortsättning osv.) anslutning tidigare. Om du fortsätter en anslutning efter 10 minuter finns det en ny arpförfrågan. Även th om fjärrenheten är aktiv hittar du den inte i cachen under 5 minuter.
• Citat: ” Så en post i arp-cachen är bevis på korrekt anslutning mellan värdar ” – Nej, om du stänger av fjärrenheten och tittar på arp-cache inom 5 minuter hittar du dess IP-adress. Allt detta kan förvirra felsökning eftersom saker kan fungera men en kort stund senare ’ t, särskilt om arp-begäran i en riktning inte ’ fungerar inte korrekt.
• @Ingo arp åldrande ska fungera så, men min erfarenhet är att skräpsamling inte ’ t rensar inaktuella poster enligt den definierade perioden. Tester i mitt svar gjordes med 2 Pi ’ s adresserade på samma undernät (ansluten till samma switch) pingade varandra några gånger & stoppa deras pingar. Om du upprepar detta test och kör ip -statistics neighbour regelbundet ’ ser du arp-poster markerade ” inaktuell ” kvar även om det är äldre än 20 minuter! Så jag förstår hur arpåldring ska fungera, men upprepa och du ’ ser att poster kan leva långt längre än 5 min. Utmärkt poäng dock !!!
• Jag har just gjort olika upplevelser;) När jag arbetade med proxy-arp snubblade jag om en situation där arp-begäran bara fungerar i en riktning, från fjärrenheten till RasPi. Anslutningen fungerade bara när fjärrenheten var ansluten till RasPi – i 5 minuter.Omvänt fungerade det ibland (inom 5 minuter efter anslutning från fjärrkontrollen) och ibland fungerar det inte ’ t. Det var väldigt svårt att hitta detta intermitterade fel (löst det med promiskuöst läge).
• Hur som helst – vad vår diskussion visar och vad jag tror: att fråga arp-cachen för ip-adresser är inte en sparlösning, om du pinga sändningsadressen innan du tittar på arp-cachen. Men den ’ en möjlighet kommer jag inte att föreslå på grund av nätverksbelastning.

Hänvisning till andra svar här, jag kom med det här skriptet för att hitta IP-adressen till min pi:

Förväntar mig att RASPI_MAC_ADDR miljövariabel ska ställas in (MAC-adressen för din pi). Detta använder arp för att söka i cachade värden, annars kör nmap för att försöka upptäcka 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 -utgången omdirigeras till STDERR, så jag kan göra:

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

Uppdaterat skript here .

Kommentarer

• Frågan är: Av någon anledning dyker min Smart Plug (och några andra Android-enheter) bara upp i genomsökningen med arp -a. Vet någon orsaken?
• Är de i intervallet 192.168.1 …. eller 10.1.10 ….? Du kan se mitt uppdaterade skript här