FTP-Uploadprobleme

[shh]

Habe FTP-Uploadprobleme.

Effekt:
Uploads werden dauernd abgebrochen (hochgeladen wird nur ein paar sek.). Reconnecten dauert dann ewig, es kommt auch oft ein timeout.
Generell müsste es dann zumindest klappen, aber das letzte Paket (zum upload abschliessen) kommt dann offenbar überhaupt nicht durch. => Upload bleibt bei 99% stehen.
Downloads klappen tadellos. Auch jegliche Verbindungen mit ´nem anderen Protokoll.

Ich sitze hier an nem Clientrechner, der INet-Verbindung via SNAT hat. Router/Gateway ist ein GNU/Linux-Server, der mit ADSL online ist (mit pppd & pppoe).
Firewall habe ich auch mal abgeschalten, daran hängt's nicht.

Könnte es sein, dass wegen falschen MTU-Werten einige Pakete getrennt werden mussen, und daher verschluckt werden (insb. beim FTP-Protokoll)?
MTU habe ich 1454 eingestellt, was normalerweise "optimal" sein soll.

Sind irgendwelche Probleme bekannt, die mit den Modulen vom Kernel v2.6.2 ip_conntrack_ftp oder ip_nat_ftp zu tun haben?
_________________
shh >>> shh's MPEG-tools

[grettsche]

Hi shh,

versuch bitte den MTU Wert mal auf 1460 zu stellen. Ein passiver Transfermodus sollte auch eingestellt sein.

grettsche

Nachtrag: Es gibt da nen kleines lustiges Programm mit Namen DFÜ-Speed, da kann man ganz bequem den MTU-Wert und den anderen Rödel einstellen. Gibt natürlich da noch duzende andere Programme. ;-)

DFÜ-Speed

DSL FAQ

Achso, DFÜ-Speed schlägt glaube für ADSL 1492 vor, bitte von Hand in 1460 ändern.



Zuletzt bearbeitet von grettsche
_________________
Gruss grettsche
Man muss nicht alles glauben was stimmt.

[bergH]

tach auch !

Gut , daß grettsche das bestätigt, bei dem niedrigen MTU Wert habe ich auch gemacht.
Es gibt Router , die laufen am besten mit 1492 , oder sogar 1500.
_________________
Gruß BergH

[grettsche]

Ja und unsere "Man ist das einfach - AOL-Kunden" brauchen 1400 und nen schrecklich netten transparenten Proxy.
_________________
Gruss grettsche
Man muss nicht alles glauben was stimmt.

[shh]

> Es gibt Router , die laufen am besten mit 1492 , oder sogar 1500.

1500 geht nur, wenn man vom LAN nichts vorwarden möchte. (Im Grunde ist's dann kein router mehr).
1492 läuft normalerweise, aber 1454 ist ein besserer Wert. Siehe: http://www.debianforum.de/wiki/?page=Die+Optimale+MTU+f%FCr+ADSL

> versuch bitte den MTU Wert mal auf 1460 zu stellen

Wo? Am Client oder am Server? Bei beiden? (irgendwie bin ich jetzt schon total planlos)
Beim Client (Windows XP) hatte ich eine standardmässige MTU von 1300 drin. Eine zu-kleine-MTU sollte doch immer laufen, oder?
Wie kommt man überhaupt auf 1460??

> Ein passiver Transfermodus sollte auch eingestellt

Ist an.

Habe jetzt auch jede Menge experimentiert.
Ändern der MTU bringt hier überhaupt nichts. Nur dass es noch schlimmer werden kann.

Ich habe jetzt eine Einstellung, die mit (fast) allem gut fuktioniert.
Server:
MTU: 1454 (was einen besseren Durchsatz ermöglichen sollte)
MSS-Clamping 1414 (=40 Bytes kleiner als MTU. Siehe: http://www.sauff.com/dsl-faq/mtu-mini-faq.html#1.5 )
Client:
MTU: 1454

Nur - immer noch -  bei FTP-Uploads gibt's Probleme.
Resumen geht nicht bei shh.dvdboard.de und pu.hb1-frankfurt.de. Da wird immer wieder probiert, gewartet und abgebrochen.
Eigenartigerweise klappt resumen auf meinem Webspace IP 82.96.87.152 tadellos.
Helmut ist doch auch bei Glovi... wieso geht's da nicht?
_________________
shh >>> shh's MPEG-tools

[grettsche]

Hi shh,

Ich meinte natürlich am Clienten, da ich ja nicht wusste, das Du auf den Server Einfluss nehmen kannst!

Ein zu kleiner MTU Wert hat den Nachteil, das die Adressinformationen nicht mehr in das Adressfeld passen und somit das Paket entweder aufgesplittet wird oder halt verworfen wird. Hängt aber vom Server ab, wie der konfiguriert ist. Ist der MTU-Wert jedoch etwas grösser als für das Adressfeld benötigt wird, dann passen etwas Nutzdaten mit rein, jedoch wahrscheinlichzu wenig. Folge davon wäre, dass mehrere Pakete verschickt werden müssen um eine Datei zu übertragen.

shh, ich kanns net genau erklären, bin nur ein Helpdesk-Mitarbeiter. Aber hast Du denn nun den Wert 1460 ausprobiert?

Ist der MTU-Wert zu groß kann es passieren das Pakete gar nicht erst versendet werden oder halt vom Router selbst aufgesplittet werden. Das Ergebnis ist, entweder werden gar keine Daten übertragen oder nur sehr langsam. Das ist alles ne ziehmliche Sch... das gesunde Mittelmaß ist halt entscheidend und der Router samts Software.

Bezüglich euren kleinen FTP-Server wird das definitiv an der verwendeten Serversoft liegen die kein Resume unterstützt! Aber das hatten wir ja schon mal hier stehen.

grettsche
_________________
Gruss grettsche
Man muss nicht alles glauben was stimmt.

[shh]

> Aber hast Du denn nun den Wert 1460  ausprobiert

Ja. Ändert nix.
Ich hab auch schon 1000 ausprobiert (am Client). Ändert auch nix.

> Bezüglich euren kleinen FTP-Server wird das definitiv an der verwendeten Serversoft liegen die kein Resume unterstützt

Er schreibt aber:
STATUS:>   This site can resume broken downloads.
??

Ich vermute immer mehr, dass das an meinem Provider (Tiscali DFN@home) liegen muss. Der Zeitraum der Umstellung von T-Online passt ungefähr.
_________________
shh >>> shh's MPEG-tools

[grettsche]

Nun ja, ein Versuch wars allemal wert. Kann es sein das es an der verwendeten FTP-Software liegt die Du verwendest? Hast Du schon mal versucht NUR mit dem IE Dateien hochzuschaufeln?

STATUS:> This site can resume broken downloads.

Die Meldung ist gut, dann sollte sich der Server gefälligst auch drann halten. ;-) Sorry shh, das Problem erschliest sich mir nicht gänzlich. Du verwendest LINUX? o.K. das war ein anderer Thread.
_________________
Gruss grettsche
Man muss nicht alles glauben was stimmt.

[shh]

> Nun ja, ein Versuch wars allemal wert

Ja, klar. Dank euch für die Tipps!

> verwendeten FTP-Software

Mit CuteFTP und neueste WS FTP LE ausprobiert.
Der Effekt ist der gleiche.

> Du verwendest LINUX

Am Server/Gateway/Router, ja. (Kernel 2.6.x aber erst seit ein paar Monaten)
Und an meinem Client zT (bei meiner Frau sowieso).
Hmm... muss mal probieren ob ich (und meine Frau) unter Linux das gleiche Problem habe, und auch mal mit dem IE...
Aber, Schmarrn. Mit dem IE hochladen probieren bringt ja auch nichts: Der kann ja auch nicht resumen.

Das Problem hatte ich früher aber nicht.
Jetzt kann's alles mögliche sein.
- Provider Tiscali DFN@home, bei dem ich seit einigen Monaten bin (vorher T-Online)
- Seit einem dreiviertel Jahr etwa ein Nforce2 board (ich verwende den internen NIC)
- WinXP auch ungefär so lange (vorher Win2k)
...oder es hat einer dieser 1000 patches von M$ wieder mehr kaputt gemacht, als gerichtet.

Argl... dass man sich dauernd das Windows (diesmal XP) zerschiessen kann/muss, sodass nichts mehr vernünftig geht??
Bei meinem GNU/Linux Server habe ich zuletzt vor über 5 Jahren ein System aufgesetzt und das auch nur, weil ich von SuSE auf Debian umgesteigen wollte.
Naja, Windows-Haltbarkeitsdatum ist ja schon wieder überschritten, was beklage ich mich. Mitterweile habe ich das System ja schon ein halbes Jahr ohne Neuinstallation drauf.
_________________
shh >>> shh's MPEG-tools

[bergH]

tach auch !

Hast Du mal den Windows/Total Commander probiert ?
Dessen FTP Client ist gut und läßt sich vielseitig configurieren.
Ich habe damit schon Sachen upgeloaded, wo andere FTP-Cleints kläglich versagt haben.
_________________
Gruß BergH