Modbus TCP Fehlersuche mit Wireshark

Wireshark zeigt Ihnen Byte für Byte, was zwischen Ihrem Client und dem Modbus TCP Gerät wirklich passiert. Mit einer Aufzeichnung und drei Filtern klären Sie in einer Minute, ob Ihre Anfrage falsch ist, ob das Gerät sie verweigert oder ob ein Gateway auf der seriellen Seite hängt. Nach dieser Lektion schneiden Sie gezielt Modbus mit, verknüpfen Anfrage und Antwort über die Transaction-ID und holen alle Exceptions mit einem einzigen Filter heraus.

Nur Modbus-Verkehr aufzeichnen

Setzen Sie den Capture-Filter, bevor Sie auf Start drücken: tcp port 502 schneidet nur Modbus mit und lässt den Rest des Netzwerks liegen. In einem Gebäudenetz landet sonst der gesamte Hintergrundverkehr in der Datei, und genau die vier Frames, um die es geht, gehen darin unter.

Der zweite Punkt ist der Messort. Ein Switch schickt Verkehr nur an die beteiligten Ports, Sie sehen also nichts von einem Gespräch zwischen zwei anderen Geräten. Zeichnen Sie deshalb auf dem Rechner auf, der selbst abfragt, oder richten Sie auf dem Switch einen Mirror-Port ein. In der Gebäudeautomation heißt das: Der Laptop hängt dort, wo sonst der Miniserver oder die SPS steht.

Bevor Sie aufzeichnen, ordnen Sie das Symptom ein.

Was das Paketfenster zeigt

Wireshark zerlegt jedes Modbus-Paket in zwei Ebenen: Modbus/TCP für den MBAP-Header und Modbus für die PDU. Das ist genau der Aufbau aus der Lektion zu Port 502, MBAP-Header und Unit-ID. Hier ist eine Anfrage, die drei Holding-Register ab PDU-Adresse 107 liest, also ab der Datenblattnummer 40108: 00 01 00 00 00 06 FF 03 00 6B 00 03.

Die Antwort im selben Stream lautet 00 01 00 00 00 09 FF 03 06 02 2B 00 00 00 64.

Daraus folgt die Regel: Length zählt die Unit-ID plus die PDU. Von den sieben MBAP-Bytes kopiert der Server sechs unverändert zurück, nur Length rechnet er neu aus. An diesem einen Feld ordnen Sie eine Antwort also schon ein, bevor Sie die PDU aufklappen.

Ein zweites Beispiel, das sich in genau einem Punkt unterscheidet. Existiert das dritte Register nicht, antwortet derselbe Server mit 00 01 00 00 00 03 FF 83 02: Length 0x0003 und der Funktionscode 0x83 statt 0x03, also 0x03 plus 0x80, dahinter ein einziges Byte mit dem Exception-Code 02.

TIDTransaction-ID, koppelt Antwort an Anfrage

PIDProtocol-ID, immer 0

LENLength, Unit-ID plus PDU

UIDUnit-ID, Adresse hinter dem Gateway

FCFunktionscode

DATADaten

Keine CRC: Ethernet und TCP sichern die Integrität

Drei Filter, die Sie immer nutzen

Drei Displayfilter decken die tägliche Fehlersuche ab.

Verwechseln Sie Capture-Filter und Displayfilter nicht. tcp port 502 entscheidet, was überhaupt in die Datei kommt, mbtcp entscheidet, was Sie davon zu sehen bekommen. Was der Capture-Filter weggelassen hat, holen Sie später nicht zurück.

Der dritte Filter ist der wertvollste. modbus.exception_code schrumpft eine lange Aufzeichnung auf die wenigen Frames, in denen ein Gerät inhaltlich abgelehnt hat. Wollen Sie dagegen erst wissen, welche IP-Adressen und Unit-IDs überhaupt antworten, ist ein Scan des Modbus-Netzwerks das passendere Werkzeug. Die Bedeutung der einzelnen Felder schlagen Sie in der Übersicht zu Modbus TCP nach.

Anfrage und Antwort verknüpfen

mbtcp.trans_id == 5 zeigt eine Transaktion vollständig, denn der Server kopiert die Transaction-ID der Anfrage in die Antwort. Klicken Sie eine Anfrage an, lesen Sie die Nummer ab, setzen Sie sie in den Filter: Sie sehen danach entweder zwei Frames oder eines.

Bleibt es bei einem Frame, kam keine Antwort. Sind es zwei, liegt aber eine Sekunde in der Zeitspalte dazwischen, war es kein Ausfall, sondern eine Laufzeit oberhalb Ihres Timeouts. Das braucht eine andere Lösung: einen längeren Timeout oder ein ruhigeres Poll-Intervall.

Ein Sonderfall, den nur eine Aufzeichnung sichtbar macht: Schickt ein Client versehentlich etwas anderes als 0 in der Protocol-ID, verwirft der Server die Anfrage stillschweigend, ohne Exception. Sie sehen die Anfrage abgehen und danach nichts.

Den Dissector an einen anderen Port hängen

Wireshark koppelt den Modbus/TCP-Dissector ab Werk an Port 502. Auf jedem anderen Port sehen Sie nur nacktes TCP, und mbtcp findet nichts.

Rechtsklick auf ein Paket, dann Decode As, in der Zeile den TCP-Port eintragen und als aktuellen Wert Modbus/TCP wählen. Ab diesem Moment greifen alle Modbus-Filter auch dort.

Sie brauchen das öfter, als Sie denken. Der Simulator aus der Lektion Modbus TCP mit einem Simulator üben läuft auf Port 5020, und SolarEdge-Geräte mit SetApp hören ab Werk auf 1502. Die Spezifikation erlaubt einen abweichenden Port ausdrücklich, verlangt aber, dass 502 zusätzlich erreichbar bleibt. Nicht jeder Hersteller hält sich daran.

Was eine Aufzeichnung über das Gateway verrät

Zwei Exception-Codes verraten Ihnen, dass Sie mit einem Gateway sprechen und nicht mit dem Endgerät. Exception 10 (0x0A, Gateway Path Unavailable) heißt, dass das Gateway selbst falsch konfiguriert oder überlastet ist. Exception 11 (0x0B, Gateway Target Device Failed To Respond) heißt, dass das Gateway Ihre Anfrage auf die serielle Seite weitergereicht hat und dort niemand geantwortet hat.

Das ist eine gute Nachricht. Netzwerk, Firewall und Client sind damit erledigt, und die Suche wandert hinter das Gateway: Unit-ID, Serveradresse, Baudrate, Parität, Verdrahtung. Wie Sie beide Seiten abgleichen, steht in der Anleitung zum Einrichten eines Modbus TCP Gateways.

Viele Gateways lassen Sie in genau diesem Fall allerdings in den Timeout laufen, statt 0x0B zu senden. Dann sagt die Zeitspalte mehr als der Inhalt: Eine Exception nach der eingestellten seriellen Wartezeit zeigt auf die RS485-Seite, gar keine Antwort auf das Gateway selbst.

Wann Wireshark nicht weiterhilft

Auf RS485 sehen Sie nichts, denn Wireshark liest von Netzwerkschnittstellen, und ein serieller Bus ist keine. Es gibt Umwege über eine Bridge, im Alltag greifen Sie dort aber zur Abfragestatistik Ihres Clients und zu den Diagnosezählern von FC08, so wie in der Lektion zur Modbus RTU Fehlersuche.

Zwei weitere Grenzen gehören dazu. Eine Aufzeichnung zeigt Ihnen, dass ein Register den Wert 555 enthält, aber nicht, ob daraus 55,5 Ampere oder 5550 Watt werden. Und läuft die Verbindung als Modbus/TCP Security über Port 802, sehen Sie nur verschlüsselte TLS-Records und keine PDU mehr.

Dazu kommt eine praktische Grenze: auf einem verwalteten Arbeitsplatz dürfen oder können Sie Wireshark nicht immer installieren. Der Protocol Analyzer in ModbusCloud Diagnostics zeigt dann die Frames der eigenen Verbindung, farbig nach Bestandteil und mit einem Zähler für Transaktionen und Fehler. Um den Verkehr eines anderen Clients mitzulesen, brauchen Sie weiterhin Wireshark und einen Mirror-Port.

Häufige Fehler

Ohne Capture-Filter starten. In einem belebten Netz füllt sich die Datei in Minuten mit Verkehr, der Sie nichts angeht, und die Suche nach Ihren vier Frames dauert länger als die Fehlersuche selbst. Setzen Sie tcp port 502 vor dem Start.

Denken, dass Wireshark den Simulator nicht sieht. Auf Port 5020 hängt kein Dissector, also erscheint nur TCP. Das sieht aus, als käme kein Modbus an, obwohl jedes Byte in der Datei steht. Decode As löst das in zehn Sekunden.

An einem normalen Switchport messen. Ein Switch leitet Verkehr nur an die beteiligten Ports weiter, Sie sehen also gar nichts und schließen daraus fälschlich auf ein totes Gerät. Messen Sie auf dem abfragenden Rechner oder auf einem Mirror-Port.

Eine fehlende Antwort sofort als Netzwerkproblem behandeln. Geht die Anfrage sichtbar raus und kommt nichts zurück, prüfen Sie zuerst Unit-ID und Verbindungslimit. Manche Geräte lassen nur eine Verbindung zu, und ein zweiter Client wirft Ihren ersten heraus, ohne dass jemand eine Fehlermeldung sieht.

Selbst ausprobieren

1. 1

   Simulator starten

   pymodbus.simulator --modbus_server server --modbus_device device startet einen Modbus TCP Server auf Port 5020. pymodbus steht unter der BSD-3-Lizenz und ist frei nutzbar, auch geschäftlich.

2. 2

   Aufzeichnung starten

   Wireshark auf der Loopback-Schnittstelle, Capture-Filter tcp port 5020. Kontrolle: Die Paketliste bleibt leer, solange niemand abfragt.

3. 3

   Ein Register lesen und den Dissector koppeln

   Lesen Sie mit Ihrem Client ein Holding-Register. Sehen Sie nur TCP, dann Rechtsklick auf ein Paket, Decode As, TCP-Port 5020 auf Modbus/TCP legen.

4. 4

   Die sieben MBAP-Bytes benennen

   Klappen Sie die Anfrage auf und ordnen Sie Transaction-ID, Protocol-ID, Length und Unit-ID zu. Notieren Sie die Transaction-ID.

5. 5

   Anfrage und Antwort zusammenholen

   Displayfilter mbtcp.trans_id == plus Ihre Nummer. Erwartung: genau zwei Frames, und in der Antwort ist Length um Byte Count und Registerwerte größer als in der Anfrage.

6. 6

   Eine Exception provozieren

   Fragen Sie eine Startadresse weit außerhalb der Registertabelle ab, etwa PDU-Adresse 60000. Filter modbus.exception_code. Erwartung: ein einzelnes kurzes Frame.

7. 7

   Die beiden Antworten vergleichen

   Halten Sie das Feld Length nebeneinander. Die Exception steht auf 0x0003, die gelungene Antwort deutlich darüber. Rechnen Sie zur Kontrolle nach: Length minus 1 ergibt die Anzahl der PDU-Bytes.

Mit echter Hardware. Ersetzen Sie 5020 durch 502 und messen Sie auf dem abfragenden Rechner oder auf einem Mirror-Port Ihres Switches. Hängt ein Gateway davor, klemmen Sie zusätzlich eine Ader der RS485-Seite ab und wiederholen Schritt 6. Erwartung: statt Exception 02 kommt jetzt Exception 11, oder es kommt gar nichts mehr.

Erwartetes Ergebnis: eine Aufzeichnung mit einer gelungenen Transaktion und einer Exception, jede mit einem eigenen Filter wiedergefunden.

Zusammenfassung

• Ein Capture-Filter wie tcp port 502 entscheidet vor dem Start, ob Ihre Aufzeichnung lesbar bleibt, denn was er weglässt, ist unwiederbringlich weg.
• Wireshark zeigt MBAP-Header und PDU als zwei getrennte Ebenen, und das Feld Length verrät die Art der Antwort, bevor Sie die PDU aufklappen.
• Der Filter mbtcp.trans_id holt Anfrage und Antwort zusammen und trennt damit eine fehlende Antwort von einer zu langsamen.
• Der Modbus-Dissector hängt ab Werk nur an Port 502, deshalb brauchen Sie Decode As für den Simulator auf 5020 und für Geräte auf abweichenden Ports.
• Die Exception-Codes 0A und 0B kommen vom Gateway und beweisen, dass das Problem dahinter auf der seriellen Seite liegt.