Probleme mit FTP und T-Online

Moderator: weneu

Holli

Beitrag von Holli »

JJ hat geschrieben:Antworten auf die Fragen:
- Firewall aktiv, welche Port 21 & 22 sperrt? Beide Ports frei für FTP + UDP
Ich habe gerade mal meinem FTP-Client auf die Finger geschaut: Über Port 21 läuft anscheinend nur die reine Protokollkommunikation mit dem Server. Für die eigentliche Datenübertragung macht er einen weiteren Port oberhalb 32000 auf, und da läuft der Haupttraffic durch. Über Port 21 gehen nur gelegentlich ein paar Bytes.

Kann es sein, daß diese hohen Ports im Router geblockt werden? Gemeinerweise wechseln diese Ports hier bei jeder Übertragung.
Auch der Rechner mit WinXP in der DMZ hört bei 8192 bytes auf.
... aber kein einziges davon kommt beim Server an, nehme ich an.

Würde ins Bild passen:
Der Client teilt dem Server über Port 21 mit: "Hier kommen jetzt x Bytes, guck nach, ob die Checksumme stimmt und sag Bescheid, ob ich das Paket noch mal schicken muß oder ob das nächste kommen kann."
Server: [wartet auf Daten, die nicht kommen und schweigt]
Client: "Wenn der Typ keine Antwort gibt, kriegt er auch keine Daten mehr." [schmollt und kappt die Verbindung]

Da das Problem bei allen Rechnern auftritt, kann eigentlich nur der Router mit seiner eingebauten Firewall auf der Leitung stehen.
JJ

Nun ist das Chaos perfekt

Beitrag von JJ »

Hallo zusammen,

nun ist die Ratlosigkeit bei uns hier perfekt. :?

Holli, Dein Hinweis von gestern Nacht hat bei uns den Suchtrieb ausgelöst und ich habe heute so im Web rumgesucht. Dein Hineis auf die beiden Kommunikationskanäle, dass nicht alles über die 20er Ports abgewickelt wird, sondern die Daten über einen weiteren Port im 1000der Bereich stattfindet, war Anlass in den Optionen im FTP-Programm zu stöbern.

Holli, Dein Hinweis war gold wert, danke nochmals.

Bei bulletproof hat mein Sohn eine Einstellung gefunden, dass nicht dynamisch die oberen Ports vergeben werden, sondern in einem fest definierten Bereich Vorgaben und Einschränkungen gemacht werden können.

Nach Umstellung und Freigabe aller Ports auf unserem Router hatten wir Erfolg und konnten ungehindert auf unseren T-Online-Server bzw. bei dir Holli zugreifen.
Haben schrittweise die Eintragungen im Router zur Freigabe von Ports zurückgenommen bis alle Eintragungen wieder raus waren und der upload funkte immer noch.

Waren sehr erfreut, eine Lösung gefunden zu haben, aber...

Das Ganze war dann aber nicht jedesmal reproduzierbar, mal funkte es mal nicht :evil:

Keine dauerhafte Lösung, schon gar nicht auf meinen Stammrechner übertragbar.

Dann habe ich aus lauter Verzweifelung meinen LAPTOP von der Arbeit ausprobiert, ist ein Gerät, dass bei uns im Firmennetz täglich eingesetzt wird und mit Virenscanner und allem versehen und konfiguriert ist, was einem Großunternehmen in der Stahlindustrie alles so einfällt, um die Rechner abzusichern. Im Firmennetz ist FTP nicht möglich, alle relevanten Ports sind dicht, aber bei mir zuhause kann ich das Laptop ins Netz nehmen und ich bekomme Internetzugang.

Und siehe da, mein Laptop macht zuhause über FTP alles das, was ich schon immer machen wollte.

Verbindung zu T-Online, habe das Verzeichnis, gelöscht und mal locker so eine Homepage-Vorlage von selfhtml raufgeladen. Hat gefunkt :P

Aber mein Stammrechner, der auch über WLan raus geht und auf dem meine Wettersoftwar läuft, hat seine ftp-Probleme weiterhin. Der Rechner von meinem Sohn ist mal so mal so.

Jetzt muss ich wohl in den sauren Apfel beissen und die Konfiguration der Rechner vergleichen. Habe aber keine Ahnung, wie und wo ich da anfangen soll.

Vielleicht hat jemand nach meiner Teilerfolgsstory eine Idee, wie ich da sinnvoll rangehen sollte.

Nochmals danke an alle, die mir Ihre Aufmerksamkeit schenkten und Zeit für mich und mein Problem hatten. :wink:
Holli

Re: Nun ist das Chaos perfekt

Beitrag von Holli »

JJ hat geschrieben:Nach Umstellung und Freigabe aller Ports auf unserem Router hatten wir Erfolg und konnten ungehindert auf unseren T-Online-Server bzw. bei dir Holli zugreifen.
Haben schrittweise die Eintragungen im Router zur Freigabe von Ports zurückgenommen bis alle Eintragungen wieder raus waren und der upload funkte immer noch.

Waren sehr erfreut, eine Lösung gefunden zu haben, aber...

Das Ganze war dann aber nicht jedesmal reproduzierbar, mal funkte es mal nicht :evil:
Da würde ich auf die zufällige Wahl des Ports tippen. Mal wird einer genommen, der nicht geblockt wird, und beim nächsten Mal eben nicht. Da hilft wohl nur, einen begrenzten Bereich offenzulassen und das FTP-Programm auf diesen Bereich festzunageln. Ob HS-Upload so eine Option hat, weiß ich nicht. Und ich weiß auch nicht, wie groß der Bereich sinnvollerweise sein müßte. Wenn HS-Upload für jede Datei einen neuen Port nimmt und die zuletzt geöffneten nicht schnell wieder freigibt, kann es mit 20 offenen Ports schnell eng werden. Keine Ahnung, wie HS-Upload da vorgeht.
Und siehe da, mein Laptop macht zuhause über FTP alles das, was ich schon immer machen wollte.
Dazu reicht ja, daß das FTP-Programm (zufällig) einen Bereich mit offenen Ports gewählt hat oder so intelligent ist, die Ports so lange zu probieren, bis ein freier gefunden ist.
Jetzt muss ich wohl in den sauren Apfel beissen und die Konfiguration der Rechner vergleichen. Habe aber keine Ahnung, wie und wo ich da anfangen soll.
Bei den von den Programmen benützten Ports. Nach den letzten Tests liegt es ziemlich sicher daran.

Eigentlich ist es auch unkritisch, diese Ports offen zu lassen. In diesem Bereich lauscht sowieso kein "ordentliches" Programm. Und Trojaner lassen sich von solchen "Kleinigkeiten" normalerweise nicht aufhalten. Wenn sie in diesem Portbereich nicht durchkommen, dann eben woanders.

Einen halbwegs vernünftigen Schutz dagegen kann man nur mit einer Firewall erreichen, die sich im Detail konfigurieren läßt, also für genau definierte Programme genau definierte Adreß- und Portbereiche freigibt, wie z.B. die Kerio. Sicher ist man bei einer Firewall, die auf dem zu schützenden Rechner läuft, allerdings nie.

Ich habe hier die Kerio laufen. Allerdings nicht, um mich in Sicherheit zu wiegen, sondern mehr, um den ein- und ausgehenden Traffic beobachten zu können. So sieht man schnell, mit welchem Server über welche Ports manche Programme quatschen, und wenn man Lust hat, kann man dieses Gequatsche unterbinden. Hauptsächlich dient es aber der Problemanalyse wie bei dir jetzt.
Vielleicht hat jemand nach meiner Teilerfolgsstory eine Idee, wie ich da sinnvoll rangehen sollte.
Die neuen Kerio-Versionen schleppen ziemlich viel überflüssigen Ballast mit rum und quatschen ungefragt mit "zu Hause". Deshalb habe ich mir extra eine alte 2.x aufgehoben, die sich auf das Nötigste beschränkt, aber freie Sicht auf den gesamten Netzwerkverkehr eines Rechners gibt. Und die Installationsdatei dafür ist mir gerade ganz aus Versehen in dein Test-Verzeichnis gerutscht :D
JJ

Die Arbeit kann beginnen.

Beitrag von JJ »

Na dann will ich mich mal auf die Suche und Socken machen.

Danke und schön Abend noch :wink:
JJ

Das Problem ist gelöst!!

Beitrag von JJ »

Hallo zusammen,

habe lange nichts von mir hören lassen, kann aber jetzt erfolgreichen Vollzug melden. :D

Um die Sache abzukürzen, es lag bei mir an der MTU-Einstellung. Fragt mich bitte nicht, was das genau ist, kann ich nicht beantworten.

Ich habe solange eine Menge anderer Leute genervt, bis sie jetzt mit einer Lösung kamen und nun vor mir Ruhe haben :wink:

Wer auch das Problem hat oder haben wird, sollte hier mal vorbei schauen:

http://support.microsoft.com/kb/814542/DE/

oder

http://support.microsoft.com/kb/314053/DE/

oder

http://www.informationsarchiv.net/foren ... 96794.html

Aus letztgenanntem Beitrag kam die Spur auf MTU-Größe und bei Microsoft fanden wir den Hinweis auf einen Ping-Versuch, womit wir herausfinden konnten, welche MTU-Größe der Server überhaupt abkann.

Bei mir (T-Online) sind es 1450, leider nicht die 1492, die das FTP-Optimierungstool vorgeschlagen hatte und somit zunächst keinen Erfolg brachte :( .

Bei den meisten der Netzwerkkarteneinstellungen der verschiedenen XP-Rechner stand der MTU-Wert auf 1500, also eine Größe, die der Server nicht konnte oder wollte. :cry:

So, nun kann ich an die nächsten Sachen rangehen, mal sehen, wie oft und ab wann ich wieder andere nerven muss, weil ich alleine nicht weiter komme. :wink:

Danke nochmals an alle, die ihre Zeit für mich geopfert hatten.

Werde bald meine Wetterseite aus dem Duisburger Norden aufschalten, hier schon mal der Link: www.froehlichkeit-online.de
Holli

Re: Das Problem ist gelöst!!

Beitrag von Holli »

JJ hat geschrieben:Um die Sache abzukürzen, es lag bei mir an der MTU-Einstellung. Fragt mich bitte nicht, was das genau ist, kann ich nicht beantworten.
Och, das ist nicht so schwer zu erklären: Das ist die maximale Paketgröße, die am Stück durchs Ethernet geschickt wird. Sie ist standardmäßig 1518 Bytes, wovon 14 Bytes für den Header (Absende-, Zieladresse usw.) und 4 Bytes für die Prüfsumme abgehen. Bleiben fürs Ethernet also 1500 Bytes.
Aus letztgenanntem Beitrag kam die Spur auf MTU-Größe und bei Microsoft fanden wir den Hinweis auf einen Ping-Versuch, womit wir herausfinden konnten, welche MTU-Größe der Server überhaupt abkann.

Bei mir (T-Online) sind es 1450, leider nicht die 1492, die das FTP-Optimierungstool vorgeschlagen hatte und somit zunächst keinen Erfolg brachte :( .
Das ist aber schon komisch. Diese 8 Bytes gehen noch mal für den Header des PPoE, das "DSL-Protokoll", weg. 1492 habe ich bei mir schon seit Jahren drinstehen und weder mit noch ohne Router ein Problem gehabt, und das ebenfalls bei T-Online.
Bei den meisten der Netzwerkkarteneinstellungen der verschiedenen XP-Rechner stand der MTU-Wert auf 1500,
Ist für reines Ethernet (LAN und WLAN) ja auch richtig. Bei DSL wird aber ein zusätzliches "Protokoll im Protokoll" in dem Paket verpackt. Deshalb müßten an sich 1500 Byte-Pakete in zwei Pakete, eins von 1492 Bytes und eins von 8 Bytes, zerlegt werden. Da das 8 Byte-Paket aber auch seine 8 Bytes PPoE-Header und 18 Bytes für das Ethernet braucht, kann man sich denken, daß das nicht gerade zu rekordverdächtigen Geschwindigkeiten führt. Und wenn dann der Router (oder irgendein Router unterwegs) auch noch das "Bitte nicht zerlegen"-Flag setzt, kann das Paket überhaupt nicht mehr transportiert werden.
also eine Größe, die der Server nicht konnte oder wollte. :cry:
Vermutlich war nicht der Server schuld, sondern irgendein Knoten auf der Strecke zu ihm.

Ich kann mir nicht vorstellen, daß bei dir noch mal ganze 42 Bytes für irgendeinen Header oder sowas weggehen. Vermutlich erreichst du jetzt also nicht die maximal mögliche Geschwindigkeit, aber es ist auf jeden Fall schneller als mit wegen wenigen Bytes fragmentierten Paketen.

Aber egal, wenn es so zuverlässig funktioniert, dann pfeif auf die letzten 3% Geschwindigkeit.
Werde bald meine Wetterseite aus dem Duisburger Norden aufschalten, hier schon mal der Link: www.froehlichkeit-online.de
Na, dann ist die Ecke hier aber mehr als gut versorgt mit privaten Stationen :D
Auf Anhieb fallen mir in Dinslaken, Duisburg, Oberhausen und Essen acht private Wetterstationen ein. Und wahrscheinlich kenne ich noch nicht mal alle.
Antworten