Ik scan mijn netwerk om IP-adressen te achterhalen door deze twee opdrachten te gebruiken.
arp -a nmap -sn 192.168.1.0/24
Om de een of andere reden worden mijn Smart Plug (en sommige andere Android-apparaten) alleen weergegeven in de scan die is uitgevoerd met arp -a
. Kent iemand de reden?
Answer
arp -a
drukt een in de cache opgeslagen lijst af met hosts / apparaten die met deze host hebben gesproken. Dus als je je smart plug en andere apparaten in de output ziet verschijnen, is dit het bewijs dat ze met deze host praatten sinds de laatste herstart van de Pi of herstart van zijn “netwerken .
In een notendop:
Uw nmap doet OUTWARD scanning van het gespecificeerde subnet vanaf de Pi.
Jouw arp uitvoer is een lijst met IP: mac-adrestoewijzingen van hosts waarmee uw pi verkeer heeft uitgewisseld.
Dus de nmap -scan kan veel hosts tonen, terwijl de arp -cache je vertelt alleen hosts waarmee je Pi heeft gesproken
De arp-cache van een Pi op 192.168.1.21 wordt hieronder weergegeven:
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
De arp-uitvoer toont ip: mac-adres toewijzingen voor (2) typen hosts:
A) hosts (” dwz pi3Bplus-2 “) binnen hetzelfde subnet als uw pi die direct verkeer kan uitwisselen en
B) Routers (“ie gateway “) vereist om verkeer naar hosts buiten het subnet van je host te leiden.
Merk op dat 192.168.1. 22 bevindt zich in 192.168.1. 21 “s cache: dat is omdat ik .22 heb gepingd van .21. Dus een invoer i n de arp-cache is het bewijs van de juiste connectiviteit tussen hosts bij het oplossen van problemen. Als ICMP werd geblokkeerd in een firewall, zou de ping natuurlijk mislukken en de host “s IP: mac mapping zou niet aanwezig zijn in de arp-cache.
Merk ook op dat de arp-cache NIET persistent! als je de Pi herstart of zelfs het netwerken, zal het de arp-cache wegblazen. Wat je eigenlijk zou willen doen bij het testen.
Opmerkingen
- Sommige dingen in je antwoord kunnen verwarrend zijn. Citaat: ” het ‘ s bewijs ze waren in gesprek met deze host sinds de laatste herstart van de Pi of herstart van zijn ‘ netwerk. ” – Nee, het ip-adres wordt na 5 minuten uit de cache verwijderd als er eerder geen ‘ ta (nieuwe, vervolg, etc.) verbinding was. Als je een verbinding na 10 minuten voortzet, is er een nieuw arp-verzoek. Zelfs th hoewel het externe apparaat actief is, zul je het 5 minuten niet in de cache vinden.
- Citaat: ” Dus een item in de arp-cache is bewijs van correcte connectiviteit tussen hosts ” – Nee, als je het externe apparaat uitschakelt en binnen 5 minuten naar de arp-cache kijkt, vind je het ip-adres. Dit kan allemaal verwarrend zijn voor het oplossen van problemen, omdat dingen kunnen werken, maar korte tijd later niet ‘ t, in het bijzonder als arp-verzoek in één richting niet ‘ werkt niet correct.
- @Ingo arp aging zou zo moeten werken, maar mijn ervaring is dat garbage collection niet ‘ t purge verouderde items volgens de gedefinieerde periode. Tests in mijn antwoord zijn gedaan met 2 Pi ‘ s geadresseerd op hetzelfde subnet (verbonden met dezelfde switch), elkaar een paar keer gepingend & het stoppen van hun pings. Als u deze test herhaalt en
ip -statistics neighbour
regelmatig uitvoert, ‘ ziet u arp-vermeldingen gemarkeerd met ” oud ” blijven, zelfs als ze ouder zijn dan 20 minuten! Dus ik begrijp je punt over hoe arp-veroudering verondersteld werkt, maar herhaal de en je ‘ zult zien dat inzendingen langer dan 5 minuten kunnen duren. Uitstekend punt echter !!! - Ik heb zojuist andere ervaringen opgedaan;) Bij het werken met proxy arp kwam ik een situatie tegen waarin arp-verzoek slechts in één richting werkt, van het externe apparaat naar de RasPi. De verbinding werkte alleen als het externe apparaat was verbonden met de RasPi – gedurende 5 minuten.Andersom werkte het soms (binnen 5 minuten na verbinding vanaf een afstandsbediening) en soms niet ‘ t. Het was erg moeilijk om deze onderbroken fout te vinden (opgelost met promiscuous mode).
- Hoe dan ook – wat onze discussie laat zien en wat ik geloof: de arp-cache vragen naar ip-adressen is geen veilige oplossing, tenzij je ping het uitzendadres voordat u naar de arp-cache kijkt. Maar die ‘ is een mogelijkheid die ik niet zal voorstellen vanwege de netwerkbelasting.
Antwoord
Dit is niet echt een vraag die specifiek is voor Raspberry Pi. Hoe dan ook, ik zal een gedetailleerd antwoord geven, omdat het vinden van het ip-adres van een Raspberry Pi hier een vaak gestelde vraag en probleem is.
nmap is een netwerkscanner en hij doet wat je verwacht: hij scant actief het netwerk op apparaten.
Het commando arp (je kunt beter ip neighbor
gebruiken) is geen scanner. Het toont alleen de inhoud van de lokale arp-cache.
Om ethernetverbindingen tot stand te brengen, wordt het arp-protocol gebruikt. Het vraagt welke ethernet-apparaten met een mac-adres welk ip-adres hebben. De gevonden toewijzing van het mac-adres naar het ip-adres wordt standaard 5 minuten opgeslagen in de lokale arp-cache. Deze mapping vindt plaats voor elke tot stand gebrachte verbinding, zelfs als het externe apparaat niet reageert op ping
-vragen. Maar dit houdt ook in dat u geen apparaat in de arp-cache vindt als er de laatste 5 minuten daarvoor geen verbinding is gemaakt.
Uw commando nmap -sn 192.168.1.0/24
voer alleen een eenvoudige ping-scan uit met uitgeschakelde poortscan. Dit zal geen apparaten vinden die ping-antwoorden onderdrukken. Dit kan ertoe leiden dat u ip-adressen in de arp-cache vindt, maar deze niet vindt met actieve ping-scan. U kunt proberen het volgende te gebruiken:
rpi ~$ nmap -Pn 192.168.1.0/24
Hiermee worden de eerste 1000 poorten op alle 255 ip-adressen op het netwerk gescand. Dit zal natuurlijk erg lang duren. U kunt overwegen om slechts één poort te gebruiken om te scannen of andere opties voor nmap te gebruiken om uw apparaten te vinden.
Antwoord
Verwijzend naar de andere antwoorden hier, ik bedacht dit script om het IP-adres van mijn pi te vinden:
Verwacht dat de RASPI_MAC_ADDR
omgevingsvariabele wordt ingesteld (het MAC-adres van uw pi). Dit gebruikt arp
om de waarden in het cachegeheugen te doorzoeken, anders wordt nmap
uitgevoerd om het te ontdekken.
#!/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 "()"
De nmap
uitvoer wordt omgeleid naar STDERR, dus ik kan het volgende doen:
alias pi="ssh pi@$(findpi-ip)"
Bijgewerkt script here
.
Reacties
- De vraag is: om de een of andere reden verschijnen mijn Smart Plug (en sommige andere Android-apparaten) alleen in de scan die is uitgevoerd met arp -a. Kent iemand de reden?
- Zijn die op de 192.168.1 …. reeks of de 10.1.10 …. reeks? Je kunt mijn bijgewerkte script hier
bekijken