Wireshark Plugin für S7-Protokoll

Zuviel Werbung?
-> Hier kostenlos registrieren
Ich werds am Freitag mal noch mit verschiedenen CPUs testen und auch mit verschiedenen Werten für den von dir geschätzten Size Type Parameter...
Hab das ganze auch schonmal in meine modifizierte libnodave gebaut... muss aber erst am Fr testen, und dann mal schaun wie Ich das in meine Leseoptimierung in der .net Bibliothek einbauen kann, aber erst muss ich mal noch rausfinden wie man feststellen kann ob das protokoll unterstützt ist...
 
In der SZL xy31 INDEX 2 steht ja z:b. das 7te Bit für das mögliche Statustelegram und laut der Doku ist das ja Reserviert... Man bräuchte mal ne neuere Doku der SZLs...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Thomas_v2.1 schrieb:
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?
Anhang anzeigen 22612
Zum Vergrößern anklicken....
Ist zyklisches Lesen bei Änderung. Funktioniert nur bei DB-Operanden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Rainer Hönle schrieb:
Ist zyklisches Lesen bei Änderung. Funktioniert nur bei DB-Operanden.
Zum Vergrößern anklicken....

Heist das dann eines der Bits der SZL 0x131 Index 3 sagt aus ob es Funktioniert ? (in funkt 0 gibts ja die Bits "2=Initialize Cyclic Reading (start implicitely)","3=Initialize Cyclic Reading (start explicitly)","4=start cyclic reading")
 
Zuletzt bearbeitet:
Ich habe gerade mal ein Logfile mit WinCC7.0 wo die "echten" zyklischen Dienste verwendet werden, mit einem Logfile einer CPU mit diesem Spezialtelegramm verglichen.
Bei SZL 0x131 Index 3 ist bei funkt_0 im Bit 7 wirklich ein Unterschied. Bei der CPU welche jetzt dieses Spezialtelegramm kann ist das auf True, bei der anderen auf False. Bei funkt_1 sind aber auch noch die ersten beiden Reservebits 1 und 2 auf True.

In den Siemens Dokus die mir vorliegen steht an den Stellen leider überall Reserve. Vlt. hat noch jemand ein Handbuch in dem das erläutert war (die Anzahl der Informationen wurde immer mal wieder geändert).

WinCC 7.2 schiebt dem Ganzen jetzt noch eine SZL Abfrage auf 132/4 vorweg, dort verbergen sich im Reserve-Teil auch noch viele Daten (sind nicht alle Null).

Ich habe auch noch keine Idee wie ich diese Anfrage bezeichnen soll, wirklich zyklisch ist es nicht.
 
Zuletzt bearbeitet:
Auch auf die Gefahr hin, dass Du mir wieder nicht glaubst: es handelt sich um ein zyklisches Lesen bei Änderung. Wenn Du nichts zyklisches siehts, dann gab es an dem Operanden keine Änderung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gut, ich sehe natürlich nicht was da im Hintergrund noch abläuft.
Ich sehe nur dass WinCC die Variablen über diese Syntax-Id im eingestellten Zyklus (z.B. 2s) pollt, also alle 2 Sekunden Anfrage- und Antworttelegramm. Im Prinzip genauso wie wenn WinCC die Daten über die Syntax-Id 0x10 lesen würde. Im Anworttelegramm bei Syntax-Id 0xb0 ist den Daten noch ein 0xff vorangestellt.

Zumindest habe ich festgestellt, dass die Option bei den WinCC Systemparameter überhaupt keine Auswirkung zu haben scheint.
 
Also Ich hab nun mal versucht den read request auch so zu starten... funzt auch, auch in kombination mit normalen requests in einer PDU. Nur wenn Ich 2 oder mehr Datenblöcke gleichzeitig über einen solchen Request anfragen will -> kommt gar keine Antwort mehr...
 

Anhänge

  • 1.jpg
    1.jpg
    159,2 KB · Aufrufe: 31
  • 2.jpg
    2.jpg
    151,1 KB · Aufrufe: 18
  • 3.jpg
    3.jpg
    158,8 KB · Aufrufe: 13
  • 4.jpg
    4.jpg
    160,8 KB · Aufrufe: 16
Wenn es dann nur möglich ist einen Datenbereich abzufragen, lässt sich mit dieser Adressierung ja nicht viel gewinnen.
Naja, ich ergänze es mal im Plugin insofern, dass die Werte wenigstens angezeigt werden. Neben dem Item wird die angefragte Adresse in der bekannten Any-Pointer Syntax angezeigt (siehe Screenshot).
Der Aufbau der Antwort lässt sich nur erschließen wenn man diese mit der vorigen Anfrage kombinieren würde. Das erste Byte in der Antwort hat die gleiche Bedeutung wie auch im übergeordneten Datenteil, ebenfalls Return-code: 0xff bei Erfolg, 0x05 beispielsweise wenn die Adresse in der SPS nicht vorhanden ist.

Was noch fehlt ist das erste Byte bei der Anfrage, da habe ich bisher immer eine 0x01 gesehen. Entweder das ist nochmal eine Art Dienstkennung, oder wieder eine Angabe über die Transport-Größe, wobei 0x01 nicht mit den anderen bekannten Werten zusammenpasst.

Hat schonmal jemand ein Logfile einer S7-Verbindung zwischen zwei S7-CPUs gemacht? Das sollte eigentlich auch vom plugin entschlüsselt werden können, aber das konnte ich mir noch nie ansehen.
 

Anhänge

  • Wireshark-SyntaxId-0xb0-dis.jpg
    Wireshark-SyntaxId-0xb0-dis.jpg
    126,2 KB · Aufrufe: 34
Thomas_v2.1 schrieb:
Wenn es dann nur möglich ist einen Datenbereich abzufragen, lässt sich mit dieser Adressierung ja nicht viel gewinnen.
Naja, ich ergänze es mal im Plugin insofern, dass die Werte wenigstens angezeigt werden. Neben dem Item wird die angefragte Adresse in der bekannten Any-Pointer Syntax angezeigt (siehe Screenshot).
Der Aufbau der Antwort lässt sich nur erschließen wenn man diese mit der vorigen Anfrage kombinieren würde. Das erste Byte in der Antwort hat die gleiche Bedeutung wie auch im übergeordneten Datenteil, ebenfalls Return-code: 0xff bei Erfolg, 0x05 beispielsweise wenn die Adresse in der SPS nicht vorhanden ist.

Was noch fehlt ist das erste Byte bei der Anfrage, da habe ich bisher immer eine 0x01 gesehen. Entweder das ist nochmal eine Art Dienstkennung, oder wieder eine Angabe über die Transport-Größe, wobei 0x01 nicht mit den anderen bekannten Werten zusammenpasst.

Hat schonmal jemand ein Logfile einer S7-Verbindung zwischen zwei S7-CPUs gemacht? Das sollte eigentlich auch vom plugin entschlüsselt werden können, aber das konnte ich mir noch nie ansehen.
Zum Vergrößern anklicken....
Da ist nur 0x01 gültig.
 
Hallo Thomas,
hast Du mal ein komplettes wireshark-Log vom CR bis zur (mehrfachen) Verwendung von 0xB0? Eventuell verwendet Siemens diese Struktur nicht nur in dem von mir erkannten Kontext "Zyklisches Lesen bei Änderung".
 
Moin Rainer,
im Anhang ein komplettes Logfile vom WinCC Systemstart bis zur Abfrage der Variablen, WinCC 7.2 mit einer S7-416 (Mlfb kann ich dir nicht sagen).
Ich habe die aktuelle s7comm.dll für 32-Bit Wireshark mit reingepackt, damit werden auch alle in der Anfrage aufgeführten SZL-IDs aufgeschlüsselt.

Wenn jemand irgendwelche Fehler im Dissector hat, oder Dinge die evtl. besser anders dargestellt werden sollte: Ich habe die nächste Woche etwas Zeit mich dadrum zu kümmern.
 

Anhänge

  • Log-Syntax-Id-0xb0.zip
    42,2 KB · Aufrufe: 13
Zuviel Werbung?
-> Hier kostenlos registrieren
Jochen Kühner schrieb:
Also Ich hab nun mal versucht den read request auch so zu starten... funzt auch, auch in kombination mit normalen requests in einer PDU. Nur wenn Ich 2 oder mehr Datenblöcke gleichzeitig über einen solchen Request anfragen will -> kommt gar keine Antwort mehr...
Zum Vergrößern anklicken....
Die Struktur ist 7 Bytes lang, da musst Du ein 0x00 anhängen, damit die Strukturen immer an gerader Adresse beginnen (kann und muss bei der letzten Struktur entfallen). Führe dann Deinen Test mal nach der Änderung mit mehreren Strukturen durch.
 
Zuletzt bearbeitet:
Rainer Hönle schrieb:
Die Struktur ist 7 Bytes lang, da musst Du ein 0x00 anhängen, damit die Strukturen immer an gerader Adresse beginnen (kann und muss bei der letzten Struktur entfallen). Führe dann Deinen Test mal nach der Änderung mit mehreren Strukturen durch.
Zum Vergrößern anklicken....

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..
 
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.
 

Similar threads

M
Aufbau S7Comm-Protokoll: Datenlänge von Item in Leseantwort
Antworten
1
Aufrufe
3K
Rainer Hönle
Rainer Hönle
Zurück
Oben