TC 6.56: FTP bricht laufend ab, wenn Bilder...

rellek · Post by *rellek » 2007-07-21, 11:55 UTC

Hacker wrote:rellek,
Hm, zwei Dinge stoeren mich da:
1. das TCP Checksum Incorrect bei 15877 und 15885

Das ist "normal" irgendwie, das kommt auch bei HTTP-Surfen im Firefox oder so. Frag mich nicht, woher das kommt...

Hacker wrote:2. das nach 15885 (ACK zu FTP: 226 Transfer complete) nichts kommt - sollte der TC nicht nach dem Ordnerinhalt fragen, wie in 15898 (nach manuellem Abbruch nach fast 3 Minuten)?

Das wundert mich auch. Laut Meldung müsste es ja theoretisch auch die skype_voicemail.gif noch komplett auf die Platte geschafft haben, aber die gibt es nicht (vor TC7 hätte es sie gegeben, aber mit 0 Bytes)

Hacker wrote:Koennten wir auch ein Capture sehen, wo alles klappt (z.B. wenn du FileZilla benutzt)?

Kann ich gerne machen (FlashFXP dann vermutlich) - soll ich dann den ganzen Capture irgendwo hochladen?

Hacker wrote:Haben die anderen im Thread vielleicht auch einen nVidia Ethernetchipsatz?

Da kann ich dich beruhigen, das tritt "schon immer", auch mit SIS735- und VIA KT266A-Chipsatz auf...

Post by *Hacker » 2007-07-21, 14:08 UTC

Kann ich gerne machen (FlashFXP dann vermutlich) - soll ich dann den ganzen Capture irgendwo hochladen?

Die beiden vollen Captures, bei identischen Bedingungen gemacht (ausser FTP Klient) koennten sicherlich Einsicht verschaffen.

Roman

rellek · Post by *rellek » 2007-07-21, 15:07 UTC

Hi,

den TC capture musste ich leider nochmal machen, weil auf dem von heute früh (s. Bildschirmfoto) waren paar unschöne Daten drin *g*
Aber das macht nix. Leider habe ich diesmal "nicht lang genug" gewartet, es kam nach dem Abbrechen-Klick diesmal kein "Verbindung fehlgeschlagen! Neu verbinden?", sondern ein "Fehler beim Herunterladen" und die Verebindung stand erstaunlicherweise noch. Aber dasselbe Spielchen, die Datei skype_info.gif wurde zwar angeblich übermittelt, ist aber nicht auf der Festplatte. Und zwar geht das bis 27084, bei 27093 habe ich dann auf Abbrechen geklickt und bei 27107 dann auf "Verbindung trennen".

Zu FlashFXP gibts nicht zu viel zu sagen, da hat ja alles so geklappt, wie man sich das vorstellen würde... Bei 56303 war er fertig und bei 56311 habe ich dann auf "Quit" geklickt.
Was die IPs angeht, ist noch alles beim Alten, wie heute früh auch.

Ansonsten auch identische Bedingungen, noch nicht einmal ein Neustart war dazwischen

-> http://www.rellek.org/capture-tc.rar
-> http://www.rellek.org/capture-ffxp.rar

HTH

Gruß

Tichy · Post by *Tichy » 2007-07-23, 07:06 UTC

Hacker wrote:rellek
Ich sehe auch, dass du einen nVidia Ethernetchipsatz benutzt. Da gab es Probleme mit, IIRC. Vielleicht ist ja das der gemeinsame Nenner.
Haben die anderen im Thread vielleicht auch einen nVidia Ethernetchipsatz?
TIA
Roman

ich habe eine 3com 3c905B-TX

*wink*
tichy

Tichy · Post by *Tichy » 2007-07-23, 07:09 UTC

Tobi wrote: - Firewall aus/ein (ZoneAlarm)

zonealarm war jahrelang sehr problematisch, weiss nicht, ob das inzwischen soviel besser ist. auch im zusammenhang mit einem apache traten z.b. verschiedene probleme auf. zone-alarm hatte jahrlange einen aehnlich schlechten ruf, wie z.b. norton-produkte. dem wuerde ich nicht mal trauen, wenn es ausgeschaltet ist.

*wink*
tichy

Post by *ghisler(Author) » 2007-07-23, 16:15 UTC

2rellek
Danke für die Wireshark-Captures. Die Datei skype_info.gif beginnt in der tc.pcap bei 8308, bei flashfxp.pcap bei 39595.

In beiden Fällen kommt ein Datenpaket von 1237 Bytes an - die Datei sollte also in beiden Fällen da sein. Was mir auffällt: Total Commander läuft im Portmodus, Flashfxp im Passivmodus. Es kann gut sein, dass die Firewall die Daten noch abfängt, nachdem sie per TCP angekommen sind.

Bitte mal den Total Commander auch im Passivmodus betreiben!

rellek · Post by *rellek » 2007-07-23, 17:07 UTC

Kann ich gerne machen sobald die Leitung mal wieder frei ist *g* Soll ich das dann auch mit Wireshark mitschneiden?

//e Aber Firewall glaub ich fast nicht...
Das einzige, was da aktiv ist, ist die vom cFos: http://www.cfos.de/techinfo/firewall.htm - die Windows-Firewall ist komplett deaktiviert.

Post by *Hacker » 2007-07-23, 20:45 UTC

Soll ich das dann auch mit Wireshark mitschneiden?

Ja, bitte!

Roman

rellek · Post by *rellek » 2007-07-23, 22:49 UTC

Das ist natürlich jetzt *sehr* interessant.

Ich habe mal im TC den passiven Modus aktiviert und der geht tatsächlich sauber bis zum Schluss durch. Außerdem habe ich den Eindruck, dass der passive Modus sehr viel schneller geht als der normale, kann das sein?

Im FlashFXP hat man so den Eindruck, dass der passive Modus gar nicht so richtig zu deaktivieren sein soll - diese Option ist standardmäßig an und sehr gut versteckt. Nachdem ich sie mal ausgeschalten habe, passiert dasselbe wie im TC - Abbruch ohne Vorwarnung

...wobei trotzdem die Frage im Raum stände, warum der TC den passiven Modus nicht auch von sich aus angekreuzt hat, wenn eine neue FTP-Verbindung eingetragen wird oder wenn eine schnelle Verbindung hergestellt wird... Denn ohne Grund wird das ja im FlashFXP (und ich vermute mal ganz stark auch in anderen Clients) nicht als Standard gesetzt sein...

Hier trotzdem die Wireshark-Captures, falls die zur Analyse gebraucht werden sollten

-> http://www.rellek.org/capture-tcpasv.rar (TC mit passiv Modus)
-> http://www.rellek.org/capture-ffxp-nopasv.rar (FlashFXP ohne passiv Modus)

Tobi · Post by *Tobi » 2007-07-25, 12:23 UTC

Habe mal mit Wireshark mein Problem geloggt.
Upload geht im passiven Modus extrem langsam, im aktiven Modus gar nicht.
Download geht übrigens wie immer ohne Probleme.
Diese Probleme traten wie gesagt nach neuer Hardware auf, vorher lief alles einwandfrei.
Im Zip sind drei Dateien. Active/Passive TC und Filezilla, jeweils der Anfang der Dateiübertragung.
Alles läuft ohne Firewall, der FTP Server ist proftpd.

Ich darf noch keine URLs posten, deshalb so:
uddp.de/tobi/capture.zip

Post by *ghisler(Author) » 2007-07-26, 15:56 UTC

Das einzige, was da aktiv ist, ist die vom cFos

Im FlashFXP hat man so den Eindruck, dass der passive Modus gar nicht so richtig zu deaktivieren sein soll - diese Option ist standardmäßig an und sehr gut versteckt. Nachdem ich sie mal ausgeschalten habe, passiert dasselbe wie im TC - Abbruch ohne Vorwarnung

Diese beiden Hinweise deuten darauf hin, dass cFos die Daten im Portmodus blockiert. Im Portmodus werden die Daten ja aktiv vom FTP-Server gesendet (der Server hat die Verbindung aufgebaut), im Passivmodus dagegen baut der Client die Verbindung auf. Klar, dass im Portmodus gewisse Firewalls strenger reagieren...

Lässt sich das Problem auch bei deaktivierter cFos-Firewall reproduzieren?

rellek · Post by *rellek » 2007-07-31, 09:26 UTC

So jetzt bin ich dazu gekommen ohne Firewall zu testen. Zu dem Zeitpunkt war wirklich gar nichts, was den Internetverkehr in irgendeiner Weise hätte hindern können (Windows Defender ist aus, Windows-Firewall ebenso etc und auf dem Server gibts nur die Firewall im cFos und die war zum Testen aus)

Das Ergebnis ist dasselbe wie mit Firewall, nach einer bestimmten Zeit - in dem Fall 6 Minuten - hört der Spaß einfach auf. Und ja, es passiert auch, wenn ich an den Server gehe, dann ist nichts, aber gar nichts, mehr zwischen Rechner und DSL-Modem, also müsste spätestens dann ein Fehler in meinem Wirkungsbereich ausgeschlossen sein.

Davon gibt es aber kein Log weil auf dem Server kein Wireshark drauf ist und auch nicht drauf sollte. Der Server wäre der hier:
http://www.sysprofile.de/id8858
Also auch kein nForce-Netzwerkchip (und wie gesagt auf Papis altem Rechner mit VIA-Chipsatz und -Netzwerkchip hatte ich das Problem auch schon - also dürfte das ziemlich egal sein).

Die Datei, die diesmal hätte übertragen werden sollen, laut Log wurde sie das auch, ist die insertorderedlist.gif bei 14750. Diese existiert auf der Festplatte aber nicht. Bei 14774 hab ich dann auf Abbrechen geklickt und es kam die Meldung, dass nicht verbunden sei, ob ich denn neu verbinden möchte, was ich verneint habe.

Hier der Capture:
-> http://www.rellek.org/capture-port-nofirewall.rar

Hoffe, das hilft bei der Fehleranalyse...

Post by *ghisler(Author) » 2007-08-02, 19:16 UTC

Ganz sicher, dass da keine Firewall mehr mitläuft? Ich hatte schon Fälle von Usern, die hatten z.B. ZoneAlarm ausprobiert, dieses dann aber nicht sauber deinstalliert, sondern nur das Programmverzeichnis gelöscht. Der ZoneAlarm-Treiber läuft dann weiter im Hintergrund, lässt sich aber nicht mehr steuern.

Bitte mal in der Computerverwaltung bei den laufenden Treibern nachsehen, ob da nicht doch noch was mitläuft! Am Mitschnitt (Download ab Paket 7293) ist ja eindeutig zu erkennen, dass das Datenpaket ankommt, und erst danach verschwindet. Bei Paket 7299 kommen 85 Bytes Daten an, wo eindeutig GIF98A drin steht...

rellek · Post by *rellek » 2007-08-02, 19:31 UTC

Hi,

ja ich bin ganz, ganz sicher, dass absolut nichts mitläuft. Auf dem Server, auf dem das Problem ebenfalls reproduzierbar ist, wird nichts probiert. D.h. es wurde, als er Mitte 2005 eingerichtet wurde, aber im April 2006 musste wegen eines Defekts die Festplatte getauscht werden und da hab ich eine Clean-Installation gemacht. Seit dem läuft auf dem Rechner:
- Windows 2000 Pro SP4 (+ Hotfixes via Win-Update)
- AntiVir Personal
- cFos

Zusätzlich ist noch Firefox und Spybot Search&Destroy installiert, die müssen aber beide manuell aufgerufen werden (TeaTimer etc ist aus).
Ansonsten ist, was Treiber angeht, auf dem Rechner wirklich nur das nötigste installiert. Das bringt auch so gut wie alles Windows mit, bis auf den Treiber des OnBoard-LANs, das kommt von SiS.

Aber die 7299 ist ja auch auf der Platte angekommen. Ganz am Ende ist das abgebrochene Paket. Schau lieber bei 14751 nach

Es handelt sich hierbei um den images-Ordner meines Forums. Ich habe einige verschiedene Styles, die z.T. ihre eigenen Buttons und Symbole haben. Daher kommt es mitunter vor, dass manche Dateien vom Namen her mehrmals vorkommen.

Auf dem Rechner, von dem der Log stammt, ist Vista drauf und außer der Windows-Firewall (die aus ist!) hat dieser Rechner in seinem ganzen "Leben" noch keine Firewall aus der Nähe gesehen.

HTH

Gruß

Post by *ghisler(Author) » 2007-08-02, 20:49 UTC

Interessant, da scheinen wirklich Daten zu fehlen!

In Paket 14747 gibt Total Commander die Portnummer an: Die Nummern 194,64 bedeuten 194*256+64 = Port Nummer 49728.

In Paket 14750 fordert Total Commander die Datei insertorderedlist.gif an.

In Paket 14752 bestätigt der Server, dass er die Verbindung aufbaut. In Paket 14753 schliesslich meldet der Server, er habe die Daten erfolgreich uebertragen. Allerdings wurde nie eine Verbindung zu Port 49728 aufgebaut!

Wieso also meldet der Server, er habe die Datei erfolgreich übertragen, wenn nie ein Paket angekommen ist?

Zum Vergleich: Bei der Datei, die bei Paket 7293 angefordert wurde, wurde im Paket 7290 Port Nr. 49553 (193*256+145) festgelegt.

Im Paket 7294 baut der Server die Verbindung zu Port 49553 auf. Dieser Verbindungsaufbau fehlt bei der Datei von Paket 14753 komplett. Trotzdem meldet der Server "erfolgreich übertragen".