Verzeichniss Synchronisieren bleibt hängen...
Moderators: Hacker, Stefan2, white
Verzeichniss Synchronisieren bleibt hängen...
Hallo
Ich stelle zu meinem FTP Server die Verbindung her (Passiv-Modus). Anschliessend will ich das Verzeichniss synchronisieren. TC beginnt das Verzeichniss des Servers einzulesen. Irgendwann bleibt er jedoch stehen. Drücke ich nun die Abbrechen Taste, so geht TC weiter zum nächsten Befehl. Drücke ich erneut die Abbrech Taste, so verschwindet das Transfer-Fenster. Jetzt sind aber sämtliche Knöpfe im TC (Verzeichnisse synchronisieren) blockiert und ich kann TC nur noch via Taskmanager abschiessen...
Hab ich da was falsch eingestellt, oder ist da der Wurm drin???
Grüsse
Guldi
Ich stelle zu meinem FTP Server die Verbindung her (Passiv-Modus). Anschliessend will ich das Verzeichniss synchronisieren. TC beginnt das Verzeichniss des Servers einzulesen. Irgendwann bleibt er jedoch stehen. Drücke ich nun die Abbrechen Taste, so geht TC weiter zum nächsten Befehl. Drücke ich erneut die Abbrech Taste, so verschwindet das Transfer-Fenster. Jetzt sind aber sämtliche Knöpfe im TC (Verzeichnisse synchronisieren) blockiert und ich kann TC nur noch via Taskmanager abschiessen...
Hab ich da was falsch eingestellt, oder ist da der Wurm drin???
Grüsse
Guldi
- ghisler(Author)
- Site Admin
- Posts: 50561
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Das tönt nach einer sehr instabilen FTP-Verbindung, da ist wohl keine vernünftige Synchronisation möglich. TC scheint auf das Timeout des Servers zu warten...
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Hallo!
Das die FTP-Verbindung im TC schon mal hängen bleibt, ist ja leider nicht ganz neu.
Siehe: http://ghisler.ch/board/viewtopic.php?t=7798
Das die FTP-Verbindung im TC schon mal hängen bleibt, ist ja leider nicht ganz neu.
Siehe: http://ghisler.ch/board/viewtopic.php?t=7798
- ghisler(Author)
- Site Admin
- Posts: 50561
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Leider doch. Mit der 6.50 gibt es das Problem nicht und mit der 6.53 des öfteren. Und dies kann ich hier jederzeit nachvollziehen. "Downgrad" auf die 6.50 und es gibt nicht ein einziges Problem, die 6.53 wieder drauf und völlig unmotiviert bleibt die Datenübertragung stehen. Sowohl beim Upload, als auch beim Download bleibt die 6.53 mitten während der Datenübertragung hängen. Es gibt keine Fehlermeldung, sondern einfach nur eine nicht mehr reagierende Datenverbindung. Aber nie mitten in der Datei, sondern wenn, dann direkt am Beginn der nächsten Datei.ghisler(Author) wrote:Das liegt aber nicht am TC...
Gruß,
Christian
Christian
Warte einfach mal eine Zeit. Bei mir ist/war es so, das meistens nach 2-3 Min. der TC wieder normal reagiert hat.Guldi wrote:OK, ich finde mich mal ab, dass TC halt mal blockiert. Aber dann kann es doch nicht sein, dass ich nach dem abbrechen überhaupt nichts mehr machen kann. Wiso sind dann alle Buttons deaktiviert????
Gruß,
Christian
Christian
Also das ist schon komisch....
Ich habe ethereal installiert, um mal den Datenverkehr zu studieren und sihe da, es funktioniert jetzt viel besser....
Beim dritten Server blieb er nun endlich wieder etwas hängen. TC meldete, dass er die Verbindung verloren hat und fragte, ob er neu verbinden soll. Alles soweit gut. Das alte Transferfenster blieb aber stehen und ein neues erscheint. Na ja, dachte ich, drücke ich abbrechen beim alten. Tja, jetzt ist das Chaos perfekt. Die verbindung ging verloren und das alte Transferfenster hatte ich immer noch....
Ich begann nochmals mit dem Vergleichen (das alte Fenster ist immer noch da) und machte erfolgreich eine syncronisation. Anschliessend beendete ich das Synchronisationsfester und das alte transferfenster ist nun endlich auch verschwunden......
Lustig, nicht....
Ich habe ethereal installiert, um mal den Datenverkehr zu studieren und sihe da, es funktioniert jetzt viel besser....
Beim dritten Server blieb er nun endlich wieder etwas hängen. TC meldete, dass er die Verbindung verloren hat und fragte, ob er neu verbinden soll. Alles soweit gut. Das alte Transferfenster blieb aber stehen und ein neues erscheint. Na ja, dachte ich, drücke ich abbrechen beim alten. Tja, jetzt ist das Chaos perfekt. Die verbindung ging verloren und das alte Transferfenster hatte ich immer noch....
Ich begann nochmals mit dem Vergleichen (das alte Fenster ist immer noch da) und machte erfolgreich eine syncronisation. Anschliessend beendete ich das Synchronisationsfester und das alte transferfenster ist nun endlich auch verschwunden......
Lustig, nicht....

Cineatic: Wenn ich nach dem ersten abbrechen warte, so sendet TC den nächsten Befehl aus. Er bleibt aber immer noch hängen. Dann kann ich immer weiter auf Abbrechen drücken.... Verliere ich die Geduld, drücke ich etwa drei mal kurz nacheinander auf Abrechen und dann verschwindet das Transferfenster. Jetzt ist aber alles gesperrt, egal wie lange ich warte....
Ich habe ein Schnappschuss erwischt, wo TC hängen bleibt:
Jetzt stock TC und nach einem Moment fliegen diese zwei Packete über das Netzwerk:
Und jetzt geht gar nichts mehr...
Viel verstehe ich ja nicht, aber da fehlt doch [SYN] und der rest bevor man ein Befehl senden kann, odder irr ich mich da???
Grüsse
Ich habe ein Schnappschuss erwischt, wo TC hängen bleibt:
Code: Select all
4000 265.165023 212.40.5.35 192.168.0.78 TCP 37393 > 2198 [SYN, ACK] Seq=0 Ack=1 Win=32660 Len=0 MSS=1420
4001 265.165087 192.168.0.78 212.40.5.35 TCP 2198 > 37393 [ACK] Seq=1 Ack=1 Win=65535 Len=0
4002 265.174515 192.168.0.78 212.40.5.35 FTP Request: LIST
4003 265.194176 212.40.5.35 192.168.0.78 FTP Response: 150 Opening ASCII mode data connection for /bin/ls.
4004 265.194813 212.40.5.35 192.168.0.78 FTP-DATA FTP Data: 9 bytes
4005 265.194904 212.40.5.35 192.168.0.78 TCP 37393 > 2198 [FIN, ACK] Seq=10 Ack=1 Win=32660 Len=0
4006 265.194957 192.168.0.78 212.40.5.35 TCP 2198 > 37393 [ACK] Seq=1 Ack=11 Win=65526 Len=0
4007 265.196315 192.168.0.78 212.40.5.35 TCP 2198 > 37393 [FIN, ACK] Seq=1 Ack=11 Win=65526 Len=0
4008 265.218731 212.40.5.35 192.168.0.78 TCP 37393 > 2198 [RST] Seq=11 Ack=656643678 Win=0 Len=0
4009 265.329942 192.168.0.78 212.40.5.35 TCP 2040 > ftp [ACK] Seq=9966 Ack=44519 Win=64365 Len=0
Code: Select all
4019 280.721830 192.168.0.78 212.40.5.35 FTP Request: CWD /html/vereine/kuesnacht
4020 280.767165 212.40.5.35 192.168.0.78 TCP ftp > 2040 [ACK] Seq=44519 Ack=9995 Win=32660 Len=0
Viel verstehe ich ja nicht, aber da fehlt doch [SYN] und der rest bevor man ein Befehl senden kann, odder irr ich mich da???
Grüsse
Morgen...
Ich befürchte, dass TC einen Bug im FTP hat. Ich denke, dass ein Packet unterwegs verloren geht und dann weiss TC nicht mehr, was er machen soll.
Da ist es noch in Ordnung:
Jetzt die Passage, wo TC stecken bleibt:
TC stellt die Verbindung zum Server her und sendet den Befehl "LIST". Der Server öffnet denn ASCII mode und sollte die Daten senden. Ich nehme an, dass die Daten aber veroren gegangen sind. Nach einem Moment sendet TC ein ACK. Keine Ahnung, ob das der Server nicht versteht, oder ob dieses Packet auch veroren geht. Ich denke aber eher das erste.
Aber grundsätzlich sollte doch jetzt TC reagieren und etwas tun. Wie zum Beispiel die passive Verbindung abbrechen, neu aufbauen und den letzten Befehl "LIST" nochmals senden....Oder bin ich da vollkommen daneben???
Drückt man nun die Abbruch Taste, so werden noch folgende Befehle gesented bzw. empfangen:
Und jetzt verschwindet das Transferfenster und alle Tasten sind deaktiviert... Ich kann TC nur noch via Taskmanager abschmeissen....
Grüsse
Guldi
Ich befürchte, dass TC einen Bug im FTP hat. Ich denke, dass ein Packet unterwegs verloren geht und dann weiss TC nicht mehr, was er machen soll.
Da ist es noch in Ordnung:
Code: Select all
1577 103.382308 192.168.0.78 212.40.5.35 TCP 2861 > 29784 [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
1578 103.397765 212.40.5.35 192.168.0.78 TCP 29784 > 2861 [SYN, ACK] Seq=0 Ack=1 Win=32660 Len=0 MSS=1420
1579 103.397875 192.168.0.78 212.40.5.35 TCP 2861 > 29784 [ACK] Seq=1 Ack=1 Win=65535 Len=0
1580 103.400482 192.168.0.78 212.40.5.35 FTP Request: LIST
1581 103.452455 212.40.5.35 192.168.0.78 FTP Response: 150 Opening ASCII mode data connection for /bin/ls.
1582 103.456457 212.40.5.35 192.168.0.78 FTP-DATA FTP Data: 74 bytes
1583 103.456899 212.40.5.35 192.168.0.78 TCP 29784 > 2861 [FIN, ACK] Seq=75 Ack=1 Win=32660 Len=0
1584 103.457006 192.168.0.78 212.40.5.35 TCP 2861 > 29784 [ACK] Seq=1 Ack=76 Win=65461 Len=0
1585 103.457119 192.168.0.78 212.40.5.35 TCP 2861 > 29784 [FIN, ACK] Seq=1 Ack=76 Win=65461 Len=0
1586 103.475148 212.40.5.35 192.168.0.78 TCP 29784 > 2861 [ACK] Seq=76 Ack=2 Win=32660 Len=0
1587 103.579463 192.168.0.78 212.40.5.35 TCP 2791 > ftp [ACK] Seq=3627 Ack=16341 Win=65114 Len=0
1588 103.643835 212.40.5.35 192.168.0.78 FTP Response: 226 Transfer complete.
1589 103.648536 192.168.0.78 212.40.5.35 FTP Request: CWD Elemente
1590 103.714703 212.40.5.35 192.168.0.78 FTP Response: 250 CWD command successful.
1591 103.717757 192.168.0.78 212.40.5.35 FTP Request: PWD
1592 103.741819 212.40.5.35 192.168.0.78 FTP Response: 257 "/html/feldschiessen/fs-software/Elemente" is current directory.
1593 103.746137 192.168.0.78 212.40.5.35 FTP Request: PASV
1594 103.764645 212.40.5.35 192.168.0.78 FTP Response: 227 Entering Passive Mode (212,40,5,35,200,232)
Code: Select all
1595 103.765803 192.168.0.78 212.40.5.35 TCP 2862 > 51432 [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460
1596 103.781557 212.40.5.35 192.168.0.78 TCP 51432 > 2862 [SYN, ACK] Seq=0 Ack=1 Win=32660 Len=0 MSS=1420
1597 103.781645 192.168.0.78 212.40.5.35 TCP 2862 > 51432 [ACK] Seq=1 Ack=1 Win=65535 Len=0
1598 103.784274 192.168.0.78 212.40.5.35 FTP Request: LIST
1599 103.803049 212.40.5.35 192.168.0.78 FTP Response: 150 Opening ASCII mode data connection for /bin/ls.
1600 103.981788 192.168.0.78 212.40.5.35 TCP 2791 > ftp [ACK] Seq=3658 Ack=16566 Win=64889 Len=0
Aber grundsätzlich sollte doch jetzt TC reagieren und etwas tun. Wie zum Beispiel die passive Verbindung abbrechen, neu aufbauen und den letzten Befehl "LIST" nochmals senden....Oder bin ich da vollkommen daneben???
Drückt man nun die Abbruch Taste, so werden noch folgende Befehle gesented bzw. empfangen:
Code: Select all
1007 395.788840 192.168.0.78 212.40.5.35 TCP 2862 > 51432 [FIN, ACK] Seq=0 Ack=0 Win=65535 Len=0
1008 395.828781 212.40.5.35 192.168.0.78 TCP 51432 > 2862 [RST] Seq=0 Ack=3752341513 Win=0 Len=0
1027 411.303573 192.168.0.78 212.40.5.35 FTP Request: CWD /html/feldschiessen/fs-software
1028 411.334270 212.40.5.35 192.168.0.78 TCP ftp > 2791 [ACK] Seq=0 Ack=37 Win=32660 Len=0
1064 446.105995 192.168.0.78 212.40.5.35 FTP Request: CWD /html/feldschiessen
1065 446.136497 212.40.5.35 192.168.0.78 TCP ftp > 2791 [ACK] Seq=0 Ack=62 Win=32635 Len=0
1219 453.619762 192.168.0.78 212.40.5.35 FTP Request: CWD /html
1220 453.655384 212.40.5.35 192.168.0.78 TCP ftp > 2791 [ACK] Seq=0 Ack=73 Win=32624 Len=0
1224 457.595432 192.168.0.78 212.40.5.35 FTP Request: PWD
1225 457.646982 212.40.5.35 192.168.0.78 TCP ftp > 2791 [ACK] Seq=0 Ack=78 Win=32619 Len=0
1232 462.614487 192.168.0.78 212.40.5.35 FTP Request: CWD /
1233 462.648062 212.40.5.35 192.168.0.78 TCP ftp > 2791 [ACK] Seq=0 Ack=85 Win=32612 Len=0
1255 481.159462 192.168.0.78 212.40.5.35 TCP 2791 > ftp [RST, ACK] Seq=85 Ack=0 Win=0 Len=0
Grüsse
Guldi
- ghisler(Author)
- Site Admin
- Posts: 50561
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
TC rechnet nicht damit, dass TCP-Pakete komplett verloren gehen - und das müsste er im Prinzip auch nicht! Bei einer TCP-Verbindung garantieren eigentlich die tieferen Protokollschichten, dass verlorene Pakete neu angefordert und erneut versandt werden. Offenbar ist das bei Ihnen nicht der Fall, möglicherweise wegen einer Firewall, welche Pakete nicht durchlässt...
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
@ghisler:
Besten Dank für die Antwort.
Die Firewall muss es wohl sein. Ich gehe davon aus, dass ein Paket verloren geht. Der Server wartet auf Antwort des Empfängers und will schliesslich nach einem Timeout das Paket wiederholen. Doch inzwischen wird vermutlich die Firewall dicht machen und es kommt gar nichts mehr durch...
Firewalls kommen immer mehr zum Einsatz, auch Privat. So nehme ich an, dass dieses Problem immer mehr auftauchen wird.
Frage: Ist es nicht möglich ein Timeout zu implementieren, So dass TC nach einem Paketverlust wieder die aktive Rolle übernimmt???
Beste Grüsse
Guldi
Besten Dank für die Antwort.
Die Firewall muss es wohl sein. Ich gehe davon aus, dass ein Paket verloren geht. Der Server wartet auf Antwort des Empfängers und will schliesslich nach einem Timeout das Paket wiederholen. Doch inzwischen wird vermutlich die Firewall dicht machen und es kommt gar nichts mehr durch...
Firewalls kommen immer mehr zum Einsatz, auch Privat. So nehme ich an, dass dieses Problem immer mehr auftauchen wird.
Frage: Ist es nicht möglich ein Timeout zu implementieren, So dass TC nach einem Paketverlust wieder die aktive Rolle übernimmt???
Beste Grüsse
Guldi
- ghisler(Author)
- Site Admin
- Posts: 50561
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Das habe ich mir auch schon überlegt. Das Problem ist, dass nicht alle FTP-Server resume unterstützen. Wenn man nun z.B. nach 30 Sekunden ohne Reaktion abbricht und neu verbindet, ist der Download u.U. futsch...
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com