34
Netzwerkgerät im Netzwerk verschwindet nach Neustart
Hallo zusammen,
ich habe ein skurriles Problem und hoffe, dass hier jemand weiterhelfen kann.
Problemstellung:
Ich nutze einen kleinen 1-Platinen-Computer (BeagleBone Black) mit Debian, auf dem eine OSGi-Anwendung läuft. Ein Node der Anwendung baut eine TCP-Verbindung zu einer RS485-Schnittstelle auf.
Eckdaten:
- BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
Das Problem:
Nach einem Neustart des BBB ist die RS485-Schnittstelle für diesen PC nicht erreichbar. Wenn ich versuche, sie per `ping` zu erreichen, geht das ARP-Paket ins Leere, als ob das Gerät nicht im Netzwerk wäre. Erst nachdem ich von einem anderen Gerät (meinem Windows-PC) einmal das RS485 anpinge, kann der BBB die RS485-Schnittstelle wieder normal erreichen und die Kommunikation läuft.
Auch ein Neustart der RS485-Schnittstelle bringt nichts, die Verbindung funktioniert erst wieder, nachdem ein anderer Netzwerkteilnehmer darauf zugreift.
Vermutung:
Ich habe den Verdacht, dass die Ursache bei den drei Mikrotik-Switches liegt, die im Netzwerk verbaut sind und per Daisy-Chain miteinander verbunden sind. Die Switches laufen alle in Standardkonfiguration, da kein spezielles Management eingerichtet ist.
Hat jemand eine Idee, woran das liegen könnte oder wie ich das Problem beheben kann?
Vielen Dank im Voraus!
ich habe ein skurriles Problem und hoffe, dass hier jemand weiterhelfen kann.
Problemstellung:
Ich nutze einen kleinen 1-Platinen-Computer (BeagleBone Black) mit Debian, auf dem eine OSGi-Anwendung läuft. Ein Node der Anwendung baut eine TCP-Verbindung zu einer RS485-Schnittstelle auf.
Eckdaten:
- BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
Das Problem:
Nach einem Neustart des BBB ist die RS485-Schnittstelle für diesen PC nicht erreichbar. Wenn ich versuche, sie per `ping` zu erreichen, geht das ARP-Paket ins Leere, als ob das Gerät nicht im Netzwerk wäre. Erst nachdem ich von einem anderen Gerät (meinem Windows-PC) einmal das RS485 anpinge, kann der BBB die RS485-Schnittstelle wieder normal erreichen und die Kommunikation läuft.
Auch ein Neustart der RS485-Schnittstelle bringt nichts, die Verbindung funktioniert erst wieder, nachdem ein anderer Netzwerkteilnehmer darauf zugreift.
Vermutung:
Ich habe den Verdacht, dass die Ursache bei den drei Mikrotik-Switches liegt, die im Netzwerk verbaut sind und per Daisy-Chain miteinander verbunden sind. Die Switches laufen alle in Standardkonfiguration, da kein spezielles Management eingerichtet ist.
Hat jemand eine Idee, woran das liegen könnte oder wie ich das Problem beheben kann?
Vielen Dank im Voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669471
Url: https://administrator.de/forum/netzwerkgeraet-im-netzwerk-verschwindet-nach-neustart-669471.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
34 Kommentare
Neuester Kommentar
ARP geht ins leere?
Heißt die Switches kennen die Mac nicht mehr und dann auf einmal doch wieder?
Heißt die Switches kennen die Mac nicht mehr und dann auf einmal doch wieder?
Das hatte ich nicht überprüft. Am BBB konnte ich die IP nimmer pingen. Ein Blick beim BBB ins ARP zeigte das er die IP nicht auflösen konnte.
Nachdem ich die Weboberfläche oder einen Ping von meinem Windows PC machte, konnte der BBB die IP wieder erreichen.
Aber da ich vom Windows PC das RS485 Gateway erreichen konnte, muss der Switch ja die MAC davon kennen.
EDIT: Ich habe 2 dieser RS485 Gateway mit dem selben BBB bei mir am laufen und kann es nicht nachstellen. Meine Vermutung geht eben in die Richtung der Switche.
Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
Einer wäre die Switche neu zu starten.
Ein Neustart des BBB und RS485 GW brachte ja keinen Erfolg
Nachdem ich die Weboberfläche oder einen Ping von meinem Windows PC machte, konnte der BBB die IP wieder erreichen.
Aber da ich vom Windows PC das RS485 Gateway erreichen konnte, muss der Switch ja die MAC davon kennen.
EDIT: Ich habe 2 dieser RS485 Gateway mit dem selben BBB bei mir am laufen und kann es nicht nachstellen. Meine Vermutung geht eben in die Richtung der Switche.
Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
Einer wäre die Switche neu zu starten.
Ein Neustart des BBB und RS485 GW brachte ja keinen Erfolg
Moin,
Einfacher ist es, die beiden Geräte an einen einfachen, nicht konfigurierbaren Switch zu hängen, sonst nichts, keine Verbindung zum sonstigen Netzwerk, dann noch ggf. einen Laptop dazu, und damit testen. Sinnvoller, als an den Switchen alles mögliche zu verstellen, um danach festzustellen, dass das Problem woanders liegt.
Gruß
DivideByZero
Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
Einer wäre die Switche neu zu starten.
Einer wäre die Switche neu zu starten.
Einfacher ist es, die beiden Geräte an einen einfachen, nicht konfigurierbaren Switch zu hängen, sonst nichts, keine Verbindung zum sonstigen Netzwerk, dann noch ggf. einen Laptop dazu, und damit testen. Sinnvoller, als an den Switchen alles mögliche zu verstellen, um danach festzustellen, dass das Problem woanders liegt.
Gruß
DivideByZero
1
Er muss ja nichts verstellen um zu gucken ob die Mac im Arp Cache ist und bleibt.
Ping ist noch mal ein anderes Thema.
Immer der Reihe nach.
Ping ist noch mal ein anderes Thema.
Immer der Reihe nach.
Moin,
Ich frage mal vorsichtig:
TCP 502 ist doch Modbus!?
RS485 wäre zudem Modbus RTU
Und wie soll denn die RS485 eine IP bekommen und dann obendrein ne MAC in den ARP-Tabellen der Switche anlegen?
Und dass beide Interfaces, NIC und RS485, eine IP im selben Netz haben, ist sicherlich auch nicht förderlich.
BTW: ist dieses Modul verbaut?
Was soll die Kiste inhaltlich eigentlich machen?
Eckdaten:
. - BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
. - BeagleBone Black (BBB): IP 192.168.1.246
- RS485: IP 192.168.1.247
- Port: TCP 502
Ich frage mal vorsichtig:
TCP 502 ist doch Modbus!?
RS485 wäre zudem Modbus RTU
Und wie soll denn die RS485 eine IP bekommen und dann obendrein ne MAC in den ARP-Tabellen der Switche anlegen?
Und dass beide Interfaces, NIC und RS485, eine IP im selben Netz haben, ist sicherlich auch nicht förderlich.
BTW: ist dieses Modul verbaut?
Was soll die Kiste inhaltlich eigentlich machen?
1
Hi!
Es ist an sich ein ModBus RTU Gateway, aber Protokoll ist off. Dadurch reines RS485.
Das RS485 ist natürlich ein Gateway. Hat also einen Ethernet Anschluss und einen RS485 Anschluss.
Ist ein Connect für ekey Fingerprint
Es ist an sich ein ModBus RTU Gateway, aber Protokoll ist off. Dadurch reines RS485.
Das RS485 ist natürlich ein Gateway. Hat also einen Ethernet Anschluss und einen RS485 Anschluss.
Ist ein Connect für ekey Fingerprint
Und dass beide Interfaces, NIC und RS485, eine IP im selben Netz haben, ist sicherlich auch nicht förderlich.
Wie?BTW: ist dieses Modul verbaut?
Nein, kein cape. Der BBB ist Standalone und das RS485 ist von WaveShareZitat von @DivideByZero:
Moin,
Einfacher ist es, die beiden Geräte an einen einfachen, nicht konfigurierbaren Switch zu hängen, sonst nichts, keine Verbindung zum sonstigen Netzwerk, dann noch ggf. einen Laptop dazu, und damit testen. Sinnvoller, als an den Switchen alles mögliche zu verstellen, um danach festzustellen, dass das Problem woanders liegt.
Gruß
DivideByZero
Moin,
Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
Einer wäre die Switche neu zu starten.
Einer wäre die Switche neu zu starten.
Einfacher ist es, die beiden Geräte an einen einfachen, nicht konfigurierbaren Switch zu hängen, sonst nichts, keine Verbindung zum sonstigen Netzwerk, dann noch ggf. einen Laptop dazu, und damit testen. Sinnvoller, als an den Switchen alles mögliche zu verstellen, um danach festzustellen, dass das Problem woanders liegt.
Gruß
DivideByZero
Ist auch eine Möglichkeit und schnell die Switche auszuschließen. Da alle IPs statisch sind, werde ich das testen.
Hallo,
Und was steht dann als Antwort da? Nichts? Ein Ping lebt ausschließlich von den Antworten...
Eine IP ist eindeutig und schon aufgelöst. Aufgelöster geht es nicht.
https://blog.globalping.io/how-to-read-ping-results-a-beginners-guide/
https://www.kentik.com/kentipedia/ping-command-in-network-troubleshootin ...
Gruss,
Peter
Und was steht dann als Antwort da? Nichts? Ein Ping lebt ausschließlich von den Antworten...
Ein Blick beim BBB ins ARP zeigte das er die IP nicht auflösen konnte.
Und in was soll eine IP aufgelöst werden? Eine Super-IP? In Marmelade? Oder meintest du das dein arp -a dir keine passende IP und mac (Physische Adresse) nannte?Eine IP ist eindeutig und schon aufgelöst. Aufgelöster geht es nicht.
Einer wäre die Switche neu zu starten.
Aber vorher schauen was in deren Logs drin steht, deren arp Tabellen etc. Und auch mit einen Kabelhai mal schauen. Ein Tracert hilft dir auch den weg der Pings zu klären. Evtl. ändert sich ja dort das Routing oder Knut Rupprecht schaltet dort Strom ab und Firewall ein. Welches Gerät gibt denn die letzte Meldung wenn der Ping nicht mehr Erfolgreich ist?https://blog.globalping.io/how-to-read-ping-results-a-beginners-guide/
https://www.kentik.com/kentipedia/ping-command-in-network-troubleshootin ...
Gruss,
Peter
Grundsätzlich wäre es praktisch zu wissen, wo die ARP Auflösung scheitert.
Wenn der BBB die IP nicht auflösen kann, kann er auch nichts absenden.
Hatte danach beide Geräte auf einen Mikrotik Switch gehängt. Weiß jemand ob man den Traffic bei 2 Ports debuggen kann?
Der BBB muss ja nach dem Neustart den ARP absenden. Der Switch muss das an alle Ports, außer dem Source, weiterleiten: Heißt: mit Wireshark muss ich das ARP request auf meinem Windows PC sehen.
Bin nimmer so up2date (nach einigen Jahrzenten): das ARP request wird als Broadcast geantwortet? oder als Unicast an die Source?
Ich meine es kann ja nur 3 Fehlermöglichkeiten geben:
Wenn der BBB die IP nicht auflösen kann, kann er auch nichts absenden.
Hatte danach beide Geräte auf einen Mikrotik Switch gehängt. Weiß jemand ob man den Traffic bei 2 Ports debuggen kann?
Der BBB muss ja nach dem Neustart den ARP absenden. Der Switch muss das an alle Ports, außer dem Source, weiterleiten: Heißt: mit Wireshark muss ich das ARP request auf meinem Windows PC sehen.
Bin nimmer so up2date (nach einigen Jahrzenten): das ARP request wird als Broadcast geantwortet? oder als Unicast an die Source?
Ich meine es kann ja nur 3 Fehlermöglichkeiten geben:
- Der BBB sendet kein ARP
- Der Mikrotik blockiert die ARP
- das RS485 GW antwortet nicht auf die ARP
Und in was soll eine IP aufgelöst werden? Eine Super-IP? In Marmelade? Oder meintest du das dein arp -a dir keine passende IP und mac (Physische Adresse) nannte?
Eine IP ist eindeutig und schon aufgelöst. Aufgelöster geht es nicht.
Eine IP ist eindeutig und schon aufgelöst. Aufgelöster geht es nicht.
Man sollte die Antwort eigentlich aus den Zeilen rauslesen können:
Natürlich das er die MAC Adresse nicht ermitteln kann. Geprüft via arp -a
aufgelöst ersetze mit MAC ermitteln. Das soll der Satz auch für dich wieder passen
🤷🫣
Zitat von @Pjordorf:
Aber vorher schauen was in deren Logs drin steht, deren arp Tabellen etc. Und auch mit einen Kabelhai mal schauen. Ein Tracert hilft dir auch den weg der Pings zu klären. Evtl. ändert sich ja dort das Routing oder Knut Rupprecht schaltet dort Strom ab und Firewall ein. Welches Gerät gibt denn die letzte Meldung wenn der Ping nicht mehr Erfolgreich ist?
Aber vorher schauen was in deren Logs drin steht, deren arp Tabellen etc. Und auch mit einen Kabelhai mal schauen. Ein Tracert hilft dir auch den weg der Pings zu klären. Evtl. ändert sich ja dort das Routing oder Knut Rupprecht schaltet dort Strom ab und Firewall ein. Welches Gerät gibt denn die letzte Meldung wenn der Ping nicht mehr Erfolgreich ist?
Die Pings sind an sich egal. Das Problem ist das er die MAC Adresse nicht ermitteln kann. Also schlägt die ARP fehl.
Ich meine die Antwort war "No Route to host".
Ich bin morgen nochmal vor Ort und checke das genauer.
Aber solange er die MAC nicht ermitteln kann, erfolgt keinerlei Kommunikation im Ethernet. Kein Ping, HTML request oder was auch immer.
Man kann wohl den Mikrotik sniffen:
https://tojaj.com/packet-capture-from-mikrotik-to-wireshark/
Dann müsste ich ja sehen, wie die ARP zwischen den beiden Ports ablaufen.
Hat das schon einmal jemand am laufen gehabt?
https://tojaj.com/packet-capture-from-mikrotik-to-wireshark/
Dann müsste ich ja sehen, wie die ARP zwischen den beiden Ports ablaufen.
Hat das schon einmal jemand am laufen gehabt?
Hallo,
Wireshark zeigt es dir.
https://networkengineering.stackexchange.com/questions/77982/is-the-ping ...
Musst dann am Switch ein Port Mirror machen, dann kannste auch Pakete für andere als deine mac sehen.
https://forum.mikrotik.com/viewtopic.php?t=195968
https://www.reddit.com/r/mikrotik/comments/dghfa3/port_mirroring_for_wir ...
https://forum.mikrotik.com/viewtopic.php?t=58471
https://www.technicallyinsane.com/2015/10/mirroring-ports-on-mikrotik.ht ...
Gruss,
Peter
Wireshark zeigt es dir.
Wenn der BBB die IP nicht auflösen kann, kann er auch nichts absenden.
Du pingst die IP, der Switch dazwischen kann aber nur die mac, also schaut der in seine arp Tabelle an welchem Port er das Paket weiterleiten muss die du anpingen willst.Weiß jemand ob man den Traffic bei 2 Ports debuggen kann?
Klar kann ein Mikrotik das.Der Switch muss das an alle Ports, außer dem Source, weiterleiten:
https://networkengineering.stackexchange.com/questions/19881/pinging-bro ...https://networkengineering.stackexchange.com/questions/77982/is-the-ping ...
Heißt: mit Wireshark muss ich das ARP request auf meinem Windows PC sehen.
Nö, dein Switch gibt dir nur Pakete für deine NIC, und Broadcasts. Ein Switch ist kein Ethernet HubMusst dann am Switch ein Port Mirror machen, dann kannste auch Pakete für andere als deine mac sehen.
https://forum.mikrotik.com/viewtopic.php?t=195968
https://www.reddit.com/r/mikrotik/comments/dghfa3/port_mirroring_for_wir ...
https://forum.mikrotik.com/viewtopic.php?t=58471
https://www.technicallyinsane.com/2015/10/mirroring-ports-on-mikrotik.ht ...
Bin nimmer so up2date (nach einigen Jahrzenten): das ARP request wird als Broadcast geantwortet? oder als Unicast an die Source?
https://de.wikipedia.org/wiki/Ping_(Daten%C3%BCbertragung)* Der BBB sendet kein ARP
Wireshark sagt es dir* Der Mikrotik blockiert die ARP
Die Logs sagen es dir* das RS485 GW antwortet nicht auf die ARP
Wireshark sagt es dirIch meine die Antwort war "No Route to host".
Und wenn er die mac nicht kennt kann er auch nicht eine Route dafür anfordern. Ein Wireshark sagt es dir. Und dass so eine Antwort eher Blödsinn ist ist dir klar. Was genau ist als Antwort gekommen?Gruss,
Peter
Zitat von @Pjordorf:
Du pingst die IP, der Switch dazwischen kann aber nur die mac, also schaut der in seine arp Tabelle an welchem Port er das Paket weiterleiten muss die du anpingen willst.
Du pingst die IP, der Switch dazwischen kann aber nur die mac, also schaut der in seine arp Tabelle an welchem Port er das Paket weiterleiten muss die du anpingen willst.
Da liegst du aber weit daneben. Der Ablauf am Ethernet istt:
a) Bevor ein Host überhaupt eine Kommunikation startet, sendet er eine ARP raus, wenn ihm die MAC noch nicht bekannt ist
b) Der sich angesprochene Host antwortet auf das ARP request und sendet seine MAC retour
c) der host kennt nun die MAC und adressiert das Netzwerkpaket mit der MAC Adresse
d) der Switch kennt ebenso die MACs und leitet es entsprechend weiter
Im lokalen Netzwerk findet keine Kommunikation über IP statt. Das ist L3. Wir befinden uns auf L2
Das habe ich dir geschrieben. Wenn ich es noch exakt wüsste, könnte ich es besser zitieren.
Morgen am Abend kann ich es erneut testen
Zitat von @Pjordorf:
Musst dann am Switch ein Port Mirror machen, dann kannste auch Pakete für andere als deine mac sehen.
Heißt: mit Wireshark muss ich das ARP request auf meinem Windows PC sehen.
Nö, dein Switch gibt dir nur Pakete für deine NIC, und Broadcasts. Ein Switch ist kein Ethernet HubMusst dann am Switch ein Port Mirror machen, dann kannste auch Pakete für andere als deine mac sehen.
Ich hoffe ich beleidige sich jetzt nicht, aber dir scheinen die Basics zu fehlen.
Natürlich sehe ich die ARP request von jedem Host im Netzwerk. Dieser werden als Broadcast gesendet und jeder bekommt die!
Hallo,
https://www.elektronik-kompendium.de/sites/net/0901061.htm
https://www.security-insider.de/was-ist-arp-address-resolution-protocol- ...
https://www.fortinet.com/de/resources/cyberglossary/what-is-arp
https://en.wikipedia.org/wiki/Address_Resolution_Protocol
https://blog.it-planet.com/switch-vs-hub-vs-router-wesentliche-unterschi ...
https://www.msxfaq.de/tools/3rdparty/portmirroring.htm
Gruss,
Peter
Zitat von @Fohnbit:
Ich hoffe ich beleidige sich jetzt nicht, aber dir scheinen die Basics zu fehlen.
sich == dich, oder? NöIch hoffe ich beleidige sich jetzt nicht, aber dir scheinen die Basics zu fehlen.
https://www.elektronik-kompendium.de/sites/net/0901061.htm
https://www.security-insider.de/was-ist-arp-address-resolution-protocol- ...
https://www.fortinet.com/de/resources/cyberglossary/what-is-arp
https://en.wikipedia.org/wiki/Address_Resolution_Protocol
https://blog.it-planet.com/switch-vs-hub-vs-router-wesentliche-unterschi ...
https://www.msxfaq.de/tools/3rdparty/portmirroring.htm
Gruss,
Peter
Mit dem ARP Ablauf in einem L2 Netz hat @Fohnbit schon Recht, das ist korrekt beschrieben!
Was man sich die ganze Zeit fragt ist warum der TO nicht schlicht und einfach einmal einen Wireshark zur Hand nimmt und sich den ARP Prozess beidseitig genau ansiehst?
So klärt man im Handumdrehen wasserdicht ob der ARP Prozess sauber auf beiden Enden abläuft ohne wild herumzuspekulieren!
Sieht man sich dann noch die Mac Adress Forwarding Tabelle der beteiligten Switches an verifiziert man zusätzlich das diese die entsprechenden Endgeräte Mac Adressen kennen und die entsprechenden Forwarding Ports über welche sie diese gelernt haben.
Mit aktueller Firmware kann man zu fast 100% ausschliessen das der Switch ein Problem damit hat, denn so ein gravierender Fehler würde ja erwartungsgemäß dann alle Endgeräte im Netz betreffen!
Diese Annahme geht natürlich davon aus das die IP Adressvergabe saube rund korrekt ist und es z.B. keine Doppelvergabe durch sich überschneidende DHCP Pooladressen mit statischen oder andere grundlegende IP Adressierungsfehler im Netz gibt!
Beispiel eines Bilderbuch ARP Requests und entsprechender Antwort:
Fazit:
Wireshark zur Hand nehmen und dem Problem sinnvoll und strategisch auf den Grund gehen anstatt im freien Fall rumzuraten und zu spekulieren. Ist im Endeffekt zielführender! Kommt ein Administrator auch mit dem gesunden IT Verstand drauf...
Hilfreiche Tips für den Umgang mit dem Kabelhai:
https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.html
https://www.heise.de/ratgeber/LAN-Monitoring-Spiegelports-von-Switches-n ...
Alternativ kann man bei Mikrotik Switches auch den eingebauten Wireshark mit der Torch Funktion nutzen. Genug Tools also um alles sinnvoll und zielführend zu troubleshooten.
Im lokalen Netzwerk findet keine Kommunikation über IP statt.
Nicht ganz richtig, denn auch lokale Geräte benötigen zuallererst einmal ein gültige IP Adresse. Ohne die kann auch ARP nicht laufen. Eine korrekt vergebene IP käme also noch vor a.) ansonsten ist das alles richtig.ob die Mac im Arp Cache ist und bleibt.
Wenn es der Cache ist betrifft es ja einzig nur die Endgeräte sofern das Switchnetz eine dummes, flaches Layer 2 Netz ist.Was man sich die ganze Zeit fragt ist warum der TO nicht schlicht und einfach einmal einen Wireshark zur Hand nimmt und sich den ARP Prozess beidseitig genau ansiehst?
So klärt man im Handumdrehen wasserdicht ob der ARP Prozess sauber auf beiden Enden abläuft ohne wild herumzuspekulieren!
Sieht man sich dann noch die Mac Adress Forwarding Tabelle der beteiligten Switches an verifiziert man zusätzlich das diese die entsprechenden Endgeräte Mac Adressen kennen und die entsprechenden Forwarding Ports über welche sie diese gelernt haben.
Mit aktueller Firmware kann man zu fast 100% ausschliessen das der Switch ein Problem damit hat, denn so ein gravierender Fehler würde ja erwartungsgemäß dann alle Endgeräte im Netz betreffen!
Diese Annahme geht natürlich davon aus das die IP Adressvergabe saube rund korrekt ist und es z.B. keine Doppelvergabe durch sich überschneidende DHCP Pooladressen mit statischen oder andere grundlegende IP Adressierungsfehler im Netz gibt!
Beispiel eines Bilderbuch ARP Requests und entsprechender Antwort:
Wireshark zur Hand nehmen und dem Problem sinnvoll und strategisch auf den Grund gehen anstatt im freien Fall rumzuraten und zu spekulieren. Ist im Endeffekt zielführender! Kommt ein Administrator auch mit dem gesunden IT Verstand drauf...
Hilfreiche Tips für den Umgang mit dem Kabelhai:
https://www.heise.de/ratgeber/Fehler-erschnueffeln-221587.html
https://www.heise.de/ratgeber/LAN-Monitoring-Spiegelports-von-Switches-n ...
Alternativ kann man bei Mikrotik Switches auch den eingebauten Wireshark mit der Torch Funktion nutzen. Genug Tools also um alles sinnvoll und zielführend zu troubleshooten.
Ich frage mich ja immernoch, wie der TO es schaffen will, über Erhernet-Netzwerke (RJ45, 4 bzw. 8 adrig) über Switche hinweg eine RS485-Schnittstelle (2adrig) zu erreichen. Und auch, wie ich einer RS485-Schnittstelle eine IP geben kann.
Das sind doch physisch völlig verschiedene Medien.
@to welche IP versuchst du von wo nach wo zu erreichen?
Pingst du die 19.2.168.1.246?
Das sind doch physisch völlig verschiedene Medien.
@to welche IP versuchst du von wo nach wo zu erreichen?
Pingst du die 19.2.168.1.246?
Versteht man es richtig ist das vermutlich sowas wie ein Gateway. Vergleichbar z.B. mit einem Terminalserver auf dem man ein Telnet ausführt und der dann mit einer seriellen Schnittstelle weiter macht wie es z.B. HIER am Beispiel mit einem RasPi und einer seriellen RS-232 Schnittstelle beschrieben ist.
Hallo!
Ich kann Wireshark bis dato nicht nutzen, da ich (noch) nicht vor Ort bin.
@em-pie Dir sind derartige Gateways nicht bekannt?: https://www.waveshare.com/wiki/RS485_TO_ETH_(B)
Soweit habe ich erstmal alles.
@aqui: wird das ARP Broadcast request nicht mit einem ARP Unicast beantwortet? Die sehe ich ja nicht auf meinem PC, solange ich nicht sniffe oder einen Mirrorport eingerichtet habe
Ich kann Wireshark bis dato nicht nutzen, da ich (noch) nicht vor Ort bin.
@em-pie Dir sind derartige Gateways nicht bekannt?: https://www.waveshare.com/wiki/RS485_TO_ETH_(B)
Soweit habe ich erstmal alles.
@aqui: wird das ARP Broadcast request nicht mit einem ARP Unicast beantwortet? Die sehe ich ja nicht auf meinem PC, solange ich nicht sniffe oder einen Mirrorport eingerichtet habe
Zitat von @Fohnbit:
@em-pie Dir sind derartige Gateways nicht bekannt?: https://www.waveshare.com/wiki/RS485_TO_ETH_(B)
Dass du ein Gateway einsetzt, um von Ethernet auf RS485 umzusetzen, habe ich hier nicht aufgefasst (vielleicht auch überlesen...)@em-pie Dir sind derartige Gateways nicht bekannt?: https://www.waveshare.com/wiki/RS485_TO_ETH_(B)
Ich bin davon ausgegangen, dass du das o. g. BBB hast, bei dem unten ein Ethernet-Interface steckt und oben die 3 Pins für RS485 (Tx, Rx, Schirm) - das BBB quasi dein "Medienkonverter" ist. Und nun versuchst du, die RS485-Seite anzupingen, obwohl das Netzwerkkabel im RJ45-Port mit der IP 192.168.1.246 steckt.
Mit solchen Gateways arbeiten wir hier sehr viel - i. d. R. um von Modbus TCP auf Modbus RTU (RS485/ 232) oder MBus zu wechseln - dabei haben die Gateways (von ADFweb) "nur" eine IP über die sie aus dem Ethernet-Netzwerk erreichbar sind. das RS485/ 232 Interface hat logischerweise keine IP. Eine Software übernimmt dann das Mapping/ Umsetzen der Protokolle.
wird das ARP Broadcast request nicht mit einem ARP Unicast beantwortet?
Das ist richtig und erkennst du ja auch selber am o.a. Wireshark Screenshot! Wenn du den Kabelhai temporär nicht nutzen kannst dann nimmst du halt ein onboard Tool wie das bekannte tcpdump dafür. Auf dem BBB wird ja sicher etwas unixoides werkeln, oder?!
Ein tcpdump -i eth0 arp auf dem BBB erreicht genau das gleiche wie der o.a. Screenshot. Und...du siehst dann auch gleich den Unicast Reply ohne Mirrorport oder Snifferbridge.
Torch oder das Sniffer Tool auf dem Mikrotik kann das auch. Siehe unten...
Mikrotik kann von Haus aus sniffen
Hier mal für schnelle Debuggings auf der Konsole für einen Port/Interface und arp traffic ...
Kann man aber genauso gut auf direkt an eine offene Wireshark instanz "streamen" mit dem Streaming feature, oder auch in eine Datei capturen die du dann vom Mikrotik runterladen und mit Wireshark öffnen kannst.
Lesen und Lernen
Mikrotik - Packet Sniffer
Gruß catrell
Hier mal für schnelle Debuggings auf der Konsole für einen Port/Interface und arp traffic ...
/tool sniffer quick interface=ether3 mac-protocol=arpLesen und Lernen
Mikrotik - Packet Sniffer
Gruß catrell
1Zitat von @Fohnbit:
Man kann wohl den Mikrotik sniffen:
https://tojaj.com/packet-capture-from-mikrotik-to-wireshark/
Man kann wohl den Mikrotik sniffen:
https://tojaj.com/packet-capture-from-mikrotik-to-wireshark/
Zitat von @150940:
Mikrotik kann von Haus aus sniffen
Hier mal für schnelle Debuggings auf der Konsole für einen Port/Interface und arp traffic ...
Mikrotik kann von Haus aus sniffen
Hier mal für schnelle Debuggings auf der Konsole für einen Port/Interface und arp traffic ...
/tool sniffer quick interface=ether3 mac-protocol=arpJa, das ist ja was ich schon erwähnt habe und heute Abend testen werde.
So, bin nun vor Ort, aber das sniffen läuft nicht wie erwartet:
Mikrotik:
192.168.1.181 ist mein PC mit Wireshark
192.168.1.247 das GW
192.168.1.246 der BBB
Wenn ich mit arp -d 192.168.1.247 den eintrag lösche, habe ich genau das Problem:
BBB:
Er kann die MAC von 192.168.1.247 nicht ermitteln.
Mach ich das mit anderen hosts (192.168.1.169) klappt es ohne probleme, das er die MAC ermitellt.
Wireshark zeigt mir die ARP requests vom BBB an:
aber ich sehe keine Kommunikation vom GW (192.168.1.247).
Ich hätte erwartet, das wenn ich vom Windows PC einen Ping sende, ich das im Wireshark sehen sollte.
Ist meine sniffer config am Mikrotik falsch oder klappt das so gar nicht?
Mikrotik:
/tool sniffer print
only-headers: no
memory-limit: 100KiB
memory-scroll: yes
file-name:
file-limit: 1000KiB
streaming-enabled: yes
streaming-server: 192.168.1.181:37008
filter-stream: no
filter-interface: ether5,ether6,ether7,ether8,ether9
filter-mac-address:
filter-src-mac-address:
filter-dst-mac-address:
filter-mac-protocol:
filter-ip-address:
filter-src-ip-address:
filter-dst-ip-address:
filter-ipv6-address:
filter-src-ipv6-address:
filter-dst-ipv6-address:
filter-ip-protocol:
filter-port:
filter-src-port:
filter-dst-port:
filter-vlan:
filter-cpu:
filter-size:
filter-direction: any
filter-operator-between-entries: or
quick-rows: 20
quick-show-frame: no
running: yes192.168.1.247 das GW
192.168.1.246 der BBB
Wenn ich mit arp -d 192.168.1.247 den eintrag lösche, habe ich genau das Problem:
BBB:
arp -d 192.168.1.247
ping 192.168.1.247
PING 192.168.1.247 (192.168.1.247) 56(84) bytes of data.
From 192.168.1.246 icmp_seq=1 Destination Host Unreachable
From 192.168.1.246 icmp_seq=2 Destination Host Unreachable
From 192.168.1.246 icmp_seq=3 Destination Host Unreachable
arp -a
? (192.168.1.1) at 1c:ed:6f:a5:1c:fe [ether] on eth0
? (192.168.1.201) at 1c:ed:6f:a5:1c:fe [ether] on eth0
? (192.168.1.59) at f0:f6:c1:ef:e1:1c [ether] on eth0
? (192.168.1.194) at b8:e9:37:d3:ea:56 [ether] on eth0
? (192.168.1.136) at c4:38:75:b9:93:0f [ether] on eth0
? (192.168.1.42) at e8:b2:fe:a7:75:8f [ether] on eth0
? (192.168.1.131) at d8:af:f1:5d:f2:13 [ether] on eth0
? (192.168.1.252) at d4:01:c3:ef:1c:88 [ether] on eth0
? (192.168.1.135) at 60:5b:30:09:42:66 [ether] on eth0
? (192.168.1.45) at cc:1b:e0:81:1e:7d [ether] on eth0
? (192.168.1.247) at <incomplete> on eth0
? (192.168.1.245) at 60:b6:e1:1a:4f:2e [ether] on eth0
? (192.168.1.36) at bc:30:7d:60:b3:a9 [ether] on eth0
? (192.168.1.188) at d8:61:62:7f:ad:fa [ether] on eth0
? (192.168.1.21) at b4:b2:91:89:d1:22 [ether] on eth0
? (192.168.1.121) at b8:e9:37:d6:37:0c [ether] on eth0
? (192.168.1.169) at c4:38:75:b9:93:0f [ether] on eth0Er kann die MAC von 192.168.1.247 nicht ermitteln.
Mach ich das mit anderen hosts (192.168.1.169) klappt es ohne probleme, das er die MAC ermitellt.
Wireshark zeigt mir die ARP requests vom BBB an:
aber ich sehe keine Kommunikation vom GW (192.168.1.247).
Ich hätte erwartet, das wenn ich vom Windows PC einen Ping sende, ich das im Wireshark sehen sollte.
Ist meine sniffer config am Mikrotik falsch oder klappt das so gar nicht?
Wireshark zeigt mir die ARP requests vom BBB an:
Hast du den Wireshark an einem Port der den Client Anschlussport oder den BBB Port spiegelt??Ohne einen Spiegelport kannst du es natürlich nicht sehen da der Reply ein Unicast ist. Den Request siehst du ja immer, egal wo, da Broadcast und der wird in der L2 Domain überallhin geflutet.
https://www.youtube.com/watch?v=Fn4jEPHYPew
oder alternativ ohne Mirror
https://help.mikrotik.com/docs/spaces/ROS/pages/8323088/Packet+Sniffer
https://mikrotik-blog.com/mikrotik-datenanalyse-mit-wireshark
Auch ohne Holländisch Kenntnisse ist das Mirrorport Setup intuitiv.
Idealerweise spiegelst du den BBB Port (Gateway) auf den Wireshark, denn dort kannst du dann sowohl den eingehenden ARP Request des Clients sehen als auch den Reply des BBB. Wenn der keinen Reply sendet hast du den bösen Buhmann. Wenn der sendet aber es kommt am Client nicht an auch. Letzteres dürfte aber ziemlich unwahrscheinlich sein.
Nur zur Sicherheit nebenbei gefragt: Denn Mikrotik hast du auf dem aktuellsten RouterOS und auch den Bootloader unter System -> Routerboard auf diese gleiche Version upgegradet??
Um den Switch auszuschließen (oder eben nicht):
Stecke das GW direkt ans Laptop und lasse WireShark direkt auf deinem Laptop laufen.
Wenn du hier alle Pakete des GW siehst, ist das Teil schon mal sauber.
Dann musst du dich langsam durch hangeln…
Stecke das GW direkt ans Laptop und lasse WireShark direkt auf deinem Laptop laufen.
Wenn du hier alle Pakete des GW siehst, ist das Teil schon mal sauber.
Dann musst du dich langsam durch hangeln…
Hallo!
Ich habe das so aufgefasst, das ich mit dem Sniffer alle Pakete der Ports bekomme (in/out aller Pakete pro Port). Also wie ein Mirrorport. Da liege ich wohl falsch?
Update habe ich die FW gemacht, ja. Bootloader nicht explizit. Schau ich nochmal an.
Aber ich führe den Fehler nun auch das Linux des BBB zurück. Ein zweiter BBB am Standort hat das selbe Problem.
Das Problem besteht auch, wenn ich einen einfachen 08/15 Switch zwischen stecke.
Daher suche ich nun auf Linux Ebene weiter. Nächste Woche werde ich den BBB mit dem letzten Image flashen. Vielleicht ist es dann behoben
Ich habe das so aufgefasst, das ich mit dem Sniffer alle Pakete der Ports bekomme (in/out aller Pakete pro Port). Also wie ein Mirrorport. Da liege ich wohl falsch?
Update habe ich die FW gemacht, ja. Bootloader nicht explizit. Schau ich nochmal an.
Aber ich führe den Fehler nun auch das Linux des BBB zurück. Ein zweiter BBB am Standort hat das selbe Problem.
Das Problem besteht auch, wenn ich einen einfachen 08/15 Switch zwischen stecke.
Daher suche ich nun auf Linux Ebene weiter. Nächste Woche werde ich den BBB mit dem letzten Image flashen. Vielleicht ist es dann behoben
Bootloader nicht explizit. Schau ich nochmal an.
Ein Fehler! Das sollte immer gemacht werden!Das Problem besteht auch, wenn ich einen einfachen 08/15 Switch zwischen stecke.
Oha, das schliesst dann wie erwartet deine bestehende Switch Infrastruktur aus. Du kannst das ja auch mal querchecken wenn du einen Raspberry Pi aus der Bastelschublade anschliesst. Auch der dürfte fehlerfrei funktionieren. Womit dann klar ist das der BBB der Buhmann ist.Sucht man im Internet (Englisch) nach diesen BBB Problematiken findet man eine Menge Treffer.
ok, du meinst wohl dieses:
Sniffer:
ok, schade. Es wäre schön wenn man physikalisch Unabhängig den kompletten Traffic eines Ports in Wireshark sehen könnte. Jedoch kann ich diese in eine Datei speichern und dann in Wireshark öffnen?
Dann hätte ich die komplette Aufzeichnung aller Pakete zwischen 2 Ports?
Ich würde sehen ob der ARP vom BBB am Port A im Switch ankommt, ob er weiter gesendet wird, aber wohl nicht.
Würde dann aber auch sehen, ob das GW entsprechend antwortet. Ob es am BBB dann ankommt, sehe ich auch nicht.
tcpDump wäre hier in Debian wohl mein Freund. Mal schauen wieviel Zeit ich da noch investiere, bevor ich gleich den BBB neu flashe
Sniffer:
ok, schade. Es wäre schön wenn man physikalisch Unabhängig den kompletten Traffic eines Ports in Wireshark sehen könnte. Jedoch kann ich diese in eine Datei speichern und dann in Wireshark öffnen?
Dann hätte ich die komplette Aufzeichnung aller Pakete zwischen 2 Ports?
Ich würde sehen ob der ARP vom BBB am Port A im Switch ankommt, ob er weiter gesendet wird, aber wohl nicht.
Würde dann aber auch sehen, ob das GW entsprechend antwortet. Ob es am BBB dann ankommt, sehe ich auch nicht.
tcpDump wäre hier in Debian wohl mein Freund. Mal schauen wieviel Zeit ich da noch investiere, bevor ich gleich den BBB neu flashe
Zitat von @Fohnbit:
Es wäre schön wenn man physikalisch Unabhängig den kompletten Traffic eines Ports in Wireshark sehen könnte.
Einfach in Wireshark den Capture Filter auf den DST- Port setzen an den du streamst, schon ist das nur der Traffic der an dich vom Mikrotik gestreamt wird 😉.Es wäre schön wenn man physikalisch Unabhängig den kompletten Traffic eines Ports in Wireshark sehen könnte.
Jedoch kann ich diese in eine Datei speichern und dann in Wireshark öffnen?
Klar einfach nen Dateinamen am Mikrotik definieren und maximale Größe festlegen, danach das File per FTP/SFTP auf deinen Wireshark Rechner kopieren (vorher sniffer stoppen)./tool sniffer set file-name=capture.cap
/tool sniffer set file-limit=10Mok, du meinst wohl dieses:
Richtig! Und wie du ja auch selber siehst hast du prompt vergessen den Bootloader (Current) upzudaten!! 
So ein Mismatch gilt es immer zu vermeiden.
