Különbség az arp -a és az nmap -sn között?

arp -a kinyomtat egy gyorsítótárazott listát gazdagépek / eszközök, amelyek már beszéltek ezzel a gazdagéppel. Ezért ha azt látja, hogy az okos csatlakozója és más eszközei megjelennek a kimenetben, ez bizonyítja, hogy ezzel a gazdagéppel beszéltek a Pi utolsó újraindítása vagy a annak “networking .

Dióhéjban:

A nmap a megadott alhálózat KÜLSŐ beolvasását végzi a Pi-ből.

A arp kimenet az IP: mac-cím leképezések listája Olyan gazdagépek , amelyekkel a pi forgalmat cserélt.

Tehát a nmap beolvasás sok gazdagépet mutathat, míg az arp gyorsítótár csak hosztok, amelyekkel a Pi beszélt

Az alábbiakban látható a 192.168.1.21-es Pi arp gyorsítótára:

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 

Az arp kimenet ip: mac cím leképezések (2) típusú hosztokhoz:

A) hosztok (” azaz pi3Bplus-2 “”) ugyanazon az alhálózaton belül, mint a pi, amely közvetlenül képes cserélni a forgalmat és

B) Útválasztók (“azaz átjáró “) szükségesek a forgalom átirányításához a gazdagép alhálózatán kívüli állomásokhoz.

Megjegyzés: 192.168.1. 22 a 192.168.1-ben található. 21 “gyorsítótár: Ez azért van, mert .22-et pingeltem .21-ből. Tehát egy i n az arp gyorsítótár bizonyítja a gazdagépek közötti megfelelő kapcsolatot a hibaelhárítás során. Természetesen, ha az ICMP-t blokkolják egy tűzfalban, a ping meghiúsul, és a gazdagép “s IP: mac leképezés nem lenne jelen az arp gyorsítótárban.

Ne feledje, hogy az arp gyorsítótár NEM persistent! ha újraindítja a Pi-t, vagy akár a hálózatot, az elfújja az arp gyorsítótárat. Amit a tesztelés során valóban meg kell tennie.

Megjegyzések

• A válaszában vannak olyan dolgok, amelyek zavaróak lehetnek. Idézet: ” it ‘ bizonyíték a Pi legutóbbi újraindítása óta vagy a ‘ hálózat újraindítása óta beszéltek ezzel a gazdagéppel. ” – Nem, az IP-cím 5 perc elteltével eltávolításra kerül a gyorsítótárból, ha korábban nem volt ‘ ta (új, folytatás stb.) kapcsolat. Ha 10 perc után folytatja a kapcsolatot, akkor egy új arp kérés. Még th Ha a távoli eszköz aktív, akkor 5 percig nem fogja megtalálni a gyorsítótárban.
• Idézet: ” Tehát egy bejegyzés az arp gyorsítótárban: a gazdagépek közötti megfelelő kapcsolat igazolása ” – Nem, ha kikapcsolja a távoli eszközt, és 5 percen belül megnézi az arp gyorsítótárat, megtalálja annak IP-címét. Mindez zavaró lehet a hibaelhárításban, mert a dolgok működhetnek, de rövid idő múlva nem ‘ t, különösen, ha az egyik irányú arp kérés nem ‘ nem működnek megfelelően.
• Az @Ingo arp öregedésének kellene így működnie, de az a tapasztalatom, hogy a szemétszállítás nem ‘ nem tisztít elavult bejegyzések a meghatározott időszaknak megfelelően. A válaszomban a teszteket 2 Pi ‘ s segítségével végeztük, ugyanazon az alhálózaton (ugyanazon kapcsolóhoz csatlakoztatva), néhányszor pingálva egymást. & megállítva a pingeiket. Ha megismétli ezt a tesztet, és rendszeresen futtatja a ip -statistics neighbour fájlt, akkor ‘ ll látni fogja az ” jelöléseket az elavult ” akkor is megmarad, ha 20 percnél idősebb! Tehát megértem, hogy az arp öregedés miként működik állítólag , de ismételje meg, és ‘ ll látni fogják, hogy a bejegyzések 5 percnél tovább élhetnek. Kiváló pont !!!
• Éppen most tapasztaltam különböző tapasztalatokat;) A proxy arp-val való együttműködés során olyan helyzetbe botlottam, amikor az arp kérés csak egy irányban működik, a távoli eszköztől a RasPi-ig. A kapcsolat csak akkor működött, amikor a távoli eszköz a RasPi-hez csatlakozik – 5 percig.Ez fordítva néha működött (a távoli csatlakozás után 5 percen belül), és néha nem ‘ t. Nagyon nehéz volt megtalálni ezt a bekerült hibát (elhárító móddal megoldotta).
• Egyébként – amit a beszélgetésünk mutat és amiben hiszek: az arp gyorsítótár IP-címekre való kérése nem mentési megoldás, hacsak nem pingelje meg az adás címét, mielőtt megnézné az arp gyorsítótárat. De ezt a ‘ lehetőséget a hálózati terhelés miatt nem fogom javasolni.

Hivatkozás a más válaszok itt találtam ki ezt a szkriptet, hogy megtaláljam a pi IP-címét:

elvárja a RASPI_MAC_ADDR környezeti változó beállítását (a a te pi). Ez a arp segítségével tárolja a gyorsítótárban tárolt értékeket, máskülönben pedig az nmap fájlt futtatja, hogy megpróbálja megtalálni.

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

A nmap kimenet átirányításra kerül az STDERR fájlra, így megtehetem:

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

Frissített szkript here .

Megjegyzések

• A kérdés a következő: Valamilyen oknál fogva az intelligens csatlakozóm (és néhány más androidos eszköz) csak az arp -a-val végzett vizsgálat során jelenik meg. Tudja valaki az okát?
• A 192.168.1 …. vagy a 10.1.10 …. tartományba tartoznak? A frissített szkriptemet itt láthatja