Kein Binary-Download von ftp Server möglich...

Softwaretester

Neuer User
Mitglied seit
2 Okt 2006
Beiträge
8
Punkte für Reaktionen
0
Punkte
0
Hallo,

nach eifrigem Studium des Forums habe ich bisher keine Antwort auf mein Problem gefunden und hoffe, durch eine Anfrage eine Antwort zu finden.

An eine FritzBox 7050 (älteres Modell ohne USB Schnittstelle für Festplatte) mit aktueller Firmware ist über eine Netzwerkschnittstelle ein externe Festplatte (ICYBOX IB-NAS2000) angeschlossen.

Über WLAN ist die Festplatte ohne Probleme erreichbar.

Auf der FritzBox ist der Port 21 per "forwarding" auf die IP der Festplatte weiter geleitet.

Bei DynDNS ist für die temporäre IP Adresse meines DSL Anschlusses eine dynamische IP eingerichtet.

Beim FTP Zugriff über das Internet mittels der Anwendung FileZilla kann man sich ohne Probleme am FTP Server der Festplatte anmelden.

Ein UPLOAD von Dateien funktioniert sowohl im ASCII als auch im binary mode. Allerdings ein DOWNLOAD funktioniert nur im ASCII nicht im binary mode.

Wird versucht ein Download im binary mode zu starten, dann bleibt der Download schon am Anfang hängen und FileZilla meldet nach einiger Zeit den Abbruch und einen weiteren Versuch, der allerdings auch nicht funktioniert.

Ich stehe vor einem Rätsel, da eigentlich alles funktioniert wie es sollte, nur der Downlload im binary mode nicht. :confused:

Bin allen dankbar für Ideen, wie das Problem zu lösen. :D

Viele Grüße,
Softwaretester.
 
hast du in deinem verwendeten FTP-Programm den "Passive-Modus" eingestellt ? sollte helfen
 
Softwaretester schrieb:
Bin allen dankbar für Ideen, wie das Problem zu lösen.
Um das klären können, wäre ein Mitschnitt der IP-Pakete auf dem Control- und dem Data-Port hilfreich.
Das FTP-Protokoll ist nicht so kompliziert zu lesen, zumindest nicht auf dem Control-Port (21), wo alles in ASCII ist. Wenn dort keine explizite Fehlermeldung zu finden ist, die Aufschluß über das Problem gibt, handelt es möglicherweise um ein Timing-Problem.
 
Zunächst Dank für die Antworten.

Der Passive Mode beim FTP Client (diesmal SmartFTP) ist eingeschaltet.

Das Protokoll für einen misslungenen Download sieht so aus:
(habe meine IP Adresse im Protokoll auf 127.1.1.1. geändert, sie lautet natürlich anders)

[15:28:40] 227 Entering Passive Mode (127,1,1,1,240,59).
[15:28:40] Opening data connection to 127,1,1,1 Port: 61499
[15:28:40] RETR tech.JPG
[15:28:40] 150 Opening BINARY mode data connection for tech.JPG (282058 bytes)
[15:29:20] Transfer Timeout (40s). Closing data connection.
[15:29:20] 0 bytes transferred. (0 Byte/s) (00:00:40)
[15:29:55] MDTM tech.JPG
[15:30:46] NOOP
[15:31:26] Timeout (40s).
[15:31:26] Active Help: http://www.smartftp.com/support/kb/index.php/74
[15:31:26] Client closed the connection.

Für einen gelungenen UPload sieht es so aus:

[15:37:08] 227 Entering Passive Mode (127,1,1,1,240,88).
[15:37:08] Opening data connection to 127,1,1,1 Port: 61528
[15:37:08] STOR tech.JPG
[15:37:09] 150 Opening BINARY mode data connection for tech.JPG
[15:37:15] 282058 bytes transferred. (41,5 KB/s) (00:00:06)
[15:37:15] 226 Transfer complete.

An welcher Einstellung könnte man etwas ändern? :noidea:
 
Da der Upload ja funktioniert und ebenso der ASCII-Download, scheint die Adreß-Umsetzung im Router nicht das Problem zu sein, sonst ginge gar nichts.

Das Problem scheint vielmehr zu sein, daß der Client die Data Connection nicht aufbaut, nachdem der Server den Port (mit der Nummer 61499) geöffnet hat.
Der Server läuft dann nach 40 Sekunden in einen Time-out. Weil in dieser Zeit kein (korrektes) TCP-Connect auf dem Port erfolgt ist, schließt der Server den Port wieder.

Ich fürchte, da kann man an der Einstellung nicht viel ändern. Mein Rat wäre gewesen, einen anderen FTP-Client zu verwenden. Aber das hast du ja schon.

Interessanter als ein Vergleich mit einem erfolgreichen Upload wäre übrigens der Vergleich mit einem erfolgreichen ASCII-Download gewesen.

Leider sieht man auch nur die Control-Verbindung, nicht die dynamisch aufgebaute Datenverbindung, über die der eigentliche Datenaustausch erfolgt.
Ein vollständiger TCP-Mitschnitt z.B. mit Ethereal oder Wireshark würde zeigen, ob überhaupt und wenn ja wann genau der Client versucht, die Data Connection zu öffnen.

Edit: Moment!! Der Timeout wird wohl vom Client angezeigt und nicht wie zuerst angenommen vom Server über die Control-Verbindung gesendet (kann man leider im Logg des Clients nicht wirklich unterscheiden).
Dafür spricht, daß der Client anschließend noch 2 Kommandos, insbesondere das NOOP sendet, auf das der Server nicht antwortet. Die Ursache für das Problem liegt dann auf der Server-Seite.
 
Zuletzt bearbeitet:
Habe ich deine Ausführungen richtig verstanden, dass der Fehler auf dem Server zu suchen ist? Das wäre dann die ICYBOX IB-NAS2000 mit dem FTP-Server.

Über die Managment Oberfläche ist auf der Box nur der FTP Server einzuschalten und die Portadresse angebbar. Leider nicht viele Möglichkeiten der Konfiguration...

Wenn du zur weiteren Analyse ein detailliertes Protokoll benötigst, wie kann man dieses erstellen? Welche Anwendung müsste parallel zum FTP Client laufen?
 
Genaue(re)s kann man wirklich nur anhand eines kompletten TCP-Mitschnittes sagen; "komplett" im dem Sinne, daß die ganze FTP-Session und beide Connections enthalten sind.

Dazu mußt du auf der Client-Seite "Wireshark" installieren (ist kostenlos und ist z.B. auf der CD in der aktuellen c't enthalten) und starten.
Damit kannst du den erforderlichen Mitschnitt aller Pakete auf dem verwendeten Netzwerk-Interface (= LAN- oder WLAN-Karte) zum Internet vornehmen (Menüpunkt "Capture").
Den Mitschnitt kann man dann in eine Datei sichern (s.u.).

Da auf einer Netzwerk-Karte meistens noch ein bißchen mehr läuft, solltest du zunächst die TCP-Pakete herausfiltern, die zwischen dem PC und dem FTP-Server gelaufen sind. Alles andere ist uninteressant.
Wichtig ist nur, daß beide Verbindungen, also Control- und Data-Connection, enthalten sind. Deshalb darf der verwendete Paket-Filter keine Einschränkungen bzgl. der Port-Nummern machen.
Beispiel für den Filter "(ip.addr eq 10.0.0.123 and ip.addr eq 80.100.123.234)".

Für den Mitschnitt solltest du vorübergehend das Paßwort am FTP-Server wechseln, weil dieses im KLARTEXT über das Internet geht und somit auch im Klartext in den TCP-Paketen zu lesen ist.

Den (kompletten) Mitschnitt kann du dann als binäre PCAP-Datei sichern oder als Text-Datei exportieren. (Wie man mit "Wireshark" nur die auf einen Filter passenden Pakete sichert, habe ich allerdings bisher auch noch nicht herausgefunden.)
 
Hier habe ich einen Mitschnitt mit WireShark (ein wirklich sehr ausführliches Programm, guter Tipp!!!) als pcap Datei.

Leider kann ich das Protokoll nicht eindeutig lesen.

Falls sich jemand die Mühe machen sollte, in das Protokoll zu schauen, wäre ich sehr dankbar dafür.

Zunächst wurde erfolgreich eine Datei mit Namen indy1.jpg "upgeloadet" und danach der Versuch gestartet, die gleich Datei "downzuloaden".

Es ist sofort zu erkennen, dass beim Download Segmente verloren gehen.

Nochmals Dank für die Unterstützung hier im Forum.


Viele Grüße
Softwaretester
 

Anhänge

  • Upload_Download.zip
    7.7 KB · Aufrufe: 4
Hallo.

In dem Wireshark-Mitschnitt fehlen sämtlich TCP-Pakete auf der Data-Connection in der Richtung vom Client zum FTP-Server.
Im oberen Teil sind das die Pakete von 10.277.158.248, 1266 nach 84.176.192.1, 61675, im unteren Teil die Pakete von 10.227.150.248, 1268 nach 84.176.192.1, 61677.

Darum sieht man auch den kompletten 3-Wege-Handshake beim Aufbau der Data-Connections nicht. Im Paket 74 z.B. ist ein SYN,ACK zu sehen, aber das zugehörige SYN, das davor hätte stehen müssen, ist nicht zu finden.
 
Dank für deine Analyse RiVen.

Was ist die Schlußfolgerung deiner Analyse:

Ist das Protokoll nicht ausfürhlich genug, da ich nur einen Teil der Kommunikation abbildet habe, d.h. sollte ich ein ausführlicheres Protokoll ablegen.

Oder ist die Kommunikation beim Download gestört? Funktioniert der FTP Server auf der Festplatte nicht richtig?

Was kann man machen? Sollte ich mich an den Support wenden wegen einer Reklamation?

Dank nochmals für die Antworten :)
 
Hallo.

Das "bemängelte" Fehlen der TCP-Pakete sollte nur ein Hinweis darauf sein, daß der Mitschnitt selbst nicht vollständig ist. Man sieht nur 3/4 der relevanten TCP-Pakete.

Bitte wiederhole den Mitschnitt und achte darauf, daß die Pakete beider Verbindungen (Control und Data) in beiden Richtungen enthalten sind.

Sollten die Pakete der einen Richtung bei der Data-Connection wieder nicht im Sniffer-Protokoll enthalten sein, liegt das
- entweder an deiner Netzwerk-Karte (gibt nicht alle Paketdaten an den Sniffer weiter)
- oder am Sniffer Wireshark (protokolliert nicht alles)
- oder an deiner Netzwerk-Infrastruktur (Pakete gehen einen anderen Weg als über das ge-sniff-te Netzwerk-Interface).

Der letzte (eher unwahrscheinliche) Fall könnte aber u. U. auch der Grund für deine FTP-Download-Probleme sein.

Wie testest du eigentlich? Hängen Client und Server am selben DSL-Anschluß bzw. DSL-Router?
 
Ok.

Hier ein weiterer Versuch: Das Protokoll beginnt erst nachdem ich mich eingeloggt habe auf dem FTP Server.
Ich habe nicht sehen können, dass WireShark irgendwelche Daten nicht protokollieren würde.

Ich teste mit einer UMTS Card von Vodafone an einem Notebook (Client) und der anderen Seite dem Router (Server) DSL Anschluß in meiner Wohnung.

Ich habe auch schon mit demselben DSL Anschluß für Client und Router getestet.
 

Anhänge

  • Upload_Download_2.zip
    8.7 KB · Aufrufe: 3
Tja. Es ist nicht besser geworden.
Auch hier fehlt wieder die eine Hälfte der TCP-Pakete auf den Data-Connections, auch bei den zwischenzeitlichen beiden Directory-Abfragen zum FTP-Server :-(

Hängt dein Notebook denn zusätzlich (zur WAN-Verbindung über UMTS-Karte) noch per LAN oder WLAN am DSL-Router?

---

Nachtrag:

Daß die TCP-Pakete nicht im Wireshark-Trace auftauchen, liegt möglicherweise daran, daß du die Tests mit der UMTS-Karte durchführst, die offensichtlich eine Ethernet-Netzwerk-Karte emuliert.
Letztendlich wird ja PPP als Träger-Protokoll zwischen PC und UMTS-Karte benutzt und kein Ethernet. D.h. die im Wireshark angezeigten MAC-Adressen sind nicht real.

Eine weitere Besonderheit bei der Verwendung einer UMTS- (oder GPRS-)Karte ist, daß dein PC im allgemeinen eine private (!) IP-Adresse zugewiesen bekommt (das ist abhängig vom verwendeten APN) und somit eine weitere Netzwerk-Adreßumsetzung zwischen den Endgeräten stattfindet, nämlich bei Vodafone.

Die Ursache des Problemes liegt meiner Meinung nach weder am FTP-Client noch am FTP-Server, sondern an der fehlerhaften oder gestörten IP-Verbindung zwischen den beiden Programmen.
FTP-Client und -Server scheinen normal zu funktionieren, aber auf IP-Ebene kommt es zu massiven Störungen.

Zur weiteren Eingrenzung des Problemes würde ich vorschlagen, daß du einen binären Datei-Download von einem anderen, öffentlich zugänglichem FTP-Server im Internet versuchst (z.B. von AVMs FTP-Server mit den Fritz!Box-Firmware-Versionen).
Wenn du damit die gleichen Probleme hast, liegt es am ehesten an der UMTS-Karte (bzw. deren Treiber) oder am Internet-Zugang über die UMTS-Karte.

----

Noch ein Nachtrag:

Möglicherweise mußt an deinem DSL-Router wegen des verwendeten FTP-Passive-Modus' auch für die Data-Connection Port-Forwardings einrichten.
Damit du das nicht für alle möglichen Port-Nummern machen mußt, solltest du am FTP-Server den Bereich einschränken, aus dem der Server die Port-Nummern für die Data-Connection nimmt.
D.h. es sollte eine Einstellung wie
PassivePorts 60000 60100
am FTP-Server und im Router eine entsprechende Port-Range-Weiterleitung zum NAS-Rechner vorgenommen werden.
 
Zuletzt bearbeitet:
Nas-2000

Ich habe das gleiche Problem mit zwei NAS Boxen diesen Typs und konnte noch ein wenig rausfinden - allerdings habe ich hierzu auch keine Lösung.

Binary Downloads funktionieren überhaupt nicht.
ASCII Downloads funktionieren bei relativ kleinen Dateien oder bei einer Beschränkung der Transferrate auf max 10kByte.

Ich habe die Vermutung, dass die Kisten nicht ganz sauber durchdacht sind und somit doch einige Fehler haben. Auch sehr merkwürdig ist, dass sich das NAS-2000 als NAS-1000 identifiziert....:mad:
 
Nas-2000

Ich habe noch einige Tests mehr gemacht und die Vermutung, dass hier ein paar Timings nicht stimmen, hat sich erhärtet. Folgende Erkanntnisse:

1. Test im LAN - lesen funktioniert Reibungslos
2. Test im externen Netzwerksegment:

Ich bin in der glücklichen Lage über mehrere externe IP-Adressen zu verfügen, so habe ich folgendes Setup aufgebaut:

Externer Switch (HP) verbunden mit Internet,NAS-2000 und zwei Computern im externen Segment. Keine Router oder ähnliches. Rechner1 steht physisch neben dem NAS-2000 (Kabel ca 1-2m). Rechner2 steht entfernt (Kabel ca. 25-30m). Rechner3 ist ein Rechner im Internet. Die Netzwerkverbindungen laufen schon sehr lange und sind zuverlässig.

Rechner1 kann im Binärmodus scheinbar alle Dateien lesen (ähnlich LAN). Rechner2 kann nicht mehr alle Dateien lesen. Nur Binärdateien <40kB machen keine Probleme. Rechner3 kann nur noch Dateien <4kB lesen.
:mad:
 
Hallo NAS-geplagte,

auf der Suche nach "Leidensgenossen" mit dem NAS2000 stieß ich auf Euren Thread. Meine Vermutung, insbesondere nach der Lektüre des letzten Beitrages, ist eine Frame-Segmentierung als Ursache Eurer Probleme.

McDac schrieb:
Ich habe noch einige Tests mehr gemacht
...
Rechner1 kann im Binärmodus scheinbar alle Dateien lesen (ähnlich LAN). Rechner2 kann nicht mehr alle Dateien lesen. Nur Binärdateien <40kB machen keine Probleme. Rechner3 kann nur noch Dateien <4kB lesen.
:mad:

Das FTP-Protokoll ist - dank seines Alters - nicht in der Lage, mit fragmentierten Paketen, also "zerstückelten" Daten umzugehen. Diese werden verworfen, entsprechend fehlen Daten. In Folge dessen wird der komplette Up-/Download für ungültig erklärt und verworfen.
Ursache für die Fragmentierung ist die MTU (Maximum Transfer Unit, Angabe in Bytes pro Frame) in einem der Netzwerksegmente, welche teils durch PPPOE-Verbindungen per DSL o. gar UMTS ins Internet verursacht wird.

Als Diagnose, ob dies zutrifft, sollten also Dateien verschiedener Größe auf den FTP hoch- und wieder runtergeladen werden. Dateien, die kleiner sind als die verwendete Paketgröße, kommen problemlos durch. Sind sie jedoch größer als ein Frame, werden sie fragmentiert (in mehreren Teilen weitertransportiert) und sollten am Ende wieder zusammengesetzt werden, was FTP allerdings nicht kann - die Dateien gehen also ab einer bestimmten Dateigröße verloren.
Da die Protokollframes (Steuerkommandos wie STOR etc.) stets kleiner als die MTU sind, kommen diese immer durch.

Abhilfe könnte nur die Vergrößerung der MTU im betroffenen Segment (was meist nicht möglich ist) oder Verkleinerung der MTU am FTP-Server (im Falle der NAS2000 wahrscheinlich ebenso schwer möglich) schaffen.

Sollten die Daten nur beim Upload vom Rechner zum NAS zerstückelt werden, hilft eine Justierung der MTU in Windows.
(Hierzu wird die kleinste MTU im Netz per Ping ermittelt: "ping -f -l [MTU-Größe] [IP des FTP-Servers]" eingeben mit einem MTU-Wert von maximal 1500. Meldet Ping fragmentierte Daten, ist der Wert zu senken, bis der Ping durchkommt. Teils steht die MTU bei 1492, bei manchen Internetprovidern gar bei 576 Bytes.)
EDIT: Ich habe gerade ein Programm geschrieben, welches diese Funktion erfüllt und die MTU ausgibt. Es ist nur noch die IP des Zielsystems zu definieren, bis zu welchem die MTU ermittelt werden soll.

Dieser ermittelte Wert ist dann per Registrierungseditor im Pfad "HKEY_LOCAl_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\000x", wobei 000x durch 0001, 0002 o.ä. zu ersetzen ist. Hier erstellt man einen Schlüssel namens "MaxMTU" vom Typ "REG_SZ" mit dem Wert, der eben per Ping ermittelt wurde - also z.B. "576".

Hoffentlich konnte ich ein wenig Licht ins Dunkel bringen...

Gruß,
ArtExplorer
 

Anhänge

  • MTU.zip
    259 KB · Aufrufe: 6
Zuletzt bearbeitet:
ArtExplorer schrieb:
Das FTP-Protokoll ist - dank seines Alters - nicht in der Lage, mit fragmentierten Paketen, also "zerstückelten" Daten umzugehen. Diese werden verworfen, entsprechend fehlen Daten.
Hallo ArtExplorer.

Willkommen im Forum.

Deiner oben zitierten Aussage muß ich insofern widersprechen, als daß FTP ein auf TCP/IP-basierendes Protokoll ist und Probleme mit der Fragmentierung vom IP-Stack und nicht auf FTP-Ebene behandelt werden.
FTP schreibt die Daten als TCP-Datenstrom bzw. empfängt die Daten als TCP-Datenstrom. In welchen Blockgrößen die Daten auf den TCP-Strom geschrieben werden, bestimmt noch der FTP-Server bzw. -Client. Auf die Blockgrößen beim Empfang hat der Server bzw. Client nur noch beschränkten Einfluß über die bereitgestellte Empfangspuffergröße. Hier puffert der IP-Stack die Datenbytes zwischen und gibt die Daten in den angeforderten Größen weiter.
Ob und wie aber die ursprünglichen Blöcke auf dem Weg zur Gegenseite zerstückelt werden, das bestimmen die dazwischen liegenden SW- und HW-Komponenten und nicht FTP-Server oder -Client.

Insbesondere "verwirft" ein FTP-Server oder -Client keine Datenblöcke. Es kann höchstens vorkommen, daß einzelne Datenblöcke wegen Problemen auf tieferen Ebenen erst gar nicht ankommen und die empfangene Datei deshalb fehlerhaft ist. FTP baut dabei auf die fehlerfreie Übertragung durch die TCP-Schicht.
 
Zuletzt bearbeitet:
RiVen schrieb:
Deiner oben zitierten Aussage muß ich insofern widersprechen, als daß FTP ein auf TCP/IP-basierendes Protokoll ist und Probleme mit der Fragmentierung vom IP-Stack und nicht auf FTP-Ebene behandelt werden.
FTP schreibt die Daten als TCP-Datenstrom bzw. empfängt die Daten als TCP-Datenstrom. In welchen Blockgrößen die Daten auf den TCP-Strom geschrieben werden, bestimmt noch der FTP-Server bzw. -Client. Auf die Blockgrößen beim Empfang hat der Server bzw. Client nur noch beschränkten Einfluß über die bereitgestellte Empfangspuffergröße. Hier puffert der IP-Stack die Datenbytes zwischen und gibt die Daten in den angeforderten Größen weiter.
Ja, richtig. Der Beitrag war insofern ein Schnellschuss, als ich mich zwar an ein Experiment bei einem Netzwerkkurs erinnern konnte, aber nicht mehr genau an die Ursache. Nichtsdestoweniger hingen die beschriebenen FTP-Transferprobleme DIREKT mit der MTU eines Netzwerksegmentes zusammen.

RiVen schrieb:
Ob und wie aber die ursprünglichen Blöcke auf dem Weg zur Gegenseite zerstückelt werden, das bestimmen die dazwischen liegenden SW- und HW-Komponenten und nicht FTP-Server oder -Client.
Auch richtig. Allerdings darf man hierbei nicht vernachlässigen, dass FTP als Dualverbindung funktioniert, also typischerweise eine Steuerverbindung UND eine Datenverbindung laufen lässt. Wenn ich mich nun recht entsinne, ist der Zusammenhang in Richtung PMTUD (Path MTU Discovery) und Black-Hole-Router (Router, die Frames mit gesetztem DF-Flag ohne Nachricht verwerfen, wenn sie fragmentiert werden müssten) zu suchen. Schlag mich, gib mir Tiernamen - ich weiß, es gab einen direkten Zusammenhang mit dem FTP-Protokoll und seiner Zweigleisigkeit - ich weiß nur nicht mehr, welchen...

RiVen schrieb:
Insbesondere "verwirft" ein FTP-Server oder -Client keine Datenblöcke. Es kann höchstens vorkommen, daß einzelne Datenblöcke wegen Problemen auf tieferen Ebenen erst gar nicht ankommen und die empfangene Datei deshalb fehlerhaft ist. FTP baut dabei auf die fehlerfreie Übertragung durch die TCP-Schicht.
Nachdem ich Dir zunächst einmal vollkommen zustimmen muss, entschuldige ich mich für den Schnellschuss-Artikel. Ich werde mal beim damaligen Lehrgangsleiter nachfragen, wie der genaue Zusammenhang war.
Abschließend möchte ich nur noch anmerken, dass der FTP-Transfer nach Korrektur der MTUs fehlerfrei lief. Nach o.g. Zusammenhängen sollte das schließlich nicht der Fall sein, da FTP transparent durch TCP transportiert werden sollte und auch wird. Mag sein, dass es ein Basisproblem der Fragmentierung ist, welches auch bei anderen Protokollen (HTTP etc) auftaucht. Ich möchte auch nicht 100%ig ausschließen, dass eine besondere "Empfindlichkeit" vor allem bei dem UDP-basierenden TFTP existiert.

Ich wünsche allen schöne Feiertage und einen guten Rutsch ins neue Jahr 2007.
Gruß,
ArtExplorer
 
Hallo Riven und andere,

es ist nun schon über ein Jahr her, dass der letzte Beitrag geschrieben wurde. Da ich vor ein paar Tagen wieder mit einem ähnlichen Problem konfrontiert war und auch dort Dateiübertragungen via TCP ab einer bestimmten Dateigröße nicht mehr funktionierten, erinnerte ich mich plötzlich wieder an diesen Thread.

Deiner oben zitierten Aussage muß ich insofern widersprechen, als daß FTP ein auf TCP/IP-basierendes Protokoll ist und Probleme mit der Fragmentierung vom IP-Stack und nicht auf FTP-Ebene behandelt werden.

Korrekt, wird von TCP gehandelt. Und genau da (und nicht, wie von mir fälschlicherweise erninnert, bei FTP) liegt der Hase im Pfeffer.

Siehe "Path MTU Discovery" bei Wikipedia (http://de.wikipedia.org/wiki/PMTUD):
PMTUD (Path Maximum Transmission Unit Discovery) ist ein Algorithmus zum Bestimmen der maximalen Paketgröße, die über eine bestimmte Route im Netzwerk verschickt werden kann, ohne dass Datenpakete fragmentiert werden müssen.

Um die maximale Größe zu bestimmen, die ein Datenpaket haben darf, muss die Stelle der Route gefunden werden, die die kleinsten Datenpakete zulässt. Dazu wird ein IP-Paket versendet, bei dem das DF-Bit (Don’t Fragment) gesetzt ist und welches die Größe der lokal eingestellten Maximum Transmission Unit besitzt.
Kommt das Paket an eine Stelle im Netzwerk, an dem nur eine kleinere MTU verarbeitet werden kann, wird ein ICMP Error Typ 3 Code 4 (Destination Unreachable Fragmentation Needed, DF Set) zurück geschickt, welcher auch die eigene MTU enthält. Der lokale Rechner erhält dieses ICMP-Paket und versendet nun die Nachrichten in der Größe der zurück gelieferten MTU und vermeidet somit die Fragmentierung des Paketes über der gesamten Route.

Werden die ICMP-Typ-3-Code-4-Pakete an einem Punkt der Route gefiltert, zum Beispiel durch ein einfaches „ICMP deny“ auf einer Firewall, kann es zu Übertragungsproblemen kommen, wie im Artikel Maximum Transmission Unit beschrieben.

...und solche Firewalls, die den ICMP filtern, waren früher als "Black Holes" bekannt. Die Thematik wird in der RFC 2923 (http://tools.ietf.org/html/rfc2923) behandelt:
This shows up as a TCP connection which hangs (fails to make progress) until closed by timeout (this often manifests itself as a connection that connects and starts to transfer, then eventually terminates after 15 minutes with zero bytes transfered). This is particularly annoying with an application like ftp, which will work perfectly while it uses small packets for control information, and then fail on bulk transfers.

Wie ich schon schrieb, fährt das FTP-Protokoll zweigleisig:
- Kleine Pakete für die Steuerinformationen (Kommunikation Server-Client)
- Große Pakete für den eigentlichen Dateitransfer

Der TCP-Stack versucht also, bei Beginn der Übertragung per PMTUD die maximale Pfad-MTU (von Client bis Server) zu ermitteln. Ist ein Black-Hole (Firewall mit aktiviertem ICMP-Filter) dazwischen, bleibt die Antwort aus. Infolge dessen wird vom TCP-Stack die MTU des lokal genutzten Interfaces (z.B. 1500 Bytes bei Ethernet) genutzt.
Eine kleinere MTU auf dem Pfad bis zum Server bleibt somit unentdeckt.

Solange PMTUD aktiv ist, wird bei allen Paketen das "DF"-Flag ("Don't Fragment") gesetzt. Das Problem daran ist, das TCP PMTUD (und damit auch das DF-Flag) nicht ausschaltet, wenn die Antwort von der Gegenstelle aufgrund eines Black Holes ausbleibt.

Für einen Pfad mit existentem Blackhole (Firewall mit ICMP-Filter) heißt das also:
  • TCP aktiviert PMTUD und versucht die Pfad-MTU zu ermitteln. Dafür wird das DF-Flag eingeschaltet.
  • Das "Black Hole" filtert ICMP und verhindert die Sendung oder Antwort (je nach Fitlterrichtung)
  • TCP wartet nach wie vor auf die Antwort, das DF-Flag ist immer noch gesetzt
  • Solange noch keine Antwort vorliegt, nimmt TCP die lokale MTU-Einstellung (z.B. 1500 Bytes), was evtl. unbekannterweise zu groß ist
  • Jetzt kommt FTP ins Spiel:
  • Das FTP-Protokoll baut eine Steuerverbindung zum Server auf. Kein Thema, die Pakete kommen aufgrund der geringen Größe (wenige Bytes) alle durch.
  • Jetzt startet ein FTP-Dateitransfer. Das DF-Flag im TCP-Stack ist wegen der fehlenden Antwort noch immer gesetzt und die PMTU ist nicht ermittelt.
  • Alle FTP-Pakete, die kleiner sind als die (nicht ermittelte) Pfad-MTU, passieren den Pfad problemlos. Dazu gehören die Pakete der FTP-Steuerung: Client und Server können noch immer problemlos Kommandos und Antworten austauschen.
  • Alle FTP-Pakete, die die Pfad-MTU (unbekannterweise) übersteigen, werden wegen des gesetzten DF-Flag gefiltert und erreichen ihr Ziel nicht
  • Da die Steuerverbindung immer noch steht, sieht für FTP alles gut aus, nur scheinen die Pakete nicht anzukommen. Die Übertragung der zu großen Pakete läuft ins Timeout.

Der eigentliche Fehler des TCP-Stack liegt darin, dass er nach mehreren Timeouts (solange PMTUD ohne Antwort) die MTU nicht einfach kleiner stellt (auf ein sicheres Maß, z.B. 296 Bytes für PPP).

Insbesondere "verwirft" ein FTP-Server oder -Client keine Datenblöcke. Es kann höchstens vorkommen, daß einzelne Datenblöcke wegen Problemen auf tieferen Ebenen erst gar nicht ankommen und die empfangene Datei deshalb fehlerhaft ist. FTP baut dabei auf die fehlerfreie Übertragung durch die TCP-Schicht.
...absolut korrekt. Ich hatte es dank fehlerhafter Erinnerung auf FTP und nicht auf den TCP-Stack geschoben. Insofern "verschluckt" der FTP-Server oder -Client keine Datenblöcke - vielmehr sind es für den Pfad zu große Pakete, die wegen des noch gesetzten "Don't-Fragment"-Flag vom ersten Netzelement mit einer kleineren MTU als der ankommenden Paketgröße gedroppt werden.

WORKAROUND / HOW TO FIX:
Als Abhilfe für das urspüngliche Problem mag gelten, dass man alle Firewalls, die sich unter eigener Kontrolle befinden, kontrolliert und ggf. das ICMP-Filtern (Ping-Filter) abschaltet. Da manche Traceroute-Imlementierungen ebenfalls PMTUD verwenden, wäre zur Kontrolle ein Traceroute eine Möglichkeit.
Sind die "Black Holes" nicht unter Deiner Kontrolle (also in fremden Segmenten), bleibt nichts anderes, als an den Stellen zu drehen, wo es möglich ist: Von beiden Seiten aus zur jeweils anderen sollte mit dem in der oberen Nachricht angehangenen Programm (oder per Ping mit variierender Paketgröße mit gesetztem DF-Flag) die MTU ermittelt werden. Stehen die beiden Werte fest, nimmt man den Kleineren der beiden und trägt diese selbst ermittelte PMTU als MTU an beiden Endstellen ein. Wenn die beteiligte Software (z.B. VPN-Tunnel) dies zulässt, sollte auch wenn möglich an beiden Endstellen die "Path MTU Discovery" (PMTUD) abgeschaltet werden, da ansonsten immer das DF-Flag gesetzt bleibt.

Es möge mir verziehen sein:
Lieber ne späte Antwort / Richtigstellung als gar keine;)

Gruß,
ArtExplorer
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.