Announcement: there is an English version of this forum on Ich stehe vor der Aufgabe, bestimmte Geräte, deren IPs zusammen mit anderen im LAN (Class C, Subnet 255.255.255.0) "verteilt" sind, schnell zu finden (die IP, die per DHCP verteilt wird). Eine Reservierung anhand der MAC-Adresse im DHCP-Server oder eine Abfrage von dessen Lease-List sind nicht möglich, weil kein Zugang besteht. Bisher habe ich einfach alle 254 Adressen (1-254) mit einem HTTP-Request durchgeleiert, denn die gesuchten Geräte antworten auf "http://a.b.c.d/?cmd=ident"; mit ihrem Gerätenamen, z.B. "<html>printmanager</html>". Fremde Gerät reagieren darauf nicht oder mit "Unsinn", so dass die Erkennung auf diese Weise kein Problem ist. Zumal sind die erwarteten Antworten bzw. Gerätenamen bekannt. Das funktioniert sehr zuverlässig, aber eben langsam. Die MAC-Adressen der Subsysteme sind auch bekannt. Ich könnte natürlich auch schnell mal Alles durchpingen und dann den ARP-Cache aus einer Shell laden und darin herumparsen. Hier stört, dass die ARP-Resultate auf jeder Palttform (Win, Mac, Linux) anders formatiert sind ... Hat jemand eine Idee, die er zum Besten geben möchte? Auf die Insrallation zusätzlicher Tool soll verzichtet werden (z.B. "macping"), es muss mit Bordmitteln funktionieren. Ansonsten bleibe ich halt einfach bei der trivialen Scan-Methode ...
:
Bearbeitet durch User
Frank E. schrieb: > Ich stehe vor der Aufgabe, bestimmte Geräte, deren IPs zusammen mit > anderen im LAN (Class C, Subnet 255.255.255.0) "verteilt" sind, schnell > zu finden (die IP, die per DHCP verteilt wird). > > Das funktioniert sehr zuverlässig, aber eben langsam. was ist "schnell" für Dich in einer üblichen SI-Einheit? Programmausführung ohne Installationpipapo ist ok?
Ich benutze dazu das Programm NetSetMan in der kostenlosen Version. Dazu einfach bei den Werkzeugen den Netzwerkscanner auswählen und den zu durchsuchenden Netzwerkbereich eintragen und starten. Mit dem Tool kann man auch viele verschiedene Netzwerkprofile anlegen und mit eine Klick aktivieren. Wenn man z.Bsp. in vielen verschiedenen Netzwerken arbeitet.
Multicast-DNS wurde genau für sowas gemacht, müssen deine Geräte im Netzwerk aber natürlich unterstützen.
Rüdiger B. schrieb: > NMap mit ZenMAp Gui. Sucht alle offene Ports im Subnet. Will er ja garnicht. Er will nur die offenen Ports 80 (das kann man nmap noch mitteilen), und davon nur die, die auf seinen GET-Request korrekt antworten. Sind 253 GET-Requests. Wenn er die parallel startet und nicht sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig. Schneller wird's mit einem externen Port-Scanning tool auch nicht.
Εrnst B. schrieb: > Sind 253 GET-Requests. Wenn er die parallel startet und nicht > sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig. Danke, gute Idee - mein Programmierwerkzeug "Xojo" kann tatsächlich Threads, das hatte ich garnicht mehr auf dem Schirm ... naja klar: Der Wald und die Bäume oder ich werd alt :-( Wenn es statt der bisherigen 30s nur 3 sind bin ich schon zufrieden. Ich werde berichten. Ich muss mal gucken, wieviel RAM so ein Thread braucht, muss auf einem Raspi mit 2GB laufen ... aber auch das könnte ich dynamisch anpassen, weil ich ja jederzeit abfragen kann, wieviel RAM noch frei ist ...
Mi. W. schrieb: > Frank E. schrieb: >> Ich stehe vor der Aufgabe, bestimmte Geräte, deren IPs zusammen mit >> anderen im LAN (Class C, Subnet 255.255.255.0) "verteilt" sind, schnell >> zu finden (die IP, die per DHCP verteilt wird). >> >> Das funktioniert sehr zuverlässig, aber eben langsam. > > was ist "schnell" für Dich in einer üblichen SI-Einheit? > > Programmausführung ohne Installationpipapo ist ok? Als single thread bzw. in einer ganz gewöhnlichen For-Schleife im Hauptprogramm bis zu 30 ... 35 Sekunden.
Frank E. schrieb: > Danke, gute Idee - mein Programmierwerkzeug "Xojo" kann tatsächlich > Threads, Threads sind an dieser Stelle overkill und machen es nur langsamer. Hunderte gleichzeitige TCP-Verbindungen kann Unix seit einem halben Jahrhundert auch ohne Threads problemlos ("select", "poll" &co). Bei deinem Xojo läuft es darauf hinaus, einfach statt hintereinander jedesmal ein "connection.SendSync" zu starten, eben "connection.Send" zu verwenden. Das kannst du ohne Verzögerung 253mal aufrufen, die Verbindungen laufen parallel im Hintergrund, und du bekommst im Erfolgsfall ein "ContentReceived"-Event, sonst ein "Error".
Εrnst B. schrieb: > Frank E. schrieb: >> Danke, gute Idee - mein Programmierwerkzeug "Xojo" kann tatsächlich >> Threads, > > Threads sind an dieser Stelle overkill und machen es nur langsamer. > "connection.SendSync" zu starten, eben "connection.Send" zu verwenden. > Das kannst du ohne Verzögerung 253mal aufrufen, die Verbindungen laufen > parallel im Hintergrund, und du bekommst im Erfolgsfall ein > "ContentReceived"-Event, sonst ein "Error". Ok, hab ich so noch nicht versucht, klingt einleuchtend.
Die Adressen 127 und 255 sind Multicast adressen. Die werden also von allen empfangen. Du kannst also dort einen algorithmus durchziehen, bei welchem dir schliesslich jeder antwortet. Und zwar schneller wie jeden einzeln abzufragen.
:
Bearbeitet durch User
Pandur S. schrieb: > Die Adressen 127 und 255 sind Multicast adressen. Eine 255 als Host-Adresse wäre eine Broadcast-Adresse in einem C-Netz, aber 127? Oliver
Pandur S. schrieb: > Die Adressen 127 und 255 sind Multicast adressen. Die letzte Adresse im Netz ist die Broadcast-Adresse (Multicast ist noch eine andere Baustelle), bei einem /24 also die .255. Die .127 ist in diesem Fall ein Host wie jeder andere.
Einen Ping auf die Broadcast Adresse und der ARP Cache ist gefüllt.
Rüdiger B. schrieb: > Einen Ping auf die Broadcast Adresse und der ARP Cache ist gefüllt. Schon ausprobiert?
Rüdiger B. schrieb: > Einen Ping auf die Broadcast Adresse und der ARP Cache ist > gefüllt. Ja? > arp -a Schnittstelle: 10.10.10.1 --- 0x1 Internetadresse Physische Adresse Typ 10.10.10.2 54-a6-02-d1-02-e5 dynamisch 10.10.10.255 ff-ff-ff-ff-ff-ff statisch > ping 10.10.10.255 Ping wird ausgeführt für 10.10.10.255 mit 32 Bytes Daten: Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Zeitüberschreitung der Anforderung. Ping-Statistik für 10.10.10.255: Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4 (100% Verlust), > arp -a Schnittstelle: 10.10.10.1 --- 0x1 Internetadresse Physische Adresse Typ 10.10.10.2 54-a6-02-d1-02-e5 dynamisch 10.10.10.255 ff-ff-ff-ff-ff-ff statisch ups. Hmmm schrieb: > Die .127 ist in diesem Fall ein Host wie jeder andere. Aber nicht bei /25 ;-)
Rüdiger B. schrieb: > Einen Ping auf die Broadcast Adresse und der ARP Cache ist gefüllt. "An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded." http://www.faqs.org/rfcs/rfc1122.html
Mario M. schrieb: > "An ICMP Echo Request destined to an IP broadcast or IP multicast > address MAY be silently discarded." Das ist heutzutage auch der Regelfall, bei mir antwortet gerade mal ein Drucker darauf. In den 90ern war das noch anders, da wurden Unternehmen auch gerne mal zu unfreiwilligen DoS-Helfern, wenn die Admins "no ip directed-broadcast" nicht kannten.
Ich mach das inzwischen mit einer Kombination aus Ping auf die IP und anschließendem arp mit der IP als Argument. Das ergibt als Antwort die MAC-Adresse für genau diese IP und keine meterlange Liste :-)
Frank E. schrieb: > Ich mach das inzwischen mit einer Kombination aus Ping auf die IP und > anschließendem arp mit der IP als Argument. Das ergibt als Antwort die > MAC-Adresse für genau diese IP und keine meterlange Liste :-) So ein Blödsinn. Richtig wäre natürlich einfach ein ARP-WhoHas an die Broadcast-Adresse des interessierenden Netzes für jede IP-Adresse des interessierenden Netzes. Und asynchron dazu einsammeln, was da an ARP-IsAt-Antworten eintrudelt. Also genau das tun, was ARP halt so tut (wenn eben auch normalerweise nur für gezielte Fragen). Kein Ahnung, was Ping (also ICMP-Echo) dabei soll. Hat doch mit der Sache garnix zu schaffen. Kein Schwein interessiert sich dafür, ob das Target gewillt ist, auf ICMP-Echo zu antworten. Was interessiert ist: ist es überhaupt gewillt, irgendwie per IP zu kommunizieren. Aber: 1. Es gibt Geräte, die ihre Bereitschaft, per IP zu kommunizieren, nicht so einfach verraten. Die wollen vorher erstmal noch einen anderen Broadcast sehen. Oder sogar eine ganz bestimmte Folge solcher Broadcasts. Bis sie die sehen, halten sie sich IP-mäßig bedeckt. 2. Es gibt sogar Geräte, die überhaupt niemals per IP kommunizieren, aber trotzdem das Netz benutzen. Halt nur auf Layer2.
Ob S. schrieb: > Frank E. schrieb: > >> Ich mach das inzwischen mit einer Kombination aus Ping auf die IP und >> anschließendem arp mit der IP als Argument. Das ergibt als Antwort die >> MAC-Adresse für genau diese IP und keine meterlange Liste :-) > So ein Blödsinn. Richtig wäre natürlich einfach ein ARP-WhoHas an die > Broadcast-Adresse des interessierenden Netzes für jede IP-Adresse des > interessierenden Netzes. Mag sein. Und wie starte ich das per CLI? ARP kennt keinen Befehl, mit "who". Aber vielleicht ist es ja das, was ich ohnehin mache? > Kein Ahnung, was Ping (also ICMP-Echo) dabei soll. Hat doch mit der > Sache garnix zu schaffen. Kein Schwein interessiert sich dafür, ob das > Target gewillt ist ... Doch. Die Targets, um die es MIR geht, abntworten definitiv auf Ping. Ich mache ja keinen allgemeinen Scan, sondern suche genau diese. Aus Experimenten weiss ich, dass ich eine ARP-Antwort nur dann sicher erhalte, wenn vorher eine Kommuniktion stattfand, z.B. Ping.
Ob S. schrieb: > Kein Ahnung, was Ping (also ICMP-Echo) dabei soll. Ping löst einen ARP-Request aus. Die MAC landet im ARP-Cache und kann mit arp -a angezeigt werden. Sozusagen ein "poor mans" arping.
Und 253-mal Ping (ggfs sogar auch per Kommandozeilen-Ping-Tool) und dann den arp-cache auslesen (per Kommandozeilen-Tool) soll schneller sein, als einfach aus deinem Programm die 253 IPs per HTTP-Get durchzutesten? Kann ich mir nicht vorstellen. Und du brauchst den HTTP-Get nach dem ARP sowieso auch noch, für dein ?cmd=ident... Und das Vorab-Filtern nach bekannter MAC kann dir bei etwas komplexeren Network-Setups auch auf die Füße fallen, Stichwort VPN, ProxyArp, usw...
Εrnst B. schrieb: > Sind 253 GET-Requests. Wenn er die parallel startet und nicht > sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig. > Wie kann ich über eine Serielle Leitung Parallel scannen? :P
Jens B. schrieb: > Εrnst B. schrieb: > >> Sind 253 GET-Requests. Wenn er die parallel startet und nicht >> sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig. >> > > Wie kann ich über eine Serielle Leitung Parallel scannen? :P Nur quasi: Threads.
Εrnst B. schrieb: > Und das Vorab-Filtern nach bekannter MAC kann dir bei etwas komplexeren > Network-Setups auch auf die Füße fallen, Stichwort VPN, ProxyArp, usw... Ich will kein universelles Werkzeug, ich brauche nur die Antwort der Clients im gleichen LAN/24. Und ich weiss, wie viele ich finden muss (4 Stück), kann also aufhören, sobald alle erkannt sind. Allzuviele Sockets gleichzeitig scheint mir auch keine so gute Idee, weil das Ganze am Raspi 4 mit 2GB laufen muss, keine Ahnung wie viele das Raspian abkann. Vielleicht hat jemand dazu eine Idee. Es ist ja nicht so, dass die biherige Methode nicht funktioniert, ich hätte sie nur gerne etwas beschleunigt. Deshalb alles komplett umzustellen lohnt sich allerdings auch nur in Grenzen.
Frank E. schrieb: > Allzuviele Sockets gleichzeitig scheint mir auch keine so gute Idee, > weil das Ganze am Raspi 4 mit 2GB laufen muss Auf dem Raspi kriegst du locker 10000 gleichzeitige GET-Requests mit deinen Datenmengen hin, bevor der überhaupt auf 1% CPU-Auslastung kommt... Allerdings nicht wenn man das über 10000 gleichzeitig laufende Threads löst. Ein einziger Aufruf des "arp"-Utilities aus deinem Programm heraus braucht schon mehr Ressourcen als der ganze Scan per TCP/HTTP... Und ist ja scheinbar auch kein Thema, was deinen RasPi irgendwie überfordert. Kurz getestet: 254 sockets (NONBLOCK) aufgemacht, allen ein "connect" gegeben, alle per epoll_ctl(...EPOLL_ADD zu einem epoll-fd hinzugefügt. Dann per epoll_wait warten, was auf den einzelnen sockets passiert, mit timeout. Die Userspace-CPU-Zeit ist mit "time" nicht mehr messbar, system/kernel-Zeit liegt bei ~12millisekunden, "real"-Zeit hängt vom gewählten Timeout ab.
1 | > time ./conn_test 192.168.23 |
2 | Successful connection to 192.168.23.1 |
3 | Successful connection to 192.168.23.8 |
4 | Successful connection to 192.168.23.17 |
5 | Successful connection to 192.168.23.120 |
6 | Timeout reached. Stopping. |
7 | |
8 | real 0m0,279s |
9 | user 0m0,000s |
10 | sys 0m0,012s |
Das wird auch nicht mehr fett, wenn man dann die sowieso schon verbundenen Sockets nimmt um ein "GET /?cmd=ident HTTP/1.0\r\n\r\n" hinterherzuschicken, und die Antwort auszulesen.
Nachtrag: Das mit <1% CPU war etwas übertrieben. Wenn ich auf die Weise 192.168.0.0/16 scanne (Also ~ 64k gleichzeitig verbindende TCP-Sockets) dann lastet das für etwas über 2 Sekunden einen CPU-Kern aus. d.H. da würde es dann langsam Sinn machen das Ganze auf 4 Threads zu verteilen.
1 | Successful connection to 192.168.1.8 |
2 | Successful connection to 192.168.1.10 |
3 | Successful connection to 192.168.1.11 |
4 | Successful connection to 192.168.1.182 |
5 | Successful connection to 192.168.1.189 |
6 | Successful connection to 192.168.1.125 |
7 | Successful connection to 192.168.1.163 |
8 | Successful connection to 192.168.1.254 |
9 | Successful connection to 192.168.1.154 |
10 | Successful connection to 192.168.1.190 |
11 | Successful connection to 192.168.1.191 |
12 | Successful connection to 192.168.23.8 |
13 | Successful connection to 192.168.23.17 |
14 | Successful connection to 192.168.1.188 |
15 | Successful connection to 192.168.1.134 |
16 | Successful connection to 192.168.23.1 |
17 | Successful connection to 192.168.1.184 |
18 | Successful connection to 192.168.1.124 |
19 | Successful connection to 192.168.144.1 |
20 | Successful connection to 192.168.144.22 |
21 | Timeout reached. Stopping. |
22 | |
23 | real 0m2,415s |
24 | user 0m0,048s |
25 | sys 0m2,105s |
:
Bearbeitet durch User
Du hast jetzt ernst mal eben einen Scanner zusammengehackt, der in "Nullzeit" alle in einem Netz erreichbaren Geräte findet? Geilo! Kannst du das für Windows bauen, gern auch als Kommandozeilendings? Oder kennst du ein "Fertigprodukt" das genau das macht? Ich wüsste nämlich auch ganz gern mal, welche IPs hier besetzt sind, und diverse Scanner dauern ewig oder melden "7 denied" aber ohne IP bei Geräten die kein HTTP können/wollen, das nutzt mir nix, ich weiß das die da sind aber eben die Adresse nicht.
Angehängte Dateien:
-
mac_finder_01.png
30 KB
So, ich hab mal was gebastelt (Xojo), das scannt ein /24-Netz in 3,5s. Was momentan fehlt, ist der Filter auf die speziell formatierte Antwort, weil ich die dazu nötigen Geräte (Automaten-Komponenten) gerade nicht im Zugriff habe. Was man hier sieht, sind die IPs und MACs, der Geräte, die in meinem privaten Netz auf einen schnöden HTTP-Request, auch ohne Parameter, antworten. Das genügt mir hinsichtlich der Geschwindigkeit vollkommen. Danke für die hilfreichen Tips.
1 | Public Sub find_mac(ip_base as string) // ip_base like "192.168.10." |
2 | |
3 | var uc(255) as URLConnection //List of HTTP-Sockets |
4 | var ff(255) as FolderItem //List of temporary files |
5 | var path as string = SpecialFolder.Temporary.NativePath+"/uc." //path in tmp folder |
6 | |
7 | var ip, ret as string |
8 | var t as TextInputStream |
9 | var i as integer |
10 | |
11 | list.RemoveAllRows //clear listbox table |
12 | |
13 | for i=1 to 254 // first loop to send the requests |
14 | uc(i) = new URLConnection |
15 | ff(i) = new FolderItem(path + str(i) + ".tmp") |
16 | uc(i).send("GET" , "http://" + ip_base + str(i) , ff(i) , 3)
|
17 | next |
18 | |
19 | wait 300 //wait 3s for timeout |
20 | |
21 | for i=1 to 254 //second loop for reading the results |
22 | |
23 | if ff(i)<>nil then |
24 | if ff(i).Exists then |
25 | |
26 | t = TextInputStream.Open(ff(i)) |
27 | |
28 | if t.readall.Trim <> "" then //if temp file not empty |
29 | |
30 | var s as new shell |
31 | ip = ip_base + str(i) |
32 | s.Execute "arp " + ip |
33 | |
34 | while s.IsRunning //wait for termination of shell |
35 | app.DoEvents |
36 | wend |
37 | |
38 | list.addrow ip , mac_reform(s.Result) //result into the listbox |
39 | end if |
40 | |
41 | t.close |
42 | ff(i).Remove |
43 | |
44 | end if |
45 | end if |
46 | next |
47 | End Sub |
:
Bearbeitet durch User
Mario M. schrieb: > "An ICMP Echo Request destined to an IP broadcast or IP multicast > address MAY be silently discarded." > > http://www.faqs.org/rfcs/rfc1122.html Oh, das ist eine Handvoll Jahre her das ich das gemacht hatte. Mit dem Browser ( oder wget ) eine HTML Seite aufrufen die alle 253 IP Adressen hat und dann den ARP Cache auslesen.
:
Bearbeitet durch User
Mario M. schrieb: > Ping löst einen ARP-Request aus. Ja klar, das tut jeder Versuch einer IP-Kommunikation (wenn die MAC der Zieladresse nicht schon im ARP-Cache ist). Genau dafür ist ARP halt da. Und für den Fall, dass man sich dafür interessiert, welche Geräte im Netz sind, die gewillt sind, per IP zu kommunizieren, reicht es also logischerweise aus, für jede Adresse des Netzes eine ARP-Anfrage zu senden. Das ist die kleinstmögliche und damit logischerweise auch schnellstmögliche Kommunikation zu diesem Thema. Genau dafür wurde ARP schließlich geschaffen. Bei allen anderen hier genannten Ansätzen wird der Kanal mit Bullshit höherer Protokolle zugespammt, die mit der eigentlichen Aufgabe rein garnix zu tun haben.
Ob S. schrieb: > Bei allen anderen hier genannten Ansätzen wird der Kanal mit Bullshit > höherer Protokolle zugespammt, die mit der eigentlichen Aufgabe rein > garnix zu tun haben. Die eigentliche Aufgabe aus dem Eröffnungs-Beitrag war ein HTTP GET an alle Geräte im Subnetz, die Port 80 offen haben. Der "Bullshit höherer Protokolle" wird also so oder so benötigt. Und das "zuspammen" verhindert schon der Kernel. Wenn der beim TCP-Connect-Versuch keine ARP-Antwort erhält oder im Cache hat, dann wandert auch kein TCP-SYN über die Leitung. Wie auch. Klar, man kann anfangen Teile des Kernel-Netzwerkstacks nachzuimplementieren, in der Hoffnung da etwas Zeit für einen speziellen Anwendungsfall rauszuholen. NMap macht das m.W. bei manchen Scan-Arten per Raw-Sockets. Aber will man sich das bei so einer kleinen Anzahl von möglichen Ziel-IPs antun?
Jens M. schrieb: > Du hast jetzt ernst mal eben einen Scanner zusammengehackt, der in > "Nullzeit" alle in einem Netz erreichbaren Geräte findet? > Geilo! Das ist komplett Boiler-Plate-Code, den hat mir ChatGPT so fast korrekt zusammengestöpselt. Für den TE bringt das nix. Die zentrale "epoll"-Event-Loop hat sein Xojo sowieso schon, Xojo packt auch die Sockets da von selber rein, und wandelt die epoll-events auf seine eigenen events am Connection-Objekt um. d.H. mindestens 75% vom Code ist sowieso schon von seinem Framework erschlagen, das muss nicht als low-level C-Code implementiert werden...
Εrnst B. schrieb: > Die eigentliche Aufgabe aus dem Eröffnungs-Beitrag war ein HTTP GET an > alle Geräte im Subnetz, die Port 80 offen haben. Nein, das war nur, was der TO getan hat, weil er es nicht besser wusste oder konnte. Wenn man das ganze Posting liest (und denken kann), stellt sich heraus: Er kennt das Netz und er kennt die die MACs der Geräte, nach denen er sucht. Also: er benötigt genau nur eins: ARP. Kein IP und schon gar kein HTTP. Das Zeug kommt dann erst zum Zuge, wenn er seine Ziele gefunden hat. Und dann eben auch nur für die. > Der "Bullshit höherer Protokolle" wird also so oder so benötigt. Aber doch nicht für jede verfickte Adresse im Netz, auf der irgendein Gerät bereit ist, IP zu sprechen... > Und das "zuspammen" verhindert schon der Kernel. Wenn der beim > TCP-Connect-Versuch keine ARP-Antwort erhält oder im Cache hat, dann > wandert auch kein TCP-SYN über die Leitung. Wie auch. Ja, aber wenn da ein Gerät ist, welches IP sprechen mag, aber eben NICHT mit der erwarteten MAC ausgestattet ist, dann geht der ganze Bullshit übers Netz. Natürlich mehr oder weniger erfolglos, aber er kostet Bandbreite und damit Zeit. Dein Argumunt passt als allerhöchstens dann, wenn das gesamte Netz bis auf die gesuchten Geräte unbenutzt ist... > Klar, man kann anfangen Teile des Kernel-Netzwerkstacks > nachzuimplementieren Das braucht man sicher nicht, um ein Sack voll simple ARP-Abfragen rauszuschicken und nach einiger Zeit einen Blick auf den Bestand des ARP-Cache zu werfen... DU kannst es nur nicht so. Das ist eigentlich schon alles.
Ob S. schrieb: > Also: er benötigt genau nur eins: ARP. Ne. Genau das braucht er nicht. ARP findet zu einer bekannten IP-Adresse die unbekannte MAC-Adresse. Das Problem des TE ist genau umgekehrt.
Franko S. schrieb: > Frank E. schrieb: >> Nur quasi: Threads. > So machen das DAUs wenn sie besonders schlau sein wollen. MFA von Microsoft Azure kann man so umgehen.
Εrnst B. schrieb: > Ne. Genau das braucht er nicht. > ARP findet zu einer bekannten IP-Adresse die unbekannte MAC-Adresse. Genau. Einen umgekehrten Weg gibt es nicht und kann es auch nicht geben. Das liegt in der Natur der Sache. Genau deswegen ist es ja auch nötig, nach sämtlichen in Frage kommenden IP-Adressen zu fragen. Und das können bei größeren Netzen schon mal eine ganze Menge sein. Bei einem 10.x.x.x/8-Netz sind es eben mal so 16.777.214 nötige Anfragen. Gerade dann zählt jedes gesparte Byte Traffic pro Anfrage... Natürlich werden sich wenigsten so ein 8er-Netz anhängen. Aber 10.x.x.x/16 oder 172.16..31.x.x/16 kommt durchaus häufiger mal vor. Da sind dann auch noch 65.534 Adressen zu befragen.
Ich hätte das ja mit nmap gemacht.
1 | harry@harry-DT:~/Downloads$ sudo nmap -sP 10.17.67.0/24 |
2 | Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-12-15 21:10 CET |
3 | Nmap scan report for _gateway (10.17.67.1) |
4 | Host is up (0.000069s latency). |
5 | MAC Address: 50:91:E3:25:B8:D0 (Unknown) |
6 | Nmap scan report for 10.17.67.3 |
7 | Host is up (0.00044s latency). |
8 | MAC Address: 14:49:BC:4B:F4:18 (DrayTek) |
9 | Nmap scan report for 10.17.67.5 |
10 | Host is up (0.00014s latency). |
11 | MAC Address: 5E:2F:8F:64:0E:94 (Unknown) |
12 | Nmap scan report for 10.17.67.9 |
13 | Host is up (0.00088s latency). |
14 | MAC Address: 9E:15:16:18:79:F2 (Unknown) |
usw...
1 | Nmap scan report for 10.17.67.146 |
2 | Host is up (0.078s latency). |
3 | MAC Address: F0:A3:B2:EE:0C:31 (Hui Zhou Gaoshengda Technology) |
4 | Nmap scan report for harry-DT (10.17.67.8) |
5 | Host is up. |
6 | Nmap done: 256 IP addresses (22 hosts up) scanned in 2.10 seconds |
Harry L. schrieb: > harry@harry-DT:~/Downloads$ sudo nmap -sP 10.17.67.0/24 'n 24er Netz ist doch absolut lächerlich. Da sind > Nmap done: 256 IP addresses (22 hosts up) scanned in 2.10 seconds 2,1 Sekunden viel zu viel. Das kann man auch in ein paar zehn ms erledigen.
Ob S. schrieb: > Das kann man auch in ein paar zehn ms > erledigen. Und das ist jetzt weshalb relevant?
Ob S. schrieb: > Genau deswegen ist es ja auch nötig, nach sämtlichen in Frage kommenden > IP-Adressen zu fragen. Nein, ist es nicht, wenn er seine Hosts richtig gebaut hätte. Nämlich so, dass sie ein Service-Discovery unterstützen. SSDP, WS-Discovery, etc. Gibt genug Protokolle. So muss er ein ganzes Subnet scannen. Was in kommerziellen Installation schnell mal richtig Ärger mit den Admins einbringt. Zumindest wenn die entsprechende Überwachungsmechanismen im LAN haben. Das Scannen ist weder toll noch clever, sondern Pfusch. Kein Grund sich zu feiern.
Hannes J. schrieb: > Nein, ist es nicht, wenn er seine Hosts richtig gebaut hätte. Nämlich > so, dass sie ein Service-Discovery unterstützen. SSDP, WS-Discovery, > etc. Gibt genug Protokolle. Ja klar. Und woher weißt du bei der Geräteentwicklung, welches dieser Protokolle im Zielnetz der Geräte "zugelassen" ist? Typisch weiß man ja bei der Geräteentwicklung noch nicht, wohin der Kram mal verkauft werden wird. Allenfalls hat man zu diesem Zeitpunkt gewisse Hoffnungen, an wen man das verkaufen könnte, aber man hat wohl kaum Detailinformationen zu den Netzen der gewünschten Kunden... > So muss er ein ganzes Subnet scannen. Was in kommerziellen Installation > schnell mal richtig Ärger mit den Admins einbringt. Zumindest wenn die > entsprechende Überwachungsmechanismen im LAN haben. Wenn das Netz derart restriktiv konfiguriert ist, dass es sogar ARP-Requests limitiert (ganz ausschalten kann man die heute wohl aus praktischen Gründen nicht mehr, fast alles spricht IP und braucht dementsprechend ARP), dann kannst du GANZ sicher davon ausgehen, dass auch nicht übermässig viele Discovery-Protokolle darin zugelassen und die zugelassenen im Detail auch wieder nur restriktiv zugelassen sind. Sprich: selbst wenn es z.B. WS-Discovery prinzipiell gibt (weil z.B. bestimmte Drucker verwendet werden sollen), dann wird trotzdem nicht jedes Gerät die Vollmacht haben, sich in das entsprechende Verzeichnis einzutragen. Wäre ja noch schöner... Sprich: dieser Ansatz hilft dem TO in stark reglementierten Netzen auch nicht weiter. Sehr wahrscheinlich tut das dann aber überhaupt kein Ansatz. Typisch ist in solchen Netzen nämlich auch Port-Security durchgesetzt. D.h.: du kannst deine Geräte zwar an irgendwelche Dosen dranstöpseln, sie werden dort aber nichts weiter tun können als einen Alarm für den Admin auszulösen...
Ob S. schrieb: > Wenn das Netz derart restriktiv konfiguriert ist, dass es sogar > ARP-Requests limitiert (ganz ausschalten kann man die heute wohl aus > praktischen Gründen nicht mehr, fast alles spricht IP und braucht > dementsprechend ARP) Kann man (z.B. ifconfig <if> -arp), dann braucht man halt statische Einträge. Ist aber nur in seltenen Fällen sinnvoll. Was mir hingegen schon in der Praxis begegnet ist, sind Geräte, die nicht auf ARP-Requests antworten, sondern ausschliesslich in festen Intervallen Gratuitous ARP (also unaufgeforderte Replies) verschicken. Da das Smartwatches waren, wohl aus Energiespargründen.
Hmmm schrieb: > Was mir hingegen schon in der Praxis begegnet ist, sind Geräte, die > nicht auf ARP-Requests antworten, sondern ausschliesslich in festen > Intervallen Gratuitous ARP (also unaufgeforderte Replies) verschicken. Huch... Gibt es tatsächlich noch Geräte, die solche ARP-"Antworten" in ihren ARP-Cache aufnehmen? Das sollte doch wegen des zeitweise sehr beliebten Angriffszenarios des ARP-Spoofing inzischen praktisch überall geblockt werden. OK, ARP-Spoofing funktioniert auch mit Unicast-Antworten. Aber eben nur bei einem Peer, nicht gleich bei allen.
Nochmal zurück nach oben: Εrnst B. schrieb: > Multicast-DNS wurde genau für sowas gemacht, müssen deine Geräte im > Netzwerk aber natürlich unterstützen. Das ist keine Option? Da kannst du einfach jedem Gerät einen Namen geben, über den du es dann unabhängig von seiner IP ansprechen kannst, genau wie mit klassischem DNS, nur dass man keinen Server braucht. Jens B. schrieb: > Εrnst B. schrieb: > >> Sind 253 GET-Requests. Wenn er die parallel startet und nicht >> sequentiell, hat er in weniger als 0.1 Sekunden seine Liste fertig. >> > > Wie kann ich über eine Serielle Leitung Parallel scannen? :P Ich vermute, es bezog sich auf die Software, nicht auf die Leitung selbst. Wenn man einen GET-Request versucht, muss man ja so lange warten, bis eine Antwort kommt oder der Timeout abläuft. Also macht man mehrere Requests parallel, damit die alle gleichzeitig warten können statt nacheinander.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.