fohnbit
Goto Top

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!

Content-ID: 669471

Url: https://administrator.de/contentid/669471

Printed on: December 14, 2024 at 15:12 o'clock

150631
150631 Nov 13, 2024 at 17:58:51 (UTC)
Goto Top
ARP geht ins leere?
Heißt die Switches kennen die Mac nicht mehr und dann auf einmal doch wieder?
Fohnbit
Fohnbit Nov 13, 2024 updated at 18:09:44 (UTC)
Goto Top
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
DivideByZero
DivideByZero Nov 13, 2024 at 18:15:25 (UTC)
Goto Top
Moin,

Wenn ich das nächste mal vor Ort bin, versuche ich am Switch einige Tests.
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
150631
150631 Nov 13, 2024 at 18:48:35 (UTC)
Goto Top
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.
em-pie
em-pie Nov 13, 2024 at 19:00:13 (UTC)
Goto Top
Moin,

Eckdaten:
. - 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?
Fohnbit
Fohnbit Nov 13, 2024 at 19:08:39 (UTC)
Goto Top
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


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 WaveShare
Fohnbit
Fohnbit Nov 13, 2024 at 19:09:29 (UTC)
Goto Top
Zitat von @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.

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.
Pjordorf
Pjordorf Nov 13, 2024 at 19:13:35 (UTC)
Goto Top
Hallo,

Zitat von @Fohnbit:
Am BBB konnte ich die IP nimmer pingen.
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
Fohnbit
Fohnbit Nov 13, 2024 at 19:17:50 (UTC)
Goto Top
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:
  • Der BBB sendet kein ARP
  • Der Mikrotik blockiert die ARP
  • das RS485 GW antwortet nicht auf die ARP
Fohnbit
Fohnbit Nov 13, 2024 at 19:21:27 (UTC)
Goto Top
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.

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 face-smile
150631
150631 Nov 13, 2024 at 19:27:33 (UTC)
Goto Top
🤷🫣
Fohnbit
Fohnbit Nov 13, 2024 at 19:31:06 (UTC)
Goto Top
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?


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.
Fohnbit
Fohnbit Nov 13, 2024 at 19:44:42 (UTC)
Goto Top
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?
Pjordorf
Pjordorf Nov 13, 2024 at 20:26:31 (UTC)
Goto Top
Hallo,

Zitat von @Fohnbit:
Grundsätzlich wäre es praktisch zu wissen, wo die ARP Auflösung scheitert.
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 Hub
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 ...

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 dir

Ich 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
Fohnbit
Fohnbit Nov 13, 2024 at 20:44:03 (UTC)
Goto Top
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.

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
Fohnbit
Fohnbit Nov 13, 2024 at 20:45:32 (UTC)
Goto Top
Zitat von @Pjordorf:
Was genau ist als Antwort gekommen?

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
Fohnbit
Fohnbit Nov 13, 2024 at 20:53:30 (UTC)
Goto Top
Zitat von @Pjordorf:
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 Hub
Musst 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!
aqui
aqui Nov 14, 2024 updated at 07:36:55 (UTC)
Goto Top
Mit dem ARP Ablauf in einem L2 Netz hat @Fohnbit schon Recht, das ist korrekt beschrieben!
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:
arp
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... face-wink
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.
em-pie
em-pie Nov 14, 2024 updated at 07:33:30 (UTC)
Goto Top
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?
aqui
aqui Nov 14, 2024 at 07:40:06 (UTC)
Goto Top
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.
Fohnbit
Fohnbit Nov 14, 2024 at 07:53:13 (UTC)
Goto Top
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
em-pie
em-pie Nov 14, 2024 at 08:05:01 (UTC)
Goto Top
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...)
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.
aqui
aqui Nov 14, 2024 updated at 08:34:23 (UTC)
Goto Top
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! face-wink
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. face-wink
Torch oder das Sniffer Tool auf dem Mikrotik kann das auch. Siehe unten...
150940
150940 Nov 14, 2024 updated at 08:35:22 (UTC)
Goto Top
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=arp
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
Fohnbit
Fohnbit Nov 14, 2024 at 12:38:32 (UTC)
Goto Top
Zitat von @Fohnbit:

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 ...
/tool sniffer quick interface=ether3 mac-protocol=arp

Ja, das ist ja was ich schon erwähnt habe und heute Abend testen werde.
Fohnbit
Fohnbit Nov 14, 2024 at 16:13:53 (UTC)
Goto Top
So, bin nun vor Ort, aber das sniffen läuft nicht wie erwartet:
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: yes
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:
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 eth0

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:
2024-11-14 17_07_53-aufzeichnen von wlan

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?
aqui
aqui Nov 14, 2024 updated at 17:00:32 (UTC)
Goto Top
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. face-wink

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??
em-pie
em-pie Nov 14, 2024 at 16:56:20 (UTC)
Goto Top
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…
Fohnbit
Fohnbit Nov 14, 2024 updated at 18:46:19 (UTC)
Goto Top
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
aqui
aqui Nov 15, 2024 at 08:12:19 (UTC)
Goto Top
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.
Fohnbit
Fohnbit Nov 15, 2024 at 13:05:06 (UTC)
Goto Top
ok, du meinst wohl dieses:
2024-11-15 13_59_54-admin@192.168.1.252 (sw3) - winbox (64bit) v7.16.1 on crs328-24p-4s+ (arm)

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 face-smile
150940
150940 Nov 15, 2024 updated at 13:32:18 (UTC)
Goto Top
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 😉.
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=10M
Außerdem kannst du den Filter auf das MAC-Protokoll "ARP" setzen wenn dich nur die Pakete interessieren dann zeichnet du nichts unnötiges auf.
aqui
aqui Nov 15, 2024 updated at 13:53:38 (UTC)
Goto Top
ok, du meinst wohl dieses:
Richtig! Und wie du ja auch selber siehst hast du prompt vergessen den Bootloader (Current) upzudaten!! face-sad
So ein Mismatch gilt es immer zu vermeiden.