Wireshark Plugin für S7-Protokoll

Bei Wireshark V1.4.0 erhalte ich folgende Fehlermeldung:

Err Field 'Parameter data' (s7comm.param.data) is an FT_BYTES
but is being displayed as BASE_HEX instead of BASE_NONE

Hallo chris,
danke für deine Rückmeldung.

Bei der Version 1.4.0 wurde bei Wireshark in der Hinsicht wohl etwas geändert. Nicht-numerische Typen verlangen jetzt BASE_NONE statt BASE_HEX. Ich habe die entsprechenden Stellen angepasst und nun funktioniert es mit der 1.4.0 sowie mit der 1.2.0 (für die Windows 2000 Nutzer wie mich ;-) ).
Vielleicht war das auch das Problem das dieterb damals mit der Development Version von Wireshark hatte.

Wenn jemand noch falsch dargestellte Pakete hat, wäre es natürlich hilfreich mir diese Fehler mitzuteilen, bzw. solche Pakete aufzuzeichnen. Es gibt so viele Funktionen in dem Protokoll dass ich nicht alle Funktionen simulieren kann.

Gruß
 

Anhänge

  • s7comm-dll-2010-10-02.zip
    12,8 KB · Aufrufe: 199
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Thomas,

Erst mal danke für die viele Arbeit die du hier rein gesteckt hast.

Mir ist aufgefallen, dass die 64-bit Version von Wireshark inkompatibel mit dem zuletzt hochgeladenen Plugin ist.
Kann man da eventuell was machen? Oder muss ich zwangsläufig auf x86 zurückgreifen?

Danke
 
Mir ist aufgefallen, dass die 64-bit Version von Wireshark inkompatibel mit dem zuletzt hochgeladenen Plugin ist.
Kann man da eventuell was machen? Oder muss ich zwangsläufig auf x86 zurückgreifen?

Naja, die üblichen 64-bit Probleme halt...

Ich habe kein 64-bit System (eben aufgrund der Probleme mit diversen Programmen) zur Verfügung, meine VC6 Entwicklungsumgebung läuft in einer virtuellen Maschine unter Windows 2000 ;-)
Ich könnte dir höchstens die Quellen zum selbstübersetzen zur Verfügung stellen.
 
Bevor das Projekt auf meiner Festplatte ganz einschlummert, habe ich es mal bei Sourceforge angelegt:

https://sourceforge.net/projects/s7commwireshark/

Folgende Aktualisierungen habe ich im Vergleich zur letzten hier veröffentlichten Version vorgenommen:
- Darstellung der SZL-IDs in hex geändert
- Einige "interessante" SZL-Anfragen werden im Klartext aufgeschlüsselt
- Diverse Fehlerbereinigungen

Leider gab es von den 64-Bit Nutzern noch keine Rückmeldung, ob und wie jemand das Plugin übersetzt bekommen hat. Darum kann ich momentan nur sagen dass die dll unter 32-Bit Windows mit Wireshark lauffähig ist (bei mir läuft momentan Version 1.4.1 unter Windows 7 32 bit).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also zum Thema 64-bit,

ich wollte das Plugin für 64-bit kompilieren, habs aber leider nicht wirklich geschafft.

Dann hab ich einfach unter Win7x64 Wireshark (1.4.3) in der 32-bit Version installiert, und dort die 32-bit Version des Plugins verwendet, was einwandfrei funktioniert.
Deshalb hab ich mich auch nicht weiter um die 64-bit Variante gekümmert, da es ja problemlos lief.

Ich versuche bei Gelegenheit nochmal eine x64 Dll hinzubekommen, kann aber nichts versprechen!
 
ich wollte das Plugin für 64-bit kompilieren, habs aber leider nicht wirklich geschafft.

Dann hab ich einfach unter Win7x64 Wireshark (1.4.3) in der 32-bit Version installiert, und dort die 32-bit Version des Plugins verwendet, was einwandfrei funktioniert.
Deshalb hab ich mich auch nicht weiter um die 64-bit Variante gekümmert, da es ja problemlos lief.

Ich versuche bei Gelegenheit nochmal eine x64 Dll hinzubekommen, kann aber nichts versprechen!

Ah, na wenn es unter 64-Bit Windows mit der 32-Bit Wireshark Version läuft, ist es wenigstens irgendwie für die Win64 Nutzer benutzbar.

Wie weit bist du mit dem Übersetzen denn gekommen? Dir ist aber schon klar, dass du quasi erst das komplette Wireshark selber übersetzen musst, damit du letztendlich das Plugin übersetzen kannst. Zumindest benötigst du die Wireshark Sourcen und das komplette Build-System (Platform SDK, Python, Cygwin).
Hier gibt es eine Schritt-für-Schritt Anleitung mit der das bei mir problemlos geklappt hat:
http://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html
 
Wer hat denn die Möglichkeit und Lust mal die s7comm.dll mit der 64-Bit Version von Wireshark zu testen?
Übersetzt habe ich diese jetzt soweit, kann es aber mangels 64 Bit PC selber nicht testen.
 
Wärs denn keine Idee das ganze an Wireshark zu senden, so das es in die offiziellen Releases mit aufgenommen wird?

(Sonst muss Ich mir jetzt doch noch ne Build Umgebung aufbauen, würd das Plugin nämlich gerne in meinem MacBook nutzen :-( )
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wärs denn keine Idee das ganze an Wireshark zu senden, so das es in die offiziellen Releases mit aufgenommen wird?
Meiner Meinung nach sollten im offiziellen Wireshark nur 100%ig vollständig und richtige Protokolle enthalten sein. Davon ist das hier ja noch sehr weit entfernt, und der Stand wird ohne Protokollbeschreibung auch wohl nie erreicht werden.

Ich bin momentan dabei viele Dinge aufgrund von neuen Erkenntnissen umzubenennen. Die PDU-Type nennt sich unter anderem jetzt ROSCTR (Remote Operating Service Control), denn auf der Siemens Seite lassen sich Informationen über das Sinec AP Protokoll finden, und Teile davon sind wohl in das S7 Protokoll eingeflossen. Darum übernehme ich jetzt die Bezeichnungen die dort verwendet werden.
Ein paar Bezeichnungen lässt Siemens auch in Dokumentationen für die Sinumerik Steuerungen fallen. Wenn man mal ein paar offizielle Bezeichnungen gefunden hat, stößt man mit der google Suche nach diesen auch auf weitere Dokumente aus denen sich was raussaugen lässt.
 
Kann ich dir denn noch mit was weiterhelfen? Hab ja z.B. die Anfrage für Baustein Diagnosedaten beim mir in der Bibliothek drin. Willst du in die Richtung auch was einbauen?
 
Ich würde am liebsten erstmal den Parameter-Teil vollständig haben.

Was haben z.B. die ersten 3 Bytes bei Userdata-Telegrammen zu bedeuten? Bzw. ist "Userdata" als Name für diese Telegramme überhaupt richtig, denn in diesen Telegrammen steckt alles andere außer den Variablendiensten. Die anderen Kennungen lauten in Siemens original-Sprech z.B. "Auftrag mit Quittung", was ich einfach mal "Job" übersetzt habe. Die Antworten heißen dann im original "Quittung ohne Zusatzfeld" und "Quittung mit Zusatzfeld", bei mir "Ack" und "Ack_Data" genannt.

Wenn man das Schema wie bei den Variablendiensten annimmt, wäre das erste Byte im Parameter der Funktionscode. Der ist dabei aber immer Null.
Das zweite Byte ist immer 1. Vielleicht gibt dieses die Anzahl der Parameter-Datensätze an. Ich habe aber immer nur einen Satz gesehen.
Das dritte Byte ist immer 0x12, vielleicht gibt das an wie der Parameter-Satz aufgebaut ist? Irgendeine Bedeutung muss das aber haben, denn es ergibt ja keinen Sinn 3 Bytes für hier überflüssige Konstanten einzusetzen.

Bei den Bytes 4, 5 und 6 scheint das was ich mir da überlegt habe von der Funktion her zwar zu passen, aber so einen verrückten Aufbau traue ich nichtmal Siemens zu. Da muss irgendeine andere Logik hinterstecken.
Dann gibt es noch ein Byte vor dem Byte welches kennzeichnet dass dieses die letzte Dateneinheit zu einem Datensatz ist. Dort steht immer ein Wert ungleich Null wenn dieses nicht der letzte Datensatz ist, aber die Werte darin sind immer unterschiedlich. Ich habe schon 2, 5 und 7 gesehen. Keine Ahnung was das soll.
Technisch sinnvoll wäre eigentlich dem Partner die Anzahl der noch folgenden Pakete mitzuteilen wenn fragmentiert wird, aber das scheint es nicht zu sein.

Ich habe meinen aktuellen Arbeitsstand mal angehängt, kannst dir das ja mal ansehen (hab' die 32 und 64 Bit reingepackt). Ich habe im Laufe der Zeit noch ein paar andere Dinge geändert.
 

Anhänge

  • s7comm-0-0-3-0-pre.zip
    57,1 KB · Aufrufe: 60
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn die immer gleich sind, kann ich dir leider auch nicht mehr dazu sagen. Ich hab leider auch keine internen Infos, sondern nur das was Ich durch probieren rausgefunden habe.
Also falls du bei den Telegrammen zum Up/Download weitere Infos über den Baustein, oder bei den Bausteindiagnosetelegrammen weitere Details einbauen willst, dazu hab Ich halt noch Infos...
Wenn Ich aber was rausfinde, gibt's natürlich hier weitere Infos... Ich mach mich mal wieder an die Bausteinprüfsumme
 
Ich habe mir gerade nochmal ein paar Aufzeichnungen angesehen. So wie es aussieht ist diese Nummer doch nicht konstant, sondern eine weitere Referenz-Nummer auf die man sich beziehen kann/muss wenn ein Telegramm aufgrund der Größe fragmentiert wird. In einigen Aufzeichnungen wird diese Nummer von der SPS bei jedem neuen fragmentierten Telegramm erhöht. Eine Abfrage dieser Nummer ist nur notwendig wenn man mehrere Telegramme gleichzeitig auf die Reise schickt. Darum funktioniert das auch in libnodave ohne die Abfrage der Nummer, da dort immer nur eine einzige Anfrage zur Zeit läuft.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe mir gerade nochmal ein paar Aufzeichnungen angesehen. So wie es aussieht ist diese Nummer doch nicht konstant, sondern eine weitere Referenz-Nummer auf die man sich beziehen kann/muss wenn ein Telegramm aufgrund der Größe fragmentiert wird. In einigen Aufzeichnungen wird diese Nummer von der SPS bei jedem neuen fragmentierten Telegramm erhöht. Eine Abfrage dieser Nummer ist nur notwendig wenn man mehrere Telegramme gleichzeitig auf die Reise schickt. Darum funktioniert das auch in libnodave ohne die Abfrage der Nummer, da dort immer nur eine einzige Anfrage zur Zeit läuft.

Welche Software gibt es denn die mehrere Telegramme losschickt? Bringt das überhaupt was? D.h. Ich kann noch ein Telegramm absenden bevor die S7 auf das vorherige geantwortet hat?

Thomas_v2.1 schrieb:
Hast du zu den Diagnosetelegrammen irgendwas dokumentiert, oder steht das meisten bei dir im Quellcode drin?

Im Quellcode. Die PLCConnection.cs Funktion: PLCStartRequestDiagnosticData.

Zum aufbau von den S7 Blöcken ist noch was in der MC7Converter.cs Funktion GetAWLBlock, das bringt aber ja nur was bei der ersten anfrage, wenn der block gesplittet wird bringts ja nichts mehr...
 
Welche Software gibt es denn die mehrere Telegramme losschickt? Bringt das überhaupt was? D.h. Ich kann noch ein Telegramm absenden bevor die S7 auf das vorherige geantwortet hat?
Beim Simatic.Net OPC Server kann man das beispielsweise einstellen. Die Anzahl wird wie die PDU Größe beim Verbindungsaufbau ausgehandelt.
In der letzten Version "Max amq calling/called" genannt, so heißt es auch in den Siemens Dokumentationen. Wie bei der PDU Größe ist das vom Anfrager ein Vorschlag, und die SPS verringert diesen ggf. auf ihre maximale Anzahl.
"Called" ist die Anzahl des Partners, und "Calling" die eigene. Die Anzahl gilt für Aufträge mit Quittung.

Ob das was bringt? Keine Ahnung. Auf einer langsamen Datenleitung wie MPI wohl eher als auf einer schnellen wie Ethernet im LAN, da nicht so viel Zeit mit Warten verbracht werden muss.
 
Man sollte ja nicht mit was neuem anfangen wenn das alte noch nicht fertig ist, aber ich war grad neugierig :)

Ich habe in das Plugin auf die Schnelle eine Weiche eingebaut damit die symbolischen Adressangaben der 1200 zumindest grundsätzlich aufgeschlüsselt werden.
Der Telegrammaufbau bei der Kommunikation der 1200 mit dem integrierten TIA HMI ist grundsätzlich identisch einer 300/400er Steuerung (Kopf-, Parameter- und Datenteil). Nur die Variablenspezifikation ist eben anders.
Die magische Zahl die dem SPS-Symbol zugeordnet scheint auf jeden Fall 12 Byte lang zu sein.

Hat sich das schonmal jemand näher angesehen ob man aus der Zahl an sich noch weitere Informationen extrahieren kann? Und gibt es schon einen Mitschnitt der Kommunikation mit der neuen 1500er?

wireshark-1200-sym.jpg
 
Zurück
Oben