IP oder MAC Adressen im Netzwerk finden

[Edwin1966]

Hallo

Ok, habe ich verstanden. Müsste ich also mit Wireshark beobachten, wie Siemens seine Teilnehmer anspricht?
Hast du noch einen Tipp für mich, wie ich Nachrichten über Broadcast sende? Welche Software?

Ach ja, wollte noch erwähnen: Siemens findet auch andere Teilnehmer im Netz - zwar nur Profinet-Teilnehmer aber eben auch Cognex, Keyence, ...
Cognex macht etwas ähnliches bei GigE Teilnehmern, auch Herstellerunabhängig: Basler, Baumer, Manta, Ace, ...

 

[Nilson]

Profinet läuft über DCP:
https://profinetuniversity.com/naming-addressing/profinet-dcp/
Das ist im Profinet-Standard hinterlegt.

 

[Raijin]

Zu Profinet hat @Nilson freundlicherweise schon geantwortet. Sowas lässt sich aber nicht auf x-beliebige Netzwerkteilnehmer übertragen.



Zäumen wir das Pferd mal andersherum auf: Du hast jetzt in 3 Beiträgen effektiv nur gefragt wie das geht bzw. warum du der Meinung bist, dass es gehen müsste. Von deinem eigentlichen Vorhaben oder gar einem handfesten Problem hast du aber bisher kein Wort erwähnt.

Worum geht es also ganz konkret? Was für ein Gerät suchst du in deinem Netzwerk? Und warum setzt du es nicht einfach auf Werkszustand zurück und folgst dessen Anleitung für die Ersteinrichtung, die in der Regel entweder auf eine statische Standard-IP oder die Suche nach einer IP im DHCP-Server hinausläuft?

 

[Edwin1966]

Hy

Wenn ich das richtig verstanden habe, müsste bei Profinet mit dcp identify all möglich sein, auch Teilnehmer mit anderer IP-Adresse zu finden?

Prinzipiell geht es darum, die Arbeit zu erleichtern, wenn man Teilnehmer hat, von denen man die IP-Adresse nicht kennt. Bei Beckhoff z.B. funktioniert die Broadcast Suche leider nicht immer...

Wenn es nicht für alle Teilnehmer möglich ist, nehme ich das natürlich auch hin, aber ich möchte es zumindest mal versuchen, die Teilnehmer anzusprechen - leider habe ich keine Idee, wie ich eine Nachricht über Broadcast zu allen Teilnehmern sende. Gibt es hierfür ein Programm? Kann man das über die Konsole machen, usw???

Auf Werkseinstellung setzen, ist nicht immer möglich, da bei einigen Geräten (bsp Smartkamera) dann auch die Programme gelöscht werden. Oft ist die Datensicherung nicht aktuell und man würde wichtige Informationen verlieren.

 

[Raijin]

Wenn ich das richtig verstanden habe, müsste bei Profinet mit dcp identify all möglich sein, auch Teilnehmer mit anderer IP-Adresse zu finden?

Ja, aber das liegt eben daran, dass Profinet-Geräte das DCP-Protokoll unterstützen und zB Teil der enstprechenden Multicast-Gruppe sind, über die DCP Informationen verteilt. Ich stecke in dem Protokoll auch nicht tiefer drin, aber Fakt ist nun mal, dass nur Geräte, die DCP unterstützen, auch über DCP gefunden werden können. Mittels Broadcasts und Multicasts können so zB auf Layer 2 - MAC-Adressen - Verbindungen unabhängig von der IP-Adressen aufgebaut werden und eben auch IP-Adressen geändert werden, über die Projektierungs-Software, die eben diese Geräte in der Device Discovery gefunden hat und ihnen eine neue IP zuweist.

Wenn es nicht für alle Teilnehmer möglich ist, nehme ich das natürlich auch hin, aber ich möchte es zumindest mal versuchen, die Teilnehmer anzusprechen - leider habe ich keine Idee, wie ich eine Nachricht über Broadcast zu allen Teilnehmern sende. Gibt es hierfür ein Programm? Kann man das über die Konsole machen, usw???

Um was zu erreichen? Theoretisch kann man die Broadcast-IP des Subnetzes (zB 192.168.1.255) anpingen und theoretisch würden alle Geräte antworten, aber praktisch werden die meisten Geräte derartige Pings schlichtweg ignorieren. Unter Linux wird beispielsweise sysctl net.ipv4.icmp_echo_ignore_broadcasts standardmäßig mit 1 quittiert. Das heißt, dass Pings (=ICMP-Echo-Request), die als Broadcast am Gerät eintreffen, ignoriert werden. Gleiches gilt für Pings auf die allgemeine Broadcast-IP 255.255.255.255.

Unter Windows kann man weder die eine noch die andere IP-Adresse pingen, weil Windows keine Broadcast-Pings zulässt, zumindest nicht über ping.exe. Es mag sein, dass separate Ping-Tools das können (sofern Windows das nicht ganz allgemein blockiert), aber trotzallem sind die Antworten der anderen Netzwerkteilnehmer fraglich.

Auf Werkseinstellung setzen, ist nicht immer möglich, da bei einigen Geräten (bsp Smartkamera) dann auch die Programme gelöscht werden. Oft ist die Datensicherung nicht aktuell und man würde wichtige Informationen verlieren.

Ok, das ist natürlich "dumm gelaufen". Wenn ein Reset inkl. Datenverlust fatal wäre, muss man eben den steinigen Weg gehen und durchprobieren. Als erstes wie schon geschrieben wurde mittels WireShark bzw. tcpdump prüfen ob ggfs ARP-Requests zu sehen sind, zB weil das fragliche Gerät sein Standard-Gateway sucht. ARP-Requests sehen in etwa so aus:

Src = MAC-Adresse des Absenders
Dst = Broadcast (FF:FF:FF:FF:FF:FF)
Message: "Who has 192.168.234.1? Tell 192.168.234.23" <-- Letzteres ist die IP des Absenders


Findet man das Gerät dennoch nicht, muss man schlimmstenfalls in den sauren Apfel beißen und zumindest die gängigen privaten Subnetze abgrasen. Das heißt: Dem PC eine IP aus dem entsprechenden Subnetz verpassen (zB 192.168.234.254 / Subnetzmaske: 255.255.255.0) und anschließend mit AngryIP, nmap, o.ä. einen Subnetz-Scan durchführen. Findet man nichts, geht man ein Subnetz weiter (192.168.235.254 /24) und führt erneut einen Scan durch.
Ja, das ist langwierig und unschön, aber es hilft leider nichts. Es bringt auch nichts, dem PC zB eine 255.255.0.0 Subnetzmaske zu verpassen, weil das fragliche Gerät tendenziell eine andere Subnetzmaske hat und schlicht und ergreifend nicht antworten kann, weil sein Standardgateway nicht vorhanden ist. Mit Glück könnte man über diesen Weg aber einen ARP-Request des gesuchten Geräts provozieren, aber so oder so muss der Subnetz-Scan erstmal auf die richtige IP-Adresse stoßen...

 

[Sebbi]

Findet man das Gerät dennoch nicht, muss man schlimmstenfalls in den sauren Apfel beißen und zumindest die gängigen privaten Subnetze abgrasen.

hier kann man aber auch was feines machen, in den man sich sich direkt an das gerät hockt mit Wireshark und LAN per direkter Verbindung mit dem Gerät verbindet. Wireshark muss da natürlich schon vorher laufen um den Verbindungsprozess mitzuscheinden.

• hat es keine Feste IP, hat man mit den DHCP discover die MAC und kann auf dem DHCP Server / Router nachsehen, welche IP das gerät bekommen hat
• hat es eine feste IP, kann man durch das Lauschen schon die IP herausbekommen.

da ist es auch dann egal welche wie die Netzwerkkonfig ist, denn man bekommt ja eh alle Pakete mit. Man muss eben nur sich vor Ort begeben.

 

[Raijin]

hat es eine feste IP, kann man durch das Lauschen schon die IP herausbekommen.

Das kommt drauf an. Wie gesagt, ARP-Requests zur Suche nach dem Standard-Gateway sieht man womöglich (es sei denn das Gerät hat gar kein Standard-Gateway), aber sonst sieht man nichts, wenn das fragliche Gerät keinen besonderen Mitteilungsdrang hat. Hier wird ja sehr allgemein von "Geräten mit unbekannter IP" gesprochen und dann kann es eben auch sein, dass die wirklich so gar nichts von sich geben, wenn sie nicht direkt angesprochen werden.

Aber ich lerne auch gerne dazu, wenn du konkret etwas im Auge hast. DHCP ok, aber das setzt natürlich voraus, dass das Gerät überhaupt auf DHCP eingestellt ist und dann erübrigt sich eigentlich der gesamte Thread

 

[Sebbi]

Das kommt drauf an. Wie gesagt, ARP-Requests zur Suche nach dem Standard-Gateway

ich glaube da verwechselst du gerade etwas. Gateway Suche wäre via DHCP Zuweisung oder fest eingetragen.

ARP Requests sind aber eher dafür gedacht (lokale) Routingtabellen auf dem Client aufzubauen, sprich eine lokale IP der logischen Schicht in eine MAC auf der physichen Schicht aufzulösen.

Ferner werden aber auch , ich glaube ARP, Requests ausgesendet, sobald ein Gerät einen Link aufbaut zum Switch etc und es sich so auch bekannt macht an den Netzwerkkomponentnen, aber auch für die Konflikterkennung, wenn die fest vergebene IP schon irgendwo im Netzwerk vorhanden ist.
Hast du ggf auch schon einmal gesehen diese schöne Meldung von Windows im Netzwerkbereich mit "Adresskonflikt"

 

[Raijin]

ich glaube da verwechselst du gerade etwas. Gateway Suche wäre via DHCP Zuweisung oder fest eingetragen.

Das Gegenteil ist der Fall. ARP hat nichts mit DHCP zu tun.

Ethernet arbeitet auf Layer2, also MAC-Adressen. Wenn ein PC zB einen Ping auf 8.8.8.8 machen möchte, guckt er in seine Routingtabelle wohin das Paket soll und findet zB die Standardroute nebst Gateway. Nun nimmt der PC diese Gateway-IP und braucht die dazugehörige MAC, weil der Ping bzw das Paket auf Layer2 zum Gateway geschickt werden muss. Es folgt zunächst ein ARP-Request, der das Gateway via Broadcast (weil unbekannte MAC) dazu auffordert, sich zu melden. Das Gateway antwortet mit einem ARP-Reply, der PC kennt jetzt die MAC und bastelt ein IP-Paket (Layer3) mit Ziel-IP 8.8.8.8, verpackt es aber in ein Layer2 Paket und adressiert dieses an die MAC des Gateways.

Der ARP-Request kommt aber nur dann, wenn die MAC des Gateways nicht bereits bekannt ist, zB weil es gleichzeitig der DHCP-Server ist oder es zwischenzeitlich anderweitigen Kontakt zwischen PC und Gateway gab. Im Falle von Geräten mit unbekannter statischer IP aus potentiell anderen Subnetzen, wird es aber keinen Kontakt zum Gateway geben, weil es schlichtweg nicht existiert. Ergo müsste man ARP-Requests mit der Gateway IP und der eigenen IP des unbekannten Geräts sehen, sofern dieses zB versucht, Updates, o.ä. zu suchen und das Gateway nicht findet.

ARP Requests sind aber eher dafür gedacht (lokale) Routingtabellen auf dem Client aufzubauen, sprich eine lokale IP der logischen Schicht in eine MAC auf der physichen Schicht aufzulösen.

Ganz genau. Das entspricht dem eben beschriebenen Verfahren. Ohne dass die MAC (L2) des Gateways bekannt ist, gibt's nix Kommunikation auf IP-Ebene (Layer3) jenseits des eigenen lokalen Subnetzes und darüber, weil die Schichten aufeinander aufbauen bzw ineinander gekapselt werden.

 

[Sebbi]

Das Gegenteil ist der Fall. ARP hat nichts mit DHCP zu tun.

das hatte ich auch nicht gesagt. Du sagtest Gateway Suche via ARP mit "ARP-Requests zur Suche nach dem Standard-Gateway"
Was aber eben nicht korrekt ist, denn die Standard Gateway IP ist ja bekannt, entweder via DHCP oder eben fest eingestellt.
Aber ich weiß was du meinst, nur war das von deiner Seite aus unglücklich ausgedrückt. Besser wäre gewesen "Anfrage der MAC des Standard-Gateways"

 

[Raijin]

Du sagtest Gateway Suche via ARP mit "ARP-Requests zur Suche nach dem Standard-Gateway"
Was aber eben nicht korrekt ist, denn die Standard Gateway IP ist ja bekannt, entweder via DHCP oder eben fest eingestellt.

Ähm, doch? Aber wir reden aneinander vorbei. Das Gateway hat nun mal sowohl eine IP-Adresse auf Layer3 als auch eine MAC-Adresse auf Layer2. Die IP ist bekannt, bringt aber allein nichts, wenn die MAC nicht bekannt ist und deshalb wird das Gateway - oder sagen wir von mir aus "das Gerät mit der IP, die das Gateway darstellt" - mittels ARP gesucht, aber eben auf Layer2.