Wireshark Plugin für S7-Protokoll

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannst ja vielleicht auch nochmal testen ob das erste Byte wirklich konstant 0x01 sein muss, oder ob das der ORG-Kennung aus dem Fetch/Write-Protokoll entspricht. Dann sollte man z.B. mit 0x02 an der Stelle auch Merker lesen können. Komme dieses Jahr zum Testen an keine 400er mehr ran.

Also mit 02 Kommt "Invalid Adress" als Result, also geht nicht! Aber mit dem Füllbyte funzt die anfrage mehrerer Blöcke!

Könntest du mir das Wireshark Plugin auch als 64 Bit Version anhängen? Und kannst du denn dann auch das Füllbyte in der Anfrage auswerten?

 

[Jochen Kühner]

Noch was: In der Antwort ist ein Byte mehr enthalten weißt du denn was es bedeutet?

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also Ich hab die Funktionalität nun mal in meine ToolBox eingebaut, mit der WPF Var Tab hab Ich es getestet! Man muss im Konfigurationsbildschirm aber einen Haken setzten das er diesen RequestTyp nutzt!

 

[Thomas_v2.1]

Das erste Byte in der Antwort ist nochmal ein Return-Code, also 0xff bei Erfolg, z.B. 0x05 wenn die Adresse nicht vorhanden ist. 0x05 habe ich selber auch schon gesehen, hab einfach Online aus der SPS den DB gelöscht und dann steht dort 0x05. Scheint also die gleiche Bedeutung zu haben wie auch im übergeordneten Datenteil, lässt sich im Wireshark Plugin aber nicht implementieren.

Im Anhang die dll als 32 und 64 Bit Version bei denen ich auch das Füllbyte im Parameterteil eingebaut habe. Kannst ja mal ein logfile von so einer Anfrage anhängen.

Ich habe zwischenzeitlich noch ein paar andere Sachen ergänzt, hauptsächlich bei den SZL Anfragen. Die Tage gibts dann auch mal ein offizielles Release.

 

[Jochen Kühner]

Das erste Byte in der Antwort ist nochmal ein Return-Code, also 0xff bei Erfolg, z.B. 0x05 wenn die Adresse nicht vorhanden ist. 0x05 habe ich selber auch schon gesehen, hab einfach Online aus der SPS den DB gelöscht und dann steht dort 0x05. Scheint also die gleiche Bedeutung zu haben wie auch im übergeordneten Datenteil, lässt sich im Wireshark Plugin aber nicht implementieren.

Im Anhang die dll als 32 und 64 Bit Version bei denen ich auch das Füllbyte im Parameterteil eingebaut habe. Kannst ja mal ein logfile von so einer Anfrage anhängen.

Ich habe zwischenzeitlich noch ein paar andere Sachen ergänzt, hauptsächlich bei den SZL Anfragen. Die Tage gibts dann auch mal ein offizielles Release.

Könnte man denn nicht die Transport Size auswerten? und durch diese darauf schließen das es eine antwork auf eine andere anfrage ist? oder kann das 0x09 auch bei der Normalen Anfrage vorkommen?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Könnte man denn nicht die Transport Size auswerten? und durch diese darauf schließen das es eine antwork auf eine andere anfrage ist? oder kann das 0x09 auch bei der Normalen Anfrage vorkommen?

0x09 kann auch normal vorkommen, z.B. wenn du eine Anfrage mit Size-type 0x03 (Char) stellst, antwortet die SPS mit transport-size 0x09. Oder wenn man aus der S7-1200 per symbolischem Zugriff eine Stringvariable liest.

 

[Jochen Kühner]

0x09 kann auch normal vorkommen, z.B. wenn du eine Anfrage mit Size-type 0x03 (Char) stellst, antwortet die SPS mit transport-size 0x09. Oder wenn man aus der S7-1200 per symbolischem Zugriff eine Stringvariable liest.

Ok, danke für die Info... Laufen tuts mal...

 

[Zottel]

Ah alles klar... probiers morgen nochmals... wenns geht push Ich meine geänderte libnodave in meine toolbox, dort hab ich den support auch drinn. Muss nur mal schaun wie Ich das in libnodave mache mit dem 0x00 anhängen, da ich im moment nur eine Funktion zusätzlich habe, mal schaun..

Schau mal in addToWriteRequest, Zeile 609, da wird auch so etwas gemacht.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es ist eine neue s7comm.dll in der Version 0.0.4 verfügbar.

Folgende Erweiterungen / Ergänzungen:
- Ergänzung 1200 symbolischer Zugriff
- SZL ID/Index 0x0131 Index 0x0010 ergänzt
- Bei Variablendiensten die Syntax-Id 0xb0 ergänzt
- SZL partial list extracts ergänzt
- Optimierte Darstellung von SZL ID/Index Anfragen die über mehrere PDU gehen (Fragmentierung)
- Keine Unterscheidung mehr zwischen SZL ID 0x0111 und 0x0011
- Filtermöglichkeiten bei Variablendiensten erweitert
- Für einige SZL IDs die Index-Beschreibungen ergänzt
- SZL ID 0xxy74 ergänzt

Dann habe ich mal getestet wie man das plugin unter Linux übersetzt, und eine Kurzanleitung wie es unter Debian (und wahrscheinlich auch Ubuntu und anderen Debian-basierenden Linuxen) funktionieren sollte.
Die Kurzanleitung liegt unter:
http://sourceforge.net/projects/s7commwireshark/files/

Für das Linux-build ist die letzte Version aus dem SVN zu verwenden.

 

[Thomas_v2.1]

Mir ist grad noch ein Unterschied zwischen dem TIA-Portal V11 und V12 aufgefallen. Wenn man eine HMI-Simulation mit der V11 auf dem PC mit einer S7-1200 gestartet hat, wurden die Daten per LID, CRC usw. wie auch schon rausgefunden über die 0x32er Protokolle (was auch libnodave kann) abgefragt.

Jetzt habe ich das gleiche mal mit der V12 gemacht, und dort läuft das jetzt über die 0x72er Protokolle. Irgendwie werden die Daten auch per Request/Response ausgetauscht, aber in den Datensätzen steckt der LID zwar noch drin, aber der CRC wird (wenn es noch ein CRC ist) dann wieder anders berechnet. Entweder mit einem anderen Generatorpolynom oder nicht nur über den Symbolnamen. Habs noch nicht rausgefunden.

Ich verstehe nicht wieso man bei einem komplett neuen System wieder mit zig verschiedenen Protokollen anfangen musste. Es hätte doch gereicht wenn man Variablen auf eine einzige Weise lesen und schreiben kann. Naja, ich muss das Zeugs ja nicht warten...

 

[Thomas_v2.1]

Gibt noch eine neue Erkenntnis zur Syntax-Id 0xb0 welche WinCC gerne zusammen mit einer S7-400 verwendet.
Damit lassen sich doch mehrere Bereiche in einer PDU auslesen, die Anzahl steht in dem einen Byte was ich erst mit 1 als konstant angenommen habe. So wie es aussieht lassen sich maximal 32 Bytes am Stück lesen, warum auch immer (siehe Screenshot). Diese Adressierungsart scheint bei WinCC7.2 voll in Mode zu sein, dort wird das nur noch verwendet.
Im Antworttelegramm gibt es dann pro Datenblock ein Byte Vorkopf mit dem Return code, das lässt sich in Wireshark aber nicht zerlegen weil dazu in dem Telegramm die Informationen fehlen.

Ich bin ja immer noch skeptisch dass das wie Rainer schrieb zyklische Daten, bzw. Telegramme um Daten auf Änderung abzufragen sind. Mir scheint als werden damit ganz normal wie auch mit der anderen Adressierungsart Daten angefordert und zurückgeschickt, denn in den Telegrammen dich ich aufgezeichnet habe gab es in der SPS garantiert keine Änderung.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann muss Ich meine realisierung in libnodave nochmal umbauen... welche größe zeigt den dieses Byte nun an? Die Anzahl der SubItems? Oder die Byte größe?

Hasst du denn eine Ahnung ob Ich über irgendeine SZL auslesen kann ob denn diese Adressierungsart möglich ist?

Muss auch mal schaun wie Ich das ganze in meine Leseoptimierung einbaue...

 

[Thomas_v2.1]

Ja, die Anzahl der Subitems, kommt direkt nach der Syntax-Id. Ich hab eben schon gesehen dass das in den Screenshot noch fehlt, ich habe noch ein paar Filtermöglichkeiten ergänzt und da ist das Feld unter den Tisch gefallen.
Aber ein relevanter Geschwindigkeitsgewinn ist damit meiner Meinung nach nicht zu erwarten. Für die Anfrage in dem Screenshot hätte auch ein einziger "klassischer" Lesebefehl mit 256 Bytes funktioniert. Einen Unterschied gibt es evtl. bei vielen verschiedenen kleinen Datenbereichen, da die Adressangabe ein paar Bytes weniger hat.
Ich hänge mal ein komplettes Wireshark Log an, von WinCC Start bis Ende - es wird alles über diese Syntax-Id gelesen.

 

[Jochen Kühner]

Ja, die Anzahl der Subitems, kommt direkt nach der Syntax-Id. Ich hab eben schon gesehen dass das in den Screenshot noch fehlt, ich habe noch ein paar Filtermöglichkeiten ergänzt und da ist das Feld unter den Tisch gefallen.
Aber ein relevanter Geschwindigkeitsgewinn ist damit meiner Meinung nach nicht zu erwarten. Für die Anfrage in dem Screenshot hätte auch ein einziger "klassischer" Lesebefehl mit 256 Bytes funktioniert. Einen Unterschied gibt es evtl. bei vielen verschiedenen kleinen Datenbereichen, da die Adressangabe ein paar Bytes weniger hat.
Ich hänge mal ein komplettes Wireshark Log an, von WinCC Start bis Ende - es wird alles über diese Syntax-Id gelesen.

Hast du denn mal versucht mehr als 32 Bytes zu lesen, also selbst, ohne WinCC?

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es können maximal 255 Bytes am Stück gelesen werden (mehr Längenangabe passt nicht in ein Byte).

 

[Jochen Kühner]

Nochmal, gibts ne möglichkeit rauszufinden ob ne CPU das unterstützt? Oder unterstützt das z.B. jede 400er und keine 300er? Dann könnte Ich ja einfach per SZL die MLFB lesen und dann nur bei 400ern verwenden?

 

[Thomas_v2.1]

Nochmal, gibts ne möglichkeit rauszufinden ob ne CPU das unterstützt? Oder unterstützt das z.B. jede 400er und keine 300er? Dann könnte Ich ja einfach per SZL die MLFB lesen und dann nur bei 400ern verwenden?

Funktioniert das bei einer 300er denn nicht? Vielleicht war die Funktion in WinCC auch schon immer vorhanden, und mit ist das bisher nur nicht aufgefallen, weil ich nur selten eine 400er mit Ethernet-CP zum Test da habe.

Wenn es bei einer 300er bei dir nicht funktioniert, könnte man die Inhalte der SZL-Abfragen von WinCC vergleichen. Ich habe hier eine IM151-8 CPU mit der ich mal verglichen habe.
WinCC fragt ab:
1) 0x0424 Index 0x0000
-> imho irrelevant für Kommunikation

2) 0x0131 Index 0x0003
-> Unterschiede nur in den bisher unbekannten Reservebits von funkt_0 und funkt_1. In dem großen Reserveblock am Ende ist auch noch ein Unterschied

3) 0x0131 Index 0x0010
-> In der IM151-8 überhaupt nicht vorhanden

4) 0x132 Index 0x0006
-> Keine Unterschiede

Möglich wäre jetzt, mit meiner ersten Nettoplcsim-Version die SZL Daten in den entsprechenden Bits zu modifizieren und testen wann WinCC auf den anderen Modus umschaltet.
In der Version fehlt aber noch die Antwort auf diesen seltsamen S7CHN -Request, da weiß ich überhaupt nicht wozu das gut sein soll. Vielleicht kann eine S7-300 das auch nicht.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fehlt noch einer:
5) 0x0132 Index 0x004
In dem großen Reserveblock gibt es auch Unterschiede

 

[Jochen Kühner]

Thomas, könntest du auch eine MacOS Version des Plugins compilieren?

 

[Thomas_v2.1]

Thomas, könntest du auch eine MacOS Version des Plugins compilieren?

Von Macs habe ich keine Ahnung, kann nur für Windows und Linux übersetzen.