Wireshark Plugin für S7-Protokoll

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hats du denn auch was Rausgefunden wie das ganze begrenzt ist? Gibts bei der 1200er wieder eine maximale PDU Größe? Anfragen an verschachtelte Variablen in DBs werden durch diese Aneinanderreihung ja schon ziemlich lang...

Aus dem Grunde musste wohl die Schachtelungstiefe bei der Programmierung begrenzt werden. Es ist eine maximale Schachtelungstiefe von 8 erlaubt, dann lässt sich das Programm nicht mehr übersetzen. Eine Variablenspezifikation benötigt dann 42 bzw. 44 Bytes.

Ich habe auch schonmal ein paar andere Versuche gemacht:
Bei Zugriffe auf Array-Variablen kann man den Array-Index ändern ohne die CRC anpassen zu müssen. Aber man kann nicht über den letzten Array-Index hinaus lesen, das wird dann wohl doch in der SPS irgendwie abgefragt. Man kann ohne Probleme libnodave durch diese Adressierung erweitern, man benötigt lediglich die Nummern aus dem TIA-Projekt. Und in libnodave müssen noch die restlichen Transport-Size Angaben wie z.B. 5 für Integer ergänzt werden.

 

[Jochen Kühner]

Aus dem Grunde musste wohl die Schachtelungstiefe bei der Programmierung begrenzt werden. Es ist eine maximale Schachtelungstiefe von 8 erlaubt, dann lässt sich das Programm nicht mehr übersetzen. Eine Variablenspezifikation benötigt dann 42 bzw. 44 Bytes.

Ich habe auch schonmal ein paar andere Versuche gemacht:
Bei Zugriffe auf Array-Variablen kann man den Array-Index ändern ohne die CRC anpassen zu müssen. Aber man kann nicht über den letzten Array-Index hinaus lesen, das wird dann wohl doch in der SPS irgendwie abgefragt. Man kann ohne Probleme libnodave durch diese Adressierung erweitern, man benötigt lediglich die Nummern aus dem TIA-Projekt. Und in libnodave müssen noch die restlichen Transport-Size Angaben wie z.B. 5 für Integer ergänzt werden.

Und wie groß ist die pdu size bei der 1200er? D.h. für eine große visu ist der symboblische db zugriff wohl nichts, da man ja damit auch keine anfragen zusamenfassen kann.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die PDU Größe bei einer 1200 sind 240 Byte. Wobei WinCCflexible auch keine Variablen gepackt hat, und das hat bisher auch niemanden gestört
Ich kann mir auch vorstellen kann dass die 1200er künstlich eingeschränkt wurde, damit man einen Grund hat auf die größeren Steuerungen zu wechseln.

 

[Jochen Kühner]

Ja, aber mit flexible hat man ja auch keine großen Visus gemacht. ;-)

 

[Jochen Kühner]

Laos ich finde das mit der je Schachtelungstiefe angehängten Bytes schon ein bischen doof. Wenn man nun von einem DB aus Schachtelungstiefe 2 Werte abfrägt, können auf einmal in einer PDU nur noch maximal 10 Werte statts vorher 17 (bei absoluter Adressierung) in einer PDU übertragen werden. Das kann dann schon schön auf die Performance einer Visu drücken, und das sollte man beim projektieren auf jeden Fall beachten!

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe mal eine neue Version der s7comm.dll veröffentlicht.

Änderungen in der Version 0.0.3
- Bezeichnungen im Kopfteil entsprechend den des Sinec AP Protokolls angepasst. Dürfte den originalen Bezeichnungen am nächsten kommen.
- Bausteindienste entspechend den Bezeichnungen der 840 Dokumentation angepasst
- Diagnosetelegramme (Anfragen Typ 1) beim Baustein beobachten werden aufgeschlüsselt
- Support für Telegramme S71200 symbolisch
- einige SZL IDs/Indexe ergänzt

Download unter:
http://sourceforge.net/projects/s7commwireshark/

Es ist auch eine dll für die 64 Bit Version von Wireshark verfügbar.

 

[Jochen Kühner]

- Diagnosetelegramme (Anfragen Typ 1) beim Baustein beobachten werden aufgeschlüsselt

Zu den Diagnsetelegrammen, hast du da noch weitere Infos, welche ich noch nicht in meiner DLL habe, wo Ich vielleicht noch was verbessern muß?

 

[Thomas_v2.1]

Nein, ich habe meine Analysen der Diagnosetelegramme auch nicht abgeschlossen.
Und ich habe auch noch nicht alles das was du in deinem Programm hast übernommen.
Mehr oder neues ist auf jeden Fall nicht drin. Ich wollte aber mal einen Zwischenstand
veröffentlichen, weil ich da nicht immer kontinuierlich dran weiterarbeite sondern nur
wenn ich mal Lust darauf habe ;-)

Wenn ich das richtig verstanden habe, lässt sich der Aufbau der Antwort auf eine
Baustein-Beobachten Anfrage auch nur auswerten wenn man die Anfrage kennt.
Das lässt sich mit den Wireshark Plugin glaube ich nicht erledigen - zumindest weiß ich
noch nicht wie das gehen könnte.

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich das richtig verstanden habe, lässt sich der Aufbau der Antwort auf eine
Baustein-Beobachten Anfrage auch nur auswerten wenn man die Anfrage kennt.
Das lässt sich mit den Wireshark Plugin glaube ich nicht erledigen - zumindest weiß ich
noch nicht wie das gehen könnte.

Jo, das ist aber auf jeden Fall so! Mann muss sich immer merken was man für eine bestimmte Codezeile angefragt hatte...

 

[Jochen Kühner]

Bei einer Zeile mit einem Call kann man ja auch noch Werte driekt abfragen, d.h. ein DB, MW, ... auslesen. Das hab Ich bei mir auch noch nicht implementiert. Wie es funktioniert hab Ich zwar analysiert, aber implementiert ist da noch nichts ;-)

 

[MW]

Ich hätte da mal ne Zwischenfrage:

Ich versuche momentan aus dem Datenverkehr zwischen einer CPU und mehreren TP's ein Schreibbefehl für ein Bit aufzuzeichnen, weil gerade dieses Bit scheinbar durch eines der TP's zur falschen Zeit gesetzt wird bzw. nicht zurückgesetzt wird und ich nicht genau sagen kann, von welchem nun es kommt.
Ich kann ja die aufgezeichneten Telegramme genau auf dieses Bit filtern, dass klappt dank dem Plugin ganz gut.

Jetzt ich würde es aber noch viel schöner finden wenn auch schon beim Capture nur Telegramme aufzeichnen könnte die z.B. einen Schreibauftrag in einen bestimmten DB enthalten.
Geht das irgendwie ?

 

[Jochen Kühner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hätte da mal ne Zwischenfrage:

Ich versuche momentan aus dem Datenverkehr zwischen einer CPU und mehreren TP's ein Schreibbefehl für ein Bit aufzuzeichnen, weil gerade dieses Bit scheinbar durch eines der TP's zur falschen Zeit gesetzt wird bzw. nicht zurückgesetzt wird und ich nicht genau sagen kann, von welchem nun es kommt.
Ich kann ja die aufgezeichneten Telegramme genau auf dieses Bit filtern, dass klappt dank dem Plugin ganz gut.

Jetzt ich würde es aber noch viel schöner finden wenn auch schon beim Capture nur Telegramme aufzeichnen könnte die z.B. einen Schreibauftrag in einen bestimmten DB enthalten.
Geht das irgendwie ?

Den gleichen filter welchen du zum anzeigen verwendest, solltest du auch für das aufzeichenen verwenden können. Einfach in den optionen des netzwerkadapters festlegen, in Wireshark

 

[Thomas_v2.1]

Jetzt ich würde es aber noch viel schöner finden wenn auch schon beim Capture nur Telegramme aufzeichnen könnte die z.B. einen Schreibauftrag in einen bestimmten DB enthalten.
Geht das irgendwie ?

Es gibt sog. Capture Filter die schon bei der Aufzeichnung der Daten wirken. Diese Filter haben allerdings eine andere Syntax als die Wireshark Display Filter, da diese auf die Bibliothek libpcap, welche Wireshark zum Abgreifen der Netzwerkdaten verwendet, wirken. Vor allem kennt diese Bibliothek nicht die Protokolle die Wireshark kennt.
Darum ist leider bei der Aufzeichnung kein Filter für s7comm möglich.

Sinnvolle Filter bei der S7 Kommunikation sind z.B. "port 102", oder um nur die Kommunikation zu oder von einer IP-Adresse zu filtern mit "host x.x.x.x".
Dann hat man die Datenmenge bei einer Langzeitaufzeichnung schonmal erheblich reduziert.
Dazu in den Capture Options auf das Interface welches überwacht werden soll doppelklicken, und dort unter "Capture Filter" entweder einen vorher abgespeicherten auswählen oder direkt dort eintragen.

Man kann bei Wireshark auch diverse Aufzeichnungsoptionen einstellen, beispielsweise alle x Megabyte eine neue Datei anlegen, oder alle x Stunden. Wenn man später den ungefähren Zeitpunkt eines Fehlers kennt, kann man sich die passende Logdatei laden und dort suchen.

 

[Jochen Kühner]

Es gibt sog. Capture Filter die schon bei der Aufzeichnung der Daten wirken. Diese Filter haben allerdings eine andere Syntax als die Wireshark Display Filter, da diese auf die Bibliothek libpcap, welche Wireshark zum Abgreifen der Netzwerkdaten verwendet, wirken. Vor allem kennt diese Bibliothek nicht die Protokolle die Wireshark kennt.
Darum ist leider bei der Aufzeichnung kein Filter für s7comm möglich.

Sinnvolle Filter bei der S7 Kommunikation sind z.B. "port 102", oder um nur die Kommunikation zu oder von einer IP-Adresse zu filtern mit "host x.x.x.x".
Dann hat man die Datenmenge bei einer Langzeitaufzeichnung schonmal erheblich reduziert.
Dazu in den Capture Options auf das Interface welches überwacht werden soll doppelklicken, und dort unter "Capture Filter" entweder einen vorher abgespeicherten auswählen oder direkt dort eintragen.

Man kann bei Wireshark auch diverse Aufzeichnungsoptionen einstellen, beispielsweise alle x Megabyte eine neue Datei anlegen, oder alle x Stunden. Wenn man später den ungefähren Zeitpunkt eines Fehlers kennt, kann man sich die passende Logdatei laden und dort suchen.

Ah ok, ich dachte die Syntax wäre gleich. Hab die nie wirklich verwendet! Wieder was gelernt!

 

[MW]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt sog. Capture Filter die schon bei der Aufzeichnung der Daten wirken. Diese Filter haben allerdings eine andere Syntax als die Wireshark Display Filter, da diese auf die Bibliothek libpcap, welche Wireshark zum Abgreifen der Netzwerkdaten verwendet, wirken. Vor allem kennt diese Bibliothek nicht die Protokolle die Wireshark kennt.
Darum ist leider bei der Aufzeichnung kein Filter für s7comm möglich.

Ich hab das schon befürchtet, ich hatte nämlich schon einige Filterbefehle erfolglos durchprobiert, aber wenn es sowieso nicht möglich ist, war ich zumindest nicht zu blöd beim eintippen.

Sinnvolle Filter bei der S7 Kommunikation sind z.B. "port 102", oder um nur die Kommunikation zu oder von einer IP-Adresse zu filtern mit "host x.x.x.x".
Dann hat man die Datenmenge bei einer Langzeitaufzeichnung schonmal erheblich reduziert.
Dazu in den Capture Options auf das Interface welches überwacht werden soll doppelklicken, und dort unter "Capture Filter" entweder einen vorher abgespeicherten auswählen oder direkt dort eintragen.

Ich filtere beim capture schon nach dem destination host, port 102 und ether proto 0x0800. Das macht in meinem Fall in einer Stunde ein Capture von ca. 100MB.
Leider ist wireshark übers Wochenende beim aufzeichnen abgestürzt, trotz splittung der Capturedateien auf 100MB und Ringspeicher mit 30 Dateien, mal schauen ob es morgen früh noch läuft.

 

[Thomas_v2.1]

Ich habe mal für die 72er Telegramme vom TIA-Portal einen Test-Disssector gebaut. Im Anhang die dll für die 32-Bit Wireshark Version.
Filtern lassen sich diese Telegramme über "s7commt".

Der grundlegende Aufbau dieser Telegramme scheint Kopf-, Daten- und Fußteil zu sein. Für Telegramme die größer als die ISO-Paketlänge sind nutzt man nicht die dort vorhandene Möglichkeit zur Fragmentierung, sondern eine eigene im TIA-S7-Protokoll. D.h. bei fragmentierten Telegrammen entfällt der Fuß-Teil.
Was im Datenteil enthalten ist wird nicht entschlüsselt. Viele Funktionen werden aber wohl nicht binär sondern als Text, oder Text und Binärwert übermittelt.

Ich habe hier zu Hause eine 1200er CPU. Für die 1500er habe ich nur die Aufzeichnung aus dem anderen Thread mit der Variablentabelle. Demnach scheint die Kommunikation zur 1200 und 1500 zumindest "ähnlich" zu sein.

Die Kommunikation scheint aber auf hohe Bandbreite ausgelegt zu sein. Zumindest bei der 1200er wird beim Übertragen nur eines OB1 mit einem Netzwerk eine nicht unerhebliche Datenmenge hin- und hergeschickt. Auch wenn man eine Variablentabelle aufmacht und nur einen Wert beobachten will, wird immer gleich das ganze Programm abgeglichen.

 

[ober]

Hallo Thomas,

Wirst du den Quellcode der aktuellen Version deines Wireshark Plugins auch Posten?
Unter Linux kann ich die dlls leider nicht benutzen.

Leibe Grüße
Ober

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Ober,
der aktuellste Stand liegt immer bei Sourceforge im SVN repository (trunk/src/s7comm).

Kannst ja mal von deinen Erfahrungen berichten, ob und wie das unter Linux geklappt hat.

 

[Thomas_v2.1]

Als ich heute WinCC V7.2 mit einer 416 und Ethernet-CP verbunden und da etwas mitgelauscht habe, ist mir eine bisher unbekannte Adressierungsart aufgefallen.
Die meistbenutzte Adressierung ist die über den 10 Byte langen S7-Anypointer mit Syntax Id 0x10.

Ich habe in einem Testprojekt nur zwei Variablen gehabt, eine auf DB50.DBD0 und DB55.DBD0 adressiert. Nun hat WinCC diese Variablen anders aus der SPS gelesen, und zwar über eine Adresse mit Syntax Id 0xb0 und einer folgenden Adressangabe mit 7 Bytes Länge, also inkl. Vorkopf 9 Bytes.

Wahrscheinlicher Aufbau:
1: 0x12 // Varspec
2: 0x07 // Länge
3: 0xb0 // Sytax Id

4: 0x01 // Size-Type???

5: 0x04 // Anzahl

6: 0x00 // DB-Nummer
7: 0x37

8: 0x00 // Offset
9: 0x00

Eigentlich wollte ich das an einer 300er CPU weiter erforschen, musste aber feststellen dass diese mit den Daten nichts anfangen kann. D.h. das ist etwas 400er spezifisches.
Ich sehe das bei der WinCC Version auch das erste mal. Diese Adressierungsart spart gegenüber der anderen 3 Byte pro Datenbereich ein, bei gestückelten Datenbereichen könnte man z.B. bei einer 240er PDU 25 anstelle 19 Bereiche in einer PDU lesen.

Hat einer eine Ahnung was das ist, bzw. wie Siemens das nennt?

 

[Jochen Kühner]

Ich hab im Geschäft auch noch ein paar 400er könnte noch probieren ob das bei diesen auch funzt! Vielleicht steht die Unterstützung dieser Adressierung auch wieder in einer SZL (so wie die Unterstützung der 2 versch. Statusanfragen).