# FTP - Verbindung automatisch trennen



## CrazyCat (17 Oktober 2006)

Mit einem CP343-1 advanced IT gibt es ein kleineres Problem.

Der Server holt die Daten mittels FTP - Tool vom CP. Dann und wann schmiert das Tool ab, wird vom Server beendet und in einem gewissen Zeitintervall wieder neu gestartet.

Das alles ist noch kein Problem.

Das Problem ist das die Verbindung nicht getrennt wird, wenn das FTP - Tool abschmiert und vom Server beendet wird.
Irgendwann läßt der CP keine neuen Verbindungen mehr zu und muss neu gestaret werden, damit die Daten wieder übertragen werden können.

Kann man so eine Automatik einrichten, die die Verbindungen nach einer Leerlaufzeit von 5 Minuten automatisch trennt?
Kann diese Aufgabe der CP übernehmen?


----------



## CrazyCat (23 Oktober 2006)

Nachdem es offenbar keine Lösung für dieses Problem gibt, stelle ich eine andere Frage:

Wenn der CP keine weiteren Benutzer auf der FTP - Verbindung zuläßt, wie kann ich diesen Fehler beheben?

Kann ich das Limit für die FTP - Verbindungen erhöhen?

Kann ich die Verbindungen über einen Befehl an der CPU trennen?

Gibt es irgendeine andere Möglichkeit die Verbindungen wieder abzubauen, außer dem Aus- und Einschalten der CPU?


----------



## CrazyCat (9 November 2006)

OK.

Andere Frage: Kann ich irgendwie einen Kommunikationsstop von 3 Minuten erzwungen?

Nach 2 Minuten sollte ohne Kommunikation sollte der CP ja seine Verbindungen automatisch rücksetzen.


----------



## CrazyCat (9 November 2006)

Kommt schon Leute!

Es muss doch irgendeinen Grund geben, warum der CP nach einer gewissen Zeit keine neuen Benutzer mehr zuläßt und nur durch Spannung aus/Spannung ein wieder einen Zugriff erlaubt.

Es muss auch irgendeine Möglichkeit geben, wie man die Verbindungen vom CP oder von PC aus trennen kann, falls sie mal nicht rückgesetzt worden sind.

Wie kann man das anstellen?


----------



## CrazyCat (9 November 2006)

Das darf doch nicht wahr sein!

Bin ich der einzige Mensch auf Erden der dieses Problem hat?

Selbst wenn ich das verschissene Kabel 3 Minuten abstecke (Timeout sollte laut Siemens nach 2 Minuten automatisch alle Verbindungen trennen) läßt mich die Drecksmühle noch immer nicht rein! :twisted: :twisted: :twisted: 

Bei Siemens hat man wieder mal, wie üblich, null Ahnung woran das liegen könnte.

IRGENDJEMAND wird wohl dieses Problem kennen, oder?

Gibt es noch andere Foren, in welchen man diese Frage stellen könnte?

Werde ich hier schon rein prinzipiell ignoriert?


----------



## Unregistrierter gast (9 November 2006)

Hallo crazy cat (jetzt weis ich, woher das "crazy" kommt  )

Zu deinen Fragen:

NEIN, _ich _ignoriere dich nicht prinzipiell, habe aber auf deine Fragen keine Antwort.

NEIN, ich weis nicht, woran es liegen könnte oder wie man den Fehler behebt.

ABER das ein CP nur eine gewisse Anzahl Verbindungen zulässt, ist ja bekannt (bei der LEAN sind es z.B. nur 8)

Es tut mir leid, dir nicht geholfen zu haben!


----------



## CrazyCat (9 November 2006)

Ist mir bekannt das der verdammte CP ein Verbindungslimit hat.

Nur das er dieses NIE UND NIMMER rücksetzt, außer wenn man die Baugruppe urlöscht oder das Scheißding neu startet, ist für mich unerklärlich.

Wenn man mit Siemens telephoniert, haben sie von dem Problem keinerlei Ahnung. :twisted: 

Mittlerweile arbeite ich 3 Monate an dem Problem, bald springe ich ins Auto und mache Terror, bis IRGENDEINEM Siemens - Burschen doch einfällt wie man das Problem behebt.

Wer zahlt mir diese Stunden?
Siemens wird sie wohl nicht zahlen.

Ich habe von dem Siemens - Scheiss die Nase gestrichen voll. Das nächste Mal werde ich alles auf Mitsubishi aufbauen, sofern ich die Leute irgendwie dazu überrreden kann, denn Siemens ist irgendwo in den 70ern stehen geblieben.
Außer und/oder Verknüpfungen und ein paar Timern funktioniert nichts richtig.
Wäre ja schon der Hammer wenn sie sich bei ihrem eigenem Zeug auskennen würden.

Wäre über eine Aussage wie "Trottel, du mußt den DB regelmäßig null setzen, dann klappt's" schon äußerst dankbar.
Mit einem "Der Fehler ist uns nicht bekannt, wiederhören" ist mir nicht geholfen.

Also, kann mir jemand bei der Lösung des Problems helfen?


----------



## guenni (9 November 2006)

Hallo CC

ich weiss nicht ob es Dir hilft, es gibt doch die Bausteine FTP_Connect und FTP_Quit welche die Verbindung zum Server Aufbauen bzw. Abbauen. Kann man mit diesen nichts machen? 

Gruss Guenni


----------



## Helmut (10 November 2006)

Hallo CrazyCat,

Erstmal kenn ich mich mit dem Zuegs nicht recht aus. Aber mal eine Idee dazu:

Gibt es denn keinen Baustein, mit dem du den CP dazu bringst seine Konfig neu zu lesen? Wenn Ja, dann versuch doch mal ob der CP seine FTP-Verbindungen beendet wenn du die Konfig neu liest. Dauert warscheinlich bis der CP wieder angelaufen ist, aber vieleicht klappts ja. Ist einen Versuch wert.

Ich weis, Ich weis aber bei S7-200 (da kenn ich mich aus) nimmst du den CP243-1IT. Wenn du was mit FTP machen möchtest, so wird ein POU namens ETHx_CTRL. 

Hier ein Auszug:

_This instruction commands the CP243-1 Ethernet module to check the V memory area for a new configuration each time the CPU changes to RUN mode. If the configuration is different or the CRC protection is disabled, then the *module is reset with the new configuration*._ 

Lass es uns wissen, ob's was bringt.

Gruss

Helmut


----------



## CrazyCat (10 November 2006)

Es gibt zwei Bausteine, einen namens IP - Konfig, der die IP - Adresse und die Verbindung neu zuordnet und einen anderen namens Status, der den Status des Geräts ausgibt.

Werde diese Funktionen mal testen und sehen ob es was bringt.

Das Neuladen der HW - Konfig bringt jedenfalls nichts, der Fehler besteht in diesem Fall weiterhin.


----------



## CrazyCat (10 November 2006)

Die Zuweisung über IP - Konfig bringt nicht den gewünschten Erfolg, der CP macht keinen Reset.

Auch Status fordert keinen Reset an.......vielleicht finde ich einen Baustein mit dem ich Baugruppen gezielt reseten kann, wenn sie nicht mehr wollen.

Was auffällt ist das der CP plötzlich eine Peripheriesperre durch die S7 - CPU bekommt, wieder freigegeben wird, wieder gesperrt wird.....bis er irgendwann nicht mehr freigegeben wird.

Nach dem Neuladen der HW - Konfig wird er zwar wieder freigegeben, über FTP kann er aber weiterhin nicht erreicht werden.

Was kann der Grund für die Sperre sein?

Auffällig ist auch, das sämtliche andere Funktionen (Routing, Diagnose, Ping, HTTP - Zugriff usw.) weiterhin funktionieren, nur die FTP - Verbindungen können nicht mehr hergestellt werden.

Was kann der Grund hierfür sein?


----------



## CrazyCat (10 November 2006)

So noch ein kleines Update.

Weder der FC10 AG_CTRL, wenn er alle Verbindungen als erfolgreich beendet meldet, noch das Urlöschen des CPs und Neuladen der HW - Konfig beheben das Problem.


----------



## argv_user (10 November 2006)

*Ftp*

Hallo,
FTP ist ein Protokoll, das zwei TCP-Ports benutzt.
Einen Port für Kommandos, einer für Daten.

Vielleicht hilft Dir das ja weiter, mit dem CP
kenn ich mich leider nicht aus.


----------



## CrazyCat (10 November 2006)

Nun das wird sich zeigen, ob mir diese Info etwas nutzt, interessant und hilfreich ist sie auf jeden Fall.

Also mal angenommen, es wird die Verbindung und der Prot für die Daten wieder freigegeben, nicht aber der Port für die Kommandos.
Dann wären die Daten nach wie vor da und ggf. übertragbar, da man sich aer über den Kommandoport nicht mehr anmelden kann, ist man ausgesperrt.

Das kann u.U. Sinn ergeben.

Weißt du zufällig welche Ports verwendet werden und ob man diese am CP oder am PC programmgesteuert rücksetzen kann?


----------



## argv_user (11 November 2006)

Port 21 ist der Kommandoport
Port 20 ist der Datenport

Beim PC werden die Ports spätestens dann geschlossen,
wenn das Programm beendet wird. Ob der CP das merkt,
ich glaube nein. Nach dem was Du sagst stürzt das PC-Programm
ab. Kann sein dass dabei das FTP-Protokoll nicht mehr
sauber beendet wird, dh der CP meint die Verbindung besteht
noch und akzeptiert dann keine neue.

BTW: Was ist denn das für ein FTP-Tool, dass es sich 
überhaupt abzustürzen traut ?


----------



## CrazyCat (11 November 2006)

Das ist auch eine meine Vermutungen.

Der Datenport wird zwar durch Timeout geschlossen, der User bleibt aber angemeldet.

Beim Neustart wird wieder ein neuer User angemeldet, der alte aber nie abgemeldet, was irgendwann zu einem Überlauf der Benutzer führt.

Das Tool das es wagt abzustürzen, nennt sich Robo - FTP und ist eines der wenigen skriptfähigen FTP - Tools auf dem Markt.


Kann man irgendwie am CP die Benutzer alle wieder rauswerfen?
Was passiert am CP bei einem Logout genau, sowohl bei einem Zugriff durch die CPU selbst, als auch bei einem Zugriff von außen durch einen PC oder Server?
Kann man das irgendwie programmtechnisch nachbilden?


----------



## CrazyCat (13 November 2006)

OK.

Scheinbar sind wir wieder ins Stocken gekommen.

Eine neue Frage: Unterstützt der CP anonymes Anmelden und belegt eine anonyme Anmeldung wieder eine Ressource auf dem CP?

Habe ich dann mehrere anonyme User auf dem CP die er nicht rauswirft oder belegen die keine der Ressourcen?


----------



## CrazyCat (15 November 2006)

Kleines Update für alle die es interessiert:

Siemens hat folgendes festgestellt:

"Der CP kann nur dann einen Abriss der FTP-Client-Verbindung erkennen, wenn 
ein FTP-Kommando von Server nicht quittiert wird
vom Server ein Abbruch durchgeführt wird.
der CP erkennt KEINEN Abbruch, wenn man das Kabel zieht während keine FTP-Kommandos bearbeitet werden. Eine FTP-Client-Verbindung ist nicht zeitüberwacht."


D.h. der CP erhält die Anforderung "Daten senden", quittiert diese und sendet anschließend die Daten.

Fällt die Verbindung also während der Datenübertragung aus, so bemerkt er den Ausfall nicht.
Der Client baut eine neue Verbindung zum CP auf und meldet sich erneut an, da er den Ausfall bemerkt.
Der vorhergehende Benutzer, dessen Ausfall vom CP nicht bemerkt wurde, verbleibt am CP als angemeldet.
Irgendwann ist das Maximum der Benutzer erreicht und es funktioniert nichts mehr.

Wie kann ich also während der Datenübertragung eine ständige Quittierung durch den CP erzwingen?
Kann man die User irgendwie automatisch rauswerfen?


----------



## Unregistrierter gast (15 November 2006)

Hallo CC,

was anderes:

Hat dir meine PM bez. PW weitergeholfen ?


----------



## CrazyCat (15 November 2006)

Hast du meine PN nicht erhalten?

Danke für die Unterlagen.

Ich habe mir die Unterlagen mal durchgesehen:

Das schreiben der Passwortliste hilft mir nicht viel weiter, da ProTool csv - Dateien verwendet hat und WinCC flexible hierfür PWL - Dateien einsetzt.

Die Anmeldung eines virtuellen Users hat mir geholfen, damit kann ich was anfangen.

Irgendein Skript zum Speichern der PWs war noch dabei, da hatte ich noch keine Zeit mir dieses anzusehen.



Back to topic: Hat jemand eine Idee wie man das Problem lösen kann?


----------



## Unregistrierter gast (15 November 2006)

CrazyCat schrieb:


> Hast du meine PN nicht erhalten?


Nein. !?

......


----------



## Flo (19 November 2006)

Hallo CrazyCat,

und, Problem schon gelöst? Ich geb auch mal meinen Senf dazu:
wie Guenni weiter oben bereits beschrieben hat, gib es in der "SIMATIC NET CP" Bibliothek Bausteine für die FTP Kommunikation. Einer dieser Bausteine heisst "FTP quitt" mit dem man ohne grossen Aufwand verbindungen trennen kann. Nach einem gelungenen Trennen der Verbindung kann man mit dem "FTP Connect" die Verbindung wieder herstellen.
Ich habe die Bausteine zwar selber noch nicht getestet, kann mir aber nicht vorstellen das die nicht funktionieren, denn die bei Siemens sind ja auch nicht auf den Kopf gefallen.


----------



## CrazyCat (20 November 2006)

Es wird jetzt 2x ein Logoff - Request gesendet.

1x standrdmäßig nach der erfolgreichen Datenübertragung und sicherheitshalber nochmals vor jedem Login.

Also 2x der Baustein FTP_quitt, klingt zwar nicht logisch, aber mit dem doppeltem Logoff funktioniert es bis JETZT.

Ob das Problem dadurch für alle Zeiten gelöst ist, kann ich derzeit nicht abschätzen.


----------

