nicht angemeldet
Hi Christian,
zu dem gewünschten FTP-Server normalerweise über den dafür
reservierten Port 20 (?) auf.
21 ;-)
Yep - meine Erinnerung war ungenau (und das Fragezeichen hat seinen
Zweck erfüllt ;-).
Das ist definitiv FALSCH. Bei der HTTP-Kommunikation laufen alle
Verbindungen zwischen Client und Server auf der Serverseite
ausschließlich über Port 80.
Ja.
Wie könnte dann der Server gleichzeitig mehr als einen Client bedienen?
"snoop" mal eine solche Maschine - Du wirst Dich wundern, was für Ports
HTTP verwendet ...
Wir sind der Sache inzwischen etwas weiter nachgegangen.
Zunächst mal: Mit anderen Windows-FTP-Clients (etwa dem "ftp"-Kommando
der WinNT-cmd-Box) tritt exakt dasselbe Problem auf.
Beide scheinen von Windows einen beliebigen freien Port oberhalb von
1024 zugeteilt zu bekommen. Das ist auch okay, so, wie ich dem Dokument
entnehme, auf welches Rolf gelinkt hat.
Nur sind dort eben eine ganze Menge Ports "well known".
1024 ist zwar "legal", aber nicht "schlau".
Nehme ich nämlich einen UNIX-FTP-Client, dann habe ich das Problem nicht.
Das liegt daran, daß dieser mit wesentlich höheren Port-Nummern arbeitet
(so um die 37000), und so weit oben scheint es keine well-known Ports mehr
zu geben. Unsere Firewall kennt jedenfalls keine.
Windows selbst benutzt hingegen durchaus Ports in Bereichen bis zu 10000!
Das hätte sich diese Port-DLL mal besser vor Augen halten sollen - und
dann nicht so weit unten mit dem Ausliefern freier Ports anfangen sollen.
Würde sie "oben" anfangen (65536, richtig?), wäre das Problem ebenfalls
gelöst.
Ich habe mir vorhin erklären lassen, wie der Verbindungsaufbau-Handshake
ungefähr funktionieren soll (bitte um Korrekturen, falls erforderlich):
1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein SYN ACK und bestätigt diese Port-Nummer.
3. Der Client schickt ein ACK und fühlt sich ab hier befugt, diesen
Port zum Kommunizieren nutzen zu dürfen.
In unserem Falle sagt die Firewall dem Client nicht mal explizit, wieso
sie den Port ablehnt (dafür scheint es auf dieser Ebene gar kein Sprach-
mittel zu geben):
1. Der Client schickt ein SYN und schlägt eine Port-Nummer vor.
2. Der Server schickt ein REJ und lehnt diese Port-Nummer ab.
3. Der Client muß darauf reagieren.
Beispielsweise, indem er sich nun eine neue Port-Nummer ausdenkt.
Wie macht er das? Er könnte beispielsweise wieder die schon erwähnte
Windows-API fragen. Diese weiß natürlich nichts von der Firewall, und
vor allem kommt sie nicht auf die Idee, daß dem FTP-Client die vorhin
gelieferte Port-Nummer nicht "gefallen" hat. Es besteht also die ernste
Gefahr, daß diese Windows-API wieder dieselbe Port-Nummer liefert.
Genau das passiert auch, wie wir in den Firewall-Traces sehen können:
Der FTP-Client überträgt ein paar hundert Dateien, stößt dann zufällig
an einen well-known Port, erhält ein REJ - und versucht dann aber stur
immer wieder denselben Port, bis er irgendwann aufgibt und abbricht.
Vermutlich macht er genau das, was ich auch tun würde, nämlich einen
nächsten freien Port anfordern ... aber die API liefert ihm offenbar
ständig dieselbe Port-Nummer, weil sie nicht kapiert, was los ist.
Alle Beteiligten halten sich an die Standards - aber sie arbeiten nicht
wirklich kooperativ an der Lösung des Problems. Alle "haben recht" ...
Wenn diese Windows-API immer den "nächsten" freien Port zurück liefert,
dann ist sie in meinen Augen der Haupt-Urheber des Problems - und der
Programmierer des FTP-Clients hat tatsächlich keine Chance, das Problem
zu lösen, wenn er kein "Vorschlagsrecht" für eine Port-Nummer hat.
Würde die Windows-API beispielsweise eine Port-Nummer _auswürfeln_, statt
immer wieder dieselbe zu liefern, dann würde sie das Problem automatisch
umgehen. Würfeln dauern natürlich etwas länger als mechanisch die nächste
freie Nummer aus einer Liste abzustreichen ... könnte der FTP-Client eine
Port-Nummer vorschlagen, dann wäre es seine Entscheidung, ob er würfelt
oder sequentiell einen Port-Range abscannt.
Jetzt müßten wir mal systematisch durchtesten, ob sich alle Windowse in
dieser Hinsicht gleich verhalten. Vielleicht wäre das Problem ja durch
irgend einen Patch einer System-Bibliothek lösbar ...
Wer macht eigentlich diese Prüfung der Ports in Windows? (socket.dll?)
Ratlos,
Michael