12
Alle Hosts im LAN anpingen um an die MAC-Adressen zu kommen
Hallo,
ich möchte auf einem Debian 7 Rechner von allen im Netzwerk aktiven Hosts die MAC-Adresse ermitteln.
Dazu funktioniert gut
Was mach ich aber in einem Netz mit einer 16 Bit Maske ?
Da bekomme ich recht schnell den Fehler Strange error from connect (105):No buffer space available
Der Scann soll regelmäßig, z.B. jede halbe Stunde laufen.
Kann ich den Buffer vergrößern, oder gibt es bessere Methoden?
Ich brauch die MAC-Adressen für ein NAC System (macmon).
vG
LS
ich möchte auf einem Debian 7 Rechner von allen im Netzwerk aktiven Hosts die MAC-Adresse ermitteln.
Dazu funktioniert gut
# LAN: 192.168.0.0/24
nmap -sP 192.168.1.1-254Was mach ich aber in einem Netz mit einer 16 Bit Maske ?
# LAN: 172.16.0.0/16
nmap -sP 172.16.1.1-255
nmap -sP 172.16.10.0-255
nmap -sP 172.16.20.0-255
nmap -sP 172.16.30.0-255
...Da bekomme ich recht schnell den Fehler Strange error from connect (105):No buffer space available
Der Scann soll regelmäßig, z.B. jede halbe Stunde laufen.
Kann ich den Buffer vergrößern, oder gibt es bessere Methoden?
Ich brauch die MAC-Adressen für ein NAC System (macmon).
vG
LS
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 303542
Url: https://administrator.de/contentid/303542
Printed on: April 23, 2024 at 20:04 o'clock
12 Comments
Latest comment
nmap 192.168.0.0/16
P.S. ein nmap update würde dir auch nicht schaden. Der Parameter -sP heißt mittlerweile -sn
P.P.S. Du must nicht pingen, um einen ARP Request abzusenden "-PR" LINK
Hallo agowa338,
ok, mit /16 wird das Script deutlich kleiner
, aber die Fehlermeldung bleibt (Strange error from connect (105):No buffer space available).
?
ok, mit /16 wird das Script deutlich kleiner
, aber die Fehlermeldung bleibt (Strange error from connect (105):No buffer space available).?
Poste mal deine Routing Tabelle.
Hier schreibt jemand, dass die Default Route dafür verantwortlich ist.
Außerdem könnte es entweder eine fehlerhafte MTU, zuwenig freier Arbeitsspeicher oder ein bug in deiner nmap version sein.
Hier schreibt jemand, dass die Default Route dafür verantwortlich ist.
Außerdem könnte es entweder eine fehlerhafte MTU, zuwenig freier Arbeitsspeicher oder ein bug in deiner nmap version sein.
DHCP Server die IPs/MAC Verknüpfung auslesen?
Intelligente Switche die du auslesen könntest?
Eigentlich sollte es ja eine PC/Hardware Liste geben wo die Infos über des Gerät/PC stehen sowie die Mac Adresse ect.
Am Server könntes du den IP<->Mac Cache Auslesen und hast schonmal ne menge Adressen.
Intelligente Switche die du auslesen könntest?
Eigentlich sollte es ja eine PC/Hardware Liste geben wo die Infos über des Gerät/PC stehen sowie die Mac Adresse ect.
Am Server könntes du den IP<->Mac Cache Auslesen und hast schonmal ne menge Adressen.
admin@SRV22:~$ netstat -r
Kernel-IP-Routentabelle
Ziel Router Genmask Flags MSS Fenster irtt Iface
default 172.16.1.254 0.0.0.0 UG 0 0 0 eth0
172.16.0.0 * 255.255.0.0 U 0 0 0 eth0nmap -PR 172.16.0.0/16 geht sehr schnell, erreicht aber scheinbar nur einen Teil, oder der ARP-Cache ist voll, weil ich dann mit ip neigh show nur wenige Zeilen sehe...
vG
LS
Hallo kaiand1,
ja, DHCP auslesen ist ok, aber macmon (NAC System) nutzt die DHCP Daten als Vergleichstabelle. Verglichen werden die Daten aus dem eigenem ARP-Cache. Andere Quellen habe ich nicht, muss das lokal ermitteln.
ja, DHCP auslesen ist ok, aber macmon (NAC System) nutzt die DHCP Daten als Vergleichstabelle. Verglichen werden die Daten aus dem eigenem ARP-Cache. Andere Quellen habe ich nicht, muss das lokal ermitteln.
noch was:
0 hosts up - das stimmt so nicht 
wenn ich das mit sudo mache (sudo nmap ...), dann kommt für jede mögliche IP:
admin@SRV22:~$ nmap -PR 172.16.0.0/16
Starting Nmap 6.40 ( http://nmap.org ) at 2016-05-03 17:53 CEST
Nmap done: 65536 IP addresses (0 hosts up) scanned in 3.80 secondswenn ich das mit sudo mache (sudo nmap ...), dann kommt für jede mögliche IP:
setup_target: failed to determine route to 172.16.x.x
Es ging ja nur erst mal darum das du eine Übersicht hast Gerät<->Mac Adresse da scheinbar keine Doku darüber vorhanden ist.
Hi
zu viel Aufwand mit mäßigen Erfolgschancen das pingen, was ist wenn du Geräte in einem nicht gerouteten VLAN hast? Es gibt ein kostenloses Tools namens netDB: MAC und IP Adressen Tracking Verwaltung.
Das liest via SSH alle Switche aus inkl. deren MAC Tables (die ja bereits alles benötigten Informationen enthalten), packt das alles in eine Datenbank und du kannst via Webbrowser nach IPs, MAC, Vendor MAC oder was auch immer suchen und das Tool sagt dir dann an welchem Port das Gerät hängt. Ist OpenSource und etwas aufwendig zu einrichten (du musst z.B. alle Switche korrekt im DNS eingetragen haben inkl. Reverse Lookup usw.) aber wir nutzen das hier täglich und es erleichtert einen immens die Doku.
Gruß
@clSchak
zu viel Aufwand mit mäßigen Erfolgschancen das pingen, was ist wenn du Geräte in einem nicht gerouteten VLAN hast? Es gibt ein kostenloses Tools namens netDB: MAC und IP Adressen Tracking Verwaltung.
Das liest via SSH alle Switche aus inkl. deren MAC Tables (die ja bereits alles benötigten Informationen enthalten), packt das alles in eine Datenbank und du kannst via Webbrowser nach IPs, MAC, Vendor MAC oder was auch immer suchen und das Tool sagt dir dann an welchem Port das Gerät hängt. Ist OpenSource und etwas aufwendig zu einrichten (du musst z.B. alle Switche korrekt im DNS eingetragen haben inkl. Reverse Lookup usw.) aber wir nutzen das hier täglich und es erleichtert einen immens die Doku.
Gruß
@clSchak
Moin Moin,
Ich hab zwar keine Lösung für Dein Ping-Problem, aber...
Ich fänd es etwas schräg, wenn ein NAC-System darauf angewiesen sein sollte, alle x Minuten das Netzwerk zu pingen. Bei 30 Minuten Intervall hätte man maximal 29 Minuten, bis das NAC-System Meldung macht, da ist schon ne Menge möglich...
Strukturell würde ich erwarten, dass das NAC-System die MAC-Adressen per SNMP o.Ä. von den Switchen bekommt. Alternativ hängt das NAC zwischen Gast-Netz und zu schützendem Netz, dann bekommt es die MAC-Adresse ja im Moment des ersten Zugriffs übermittelt.
Gruß
Bernhard
Ich hab zwar keine Lösung für Dein Ping-Problem, aber...
Ich fänd es etwas schräg, wenn ein NAC-System darauf angewiesen sein sollte, alle x Minuten das Netzwerk zu pingen. Bei 30 Minuten Intervall hätte man maximal 29 Minuten, bis das NAC-System Meldung macht, da ist schon ne Menge möglich...
Strukturell würde ich erwarten, dass das NAC-System die MAC-Adressen per SNMP o.Ä. von den Switchen bekommt. Alternativ hängt das NAC zwischen Gast-Netz und zu schützendem Netz, dann bekommt es die MAC-Adresse ja im Moment des ersten Zugriffs übermittelt.
Gruß
Bernhard
Hallo Bernhard,
Das NAC System monitort natürlich die Switchports und prüft die dort anliegenden MACs gegen eine Whiteliste....
Für die Übersicht und Kontrolle wird aber eine Statistik benötigt: welche MAC zu welcher IP. Wenn sich dann da was ändert wird ein Event ausgelöst. Geprüft wird gegen z.B. DHCP und MAC-Liste aus der Firewall.
vG
LS
Ich fänd es etwas schräg, wenn ein NAC-System darauf angewiesen sein sollte, alle x Minuten das Netzwerk zu pingen
ich auch Das NAC System monitort natürlich die Switchports und prüft die dort anliegenden MACs gegen eine Whiteliste....
Für die Übersicht und Kontrolle wird aber eine Statistik benötigt: welche MAC zu welcher IP. Wenn sich dann da was ändert wird ein Event ausgelöst. Geprüft wird gegen z.B. DHCP und MAC-Liste aus der Firewall.
Ich hab zwar keine Lösung für Dein Ping-Problem
SchadevG
LS
Hallo,
um das Thema abzuschließen, es wurde mit arpwatch gelöst.
Das NAC-System hat einen entsprechenden Monitor.
Nachdem dieser aktiviert wurde, werden zu den MAC-Adressen auch die IP-Adressen und damin die DNS-Namen ermittelt. Die Daten vom DHCP können jetzt verglichen werden...
vielen Dank für eure Anregungen.
LS
um das Thema abzuschließen, es wurde mit arpwatch gelöst.
Das NAC-System hat einen entsprechenden Monitor.
Nachdem dieser aktiviert wurde, werden zu den MAC-Adressen auch die IP-Adressen und damin die DNS-Namen ermittelt. Die Daten vom DHCP können jetzt verglichen werden...
vielen Dank für eure Anregungen.
LS
