Step 7 S7 sendet RST über aufgebaute Verbindung

[Lipperlandstern]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und heute ploppt das Problem wieder auf. Der Kunde will jetzt dauerhaft seine Anwendung auf Windows 2022 Server migrieren und dann läuft dort ein Virenscanner (Crowdstrike) der die Antwort verzögert. Meine Steuerung sendet aber nach 11ms ein RST und das ist für den neunen Server mit dem Scanner zu langsam . Woher das RST kommt weiß ich immer noch nicht...

 

[312C]

Kann denn wirklich ausgeschlossen werden, dass das Anwenderprogramm z.B. mittels TDISCON Aufruf die Verbindung abbaut ? Denn soweit ich weiß ist der harte TCP-Reset das Standard-Verhalten der T-Bausteine bis TIA V17. Ab da kann man mit dem TCONSettings einstellen, ob ein normales Finish oder der Reset durchgeführt werden soll.

 

[Lipperlandstern]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann denn wirklich ausgeschlossen werden, dass das Anwenderprogramm z.B. mittels TDISCON Aufruf die Verbindung abbaut ? Denn soweit ich weiß ist der harte TCP-Reset das Standard-Verhalten der T-Bausteine bis TIA V17. Ab da kann man mit dem TCONSettings einstellen, ob ein normales Finish oder der Reset durchgeführt werden soll.

Das ganze ist mit S7-classic programmiert. Und natürlich werden die Verbindungen durch TDISCON abgebaut. Aber nicht nach 11ms sondern dann wenn Daten empfangen wurden. Es funktioniert auch so lange bis wieder einer am Server spielt

 

[Pipboy]

Bei diesem Projekt werden Verbindungen vor jedem Senden auf- und wieder abgebaut. Anschließend wird ein anderer Port geöffnet und auf die Antwort gewartet.
Das RST ist nicht gewollt, wurde aber im Wireshark protokoliert. Dadurch ist der Server nicht in der Lage eine Antwort zu senden.

Das passt nicht zusammen, die Antwort kommt doch auf einer anderen Verbindung?
Lass dir den Trace schicken und schau nach wo / woher der RST kommt.
Wenn das wirklich die Steuerung ist, wäre die erste Vermutung das etwas mit dem DISCON Trigger nicht stimmt.
Beim Anlauf gibt es vielleicht noch ein paar andere Sachen zu tun, die den lang genug verzögern.

 

[Lipperlandstern]

Das passt nicht zusammen, die Antwort kommt doch auf einer anderen Verbindung?
Lass dir den Trace schicken und schau nach wo / woher der RST kommt.
Wenn das wirklich die Steuerung ist, wäre die erste Vermutung das etwas mit dem DISCON Trigger nicht stimmt.
Beim Anlauf gibt es vielleicht noch ein paar andere Sachen zu tun, die den lang genug verzögern.

Aber warum läuft das System seit einigen Jahren fehlerfrei und erst als die Gegenstelle irgendwelche Änderungen vornimmt bricht alles zusammen.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also, wenn die am SERVER was gemacht haben und es danach nicht mehr geht, würde ich tatsächlich nochmal genau die Ports prüfen:

Der Server (siehe Skizze) empfängt das Paket. Ist der Port geschlossen, antwortet er mit einem TCP-RST, um zu signalisieren, dass keine Verbindung aufgebaut werden kann.

aus: https://de.wikipedia.org/wiki/Transmission_Control_Protocol

 

[Pipboy]

Aber warum läuft das System seit einigen Jahren fehlerfrei und erst als die Gegenstelle irgendwelche Änderungen vornimmt bricht alles zusammen.

Darüber kann man sicher noch eine ganze Weile rätseln. Wenn ein paar ms Verzögerung die Kommunikation komplett aus dem Tritt bringen ist irgendwas nicht richtig gemacht.
Dass die Steuerung so schnell random einen RST hinterher schickt klingt reichlich seltsam.