Tiger und FTP-Programme... Problem...

Grrrrrrrrrrrrr :( :(

Jetzt ist Transmit 3.2.1 draußen in deutsch. Aber der Fehler bleibt...

Verbinden mit Server - no Problem (da müßte es ja schon hängen).

Aber "Dateiliste empfangen". Er lädt und lädt... und wenn er nicht gestorben ist... lädt er noch heute :( :(
 
Hallo!

Ich habe das gleiche Problem. Tiger und Firewall up... nix geht - auch nicht mit der neuesten Version von Transmit. Firewall down... es fumpt. Das ist doch zum Haare ausraufen. Muss doch irgendwie auch mit Firewall up gehen.

Irgendwie läuft alles ausser Surfen nicht wirklich schnell gerade. ssh mag auch nicht so recht...

Mist.

Gruss,

Manjo
 
Ich kann Eure Probleme nicht bestätigen.
Ich selbst benutze Transmit unter Tiger völlig problemlos.

Der von Nightangel beschriebene Effekt sollte eigentlich nur dann auftreten, wenn aktives FTP hinter einem Router benutzt wird, da der Server dann nicht den Datenkanal zum Client einrichten kann (der bleibt sozusagen am Router stecken).
Bei passivem ftp wird auch der Datenkanal vom Client aufgebaut.

Eine Firewall kann das selbe Problem verursachen, wenn auch aus einem anderen Grund. Da der Datenkanal auf einem nicht vorhersehbaren Port > 1023 eingerichtet wird müssten praktisch alle diese Ports geöffnet werden.
Da kann man die Firewall gleich ausschalten; das kommt auf das Selbe hinaus.

Welches Problem hast Du mit ssh, Manjo?
Gehts um die Verzögerung beim connecten?
Das kann man ggf. lösen.
 
Ich habe seit Tiger auch massive Probleme mit dem Zugriff auf FTP-Server, und das nicht nur durch eine FireWall hindurch. Auch LAN-intern bocken sämtliche Programme, sei es Cyberduck, Fetch oder aber ftp im Terminal. Selbst der Finder verweigert sich*… Es liegt also scheinbar nicht unbedingt an den Drittherstellern, wenn selbst die beigelegten Programme Zicken machen.
 
@Ulfrin
veerwendest Du aktives oder oassives ftp?

@Manjo
Habe Deine PN erhalten; die Lösung poste ich lieber öffentlich, damit alle was davon haben.

Wenn beim Verbinden mit einem ssh Server der Aufbau der Verbindung sehr lange dauert, kann man das meist mit folgendem Kommando dauerhaft lösen:
Code:
sudo echo AddressFamily inet >> /etc/ssh_config

Voraussetzung für ssh ist außerdem eine funktionierende Namensauflösung aller beteiligter Rechner in beiden Richtungen.

HTH
 
Ulfrinn schrieb:
Sowohl als auch, ist leider beides bockig. :/
Nun ja.
Diese Fehlerbeschreibung ist ja nicht gerade aussagekräftig.
Insofern kann man da nicht viel dazu sagen.
Ulfrinn schrieb:
...
… Es liegt also scheinbar nicht unbedingt an den Drittherstellern, wenn selbst die beigelegten Programme Zicken machen.
Es liegt aber scheinbar auch nicht an Tiger selbst, da ja bei mir (und vielen anderen Benutzern) kein Probleme mit ftp auftreten.
 
Hallo Maceis,

hat keine Verbesserung geschaffen. Also an IPV4/6 liegt es wohl nicht. Steht die Verbindung einmal, ist alles bestens.

Im system.log habe ich gesehen, dass der Hostname auf noname gesetzt wurde. Kann mir das nicht erklären, weil dies im Wechsel mit dem eigentlichen Hostnamen geschieht.

Code:
Aug 18 16:01:12 meinname configd[29]: setting hostname to "meinname.local"
Aug 18 16:05:21 meinname configd[29]: setting hostname to "noname"
Aug 18 16:20:17 meinname configd[29]: setting hostname to "meinname.local"
Aug 18 16:23:02 meinname configd[29]: setting hostname to "noname"
Aug 18 16:31:09 meinname configd[29]: setting hostname to "meinname"
Aug 18 16:31:11 meinname configd[29]: setting hostname to "noname"

Vielleicht liegt's an der Namensauflösung?

Gruß,

Manjo
 
maceis schrieb:
Nun ja.
Diese Fehlerbeschreibung ist ja nicht gerade aussagekräftig.
Insofern kann man da nicht viel dazu sagen.Es liegt aber scheinbar auch nicht an Tiger selbst, da ja bei mir (und vielen anderen Benutzern) kein Probleme mit ftp auftreten.
Naja, es sind die oben beschriebenen Probleme, à la „Connection refused“ in Cyberduck. Bei „ftp“ gibt es dagegen oft scheinbar gar keine Antwort vom Server. (Das Programm „hängt“.) Ich wüßte nicht, wie man die Probleme sonst noch präziser beschreiben sollte. Unter Panther gab es diese Probleme nicht, seit ich auf Tiger aktualisiert habe, bestehen sie. Testweise habe ich eine Neuinstallation von Tiger auf eine externe Festplatte gemacht, und auch bei dieser nigelnagelneuen Installation gibt es die beschriebenen Probleme.
 
Ich für meinen Teil hab die Faxen dicke. Tiger habe ich soeben endgültig gelöscht. Zum Glück hatte ich ihn nur zum Testen auf der externen HD und (noch) kein Geld dafür ausgegeben.

Bleib ich eben bei Panther. Da muß ich für kein Problem ne Fieselei anfangen, damit es geht.

Davon abgesehen fand ich Spotlight und die ganze Indiziererei eh für den A...

Nik
 
Manjo schrieb:
...
Vielleicht liegt's an der Namensauflösung?
...
Ja, das ist möglich.
Wäre mögich dass Du nicht hinter einem Router bist und Dein Provider für die vergebenen IP Adressen keine Rückwärtsauflösung konfiguriert hast.
Die Zeitpunkte der "Namensänderung" wären dann die Zeitpunkte der Interenetein-(bzw. -aus-)wahl.
Das ist aber jetzt eine reine Spekulation.

---

@Ulfrin
in diesem Fall ist es schwierig aus der Ferne etwas zu sagen.
In solchen Fällen kann man manchmal (oft) die Lösung finden, wenn man einen Netzwerksniffer (z. B. ethereal) einsetzt.
Das erfordert aber etwas Erfahrung und man müsste auch den Aufbau des Netzes kennen.
 
maceis schrieb:
in diesem Fall ist es schwierig aus der Ferne etwas zu sagen.
In solchen Fällen kann man manchmal (oft) die Lösung finden, wenn man einen Netzwerksniffer (z. B. ethereal) einsetzt.
Das erfordert aber etwas Erfahrung und man müsste auch den Aufbau des Netzes kennen.
Ich vermute, daß es recht unabhängig ist vom Aufbau des Netzwerkes, denn ich habe dieses Problem hier mit jeder erdenklichen Konstellation: LAN über Router, LAN mit Direktverbindung, WAN über Router und WAN mit Direkteinwahl. In jedem Fall kommen die Fehler sporadisch vor. :/
 
Ulfrinn schrieb:
Ich vermute, daß es recht unabhängig ist vom Aufbau des Netzwerkes, denn ich habe dieses Problem hier mit jeder erdenklichen Konstellation: LAN über Router, LAN mit Direktverbindung, WAN über Router und WAN mit Direkteinwahl. In jedem Fall kommen die Fehler sporadisch vor. :/

Mit der Mac-Firewall kenne ich mich nicht aus. Aber generell gilt für ftp, dass es über Port 21 und 20 läuft! 21 ist ftp, 20 ist ftp-data. Ggf. sind an der Firewall beide zu öffnen.

Und der Fehler "Kann mich einloggen, aber File-Listing hängt" klingt doch arg nach fälschlichem active ftp oder eben geblocktem Port 20.

GRuß,
Ratti
 
ratti schrieb:
Mit der Mac-Firewall kenne ich mich nicht aus. Aber generell gilt für ftp, dass es über Port 21 und 20 läuft! 21 ist ftp, 20 ist ftp-data. Ggf. sind an der Firewall beide zu öffnen.
...
Diese Darstellung ist nicht ganz korrekt.
Zunächst mal ist es so, dass an der mac Firewall, wenn man nichts auf der Kommandozeile verstellt hat, alle Ports von innen offen sind.
Das hat zur Folge, dass für passives ftp (als Client) gar keine Ports geöffnet werden müssen.
Der Port 20 müsste allerdings ohnehin nicht offen sein, da dieser von ftp Clients grundsätzlich nicht verwendet wird, auch nicht bei passivem ftp.

Bei aktivem ftp, bringt es übrigens auch nichts, Port 20 zu öffnen, da dies der Quellport ist, den der Server verwendet.
Als Zielport wird ein nicht vorhersehbarer Port oberhalb 1024 verwendet (Der Quellport den der Client für den Kommandokanal verwendet hat +1).

Es müssten also (wie ich oben schon sagte) alle Ports > 1023 geöffnet werden.
Hinter einem einfachen NAT Router kann man aktives ftp vergessen.

ratti schrieb:
...
Und der Fehler "Kann mich einloggen, aber File-Listing hängt" klingt doch arg nach fälschlichem active ftp oder eben geblocktem Port 20.
...
Nein, nach aktivem ftp und Ports über 1023 geblockt.

Eine Firewall für aktives ftp vernünftig zu konfigurieren geht mW nur mit dynamischen rules.
Sollte man sich nur antun, wenn es nicht anders geht.
 
Also, die Mac-OS-Firewall ist bei mir vollständig deaktiviert. In meinem LAN gibt es nur vier Rechner, meinen eingeschlossen, von denen ich definitiv weiß, daß sie mir nichts anhaben werden –*Insofern benötige ich diese Firewall nicht. Im Router ist eine Firewall aktiv, aber selbst wenn ich mich ohne aktivierte Firewall direkt mit meinem PB einwähle, kommt es zu den Problemen, darüber hinaus auch bei direkter Netzwerkverbindung mit einem Server ohne Firewall, etc. pp. (s. o.). Der Fehler ist schlicht und ergreifend in meinem Fall nur auf zwei Quellen zurückzuführen:
a) der FTP-Server selbst
b) Mac OS X 10.4.x
Daß es der FTP-Server ist, bezweifle ich, weil dann merkwürdigerweise zwei gleichzeitig betroffen wären (bei unterschiedlicher Server-Software) und dieses Problem mit allen anderen Systemen (Panther, Win 2000 und XP, LINUX) nicht auftritt.

Von „Kann mich einloggen, aber File-Listing hängt“ habe ich übrigens nie etwas geschrieben –*Ich kann mich ja, wenn der Fehler auftritt, überhaupt nicht einloggen. ;)
Und an den Passivitätseinstellungen kann es auch nicht liegen, denn das Problem tritt in allen Konfigurationen sowohl im aktiven als auch im passiven Modus auf. Glaubt mir, ich habe mittlerweile alle Konfigurationen durch.

Darüber hinaus denke ich auch, daß dieser Fehler in einer der nächsten Aktualisierungen vielleicht sogar behoben wird, und bis dahin kann ich damit leben, daß ich immer mal wieder mehrere Anläufe brauche. Wenn ich dann erst einmal angemeldet bin, klappt es ja auch eigentlich immer. Trotzdem natürlich ein großes Dankeschön für eure Lösungsvorschläge und die Mühe, die ich euch gemacht habe. (frei nach Bodo Bach ;))
 
Hi,

bei mir besteht das fast gleiche Problem. Rasendschneller FTP mit Panther, mit Tiger dauert er 10 - 50 mal länger. Obwohl Firewall deaktiviert ist. Müssen wir auf eine verbessernde Aktualisierung hoffend vorm Bildschirm harren (während andere zum Hoffen in die Kirche gehen)?

free:z
 
Zuletzt bearbeitet:
Habe gestern von Panic.COM (Transmit-Support) ne Mail gekriegt, daß sie das Problem mittlerweile kennen. Allerdings haben sie keine Ahnung, wie sie es angehen sollen.

Da hat Apple wohl irgendwo nen Bockmist gebaut. Betrifft ja nicht nur Transmit...
 
Ich habe gestern lange probiert und bekam keine Daten per ftp übertragen - egal ob Konsole, Transmit oder andere Progs. Am Nachmittag habe ich mal nach Updates gesucht. Es stand da: Keine Updates verfügbar. Ich will es jetzt nicht beschwören, jedoch als ich es danach noch einen Versuch startete, funktionierte alles! Und das tut es immer noch. Ob da doch ein Update kam, ohne dass der Benutzer es merken konnte?
 
Genervt von der Warterei und der Tatsache, dass ftp mal geht und mal nicht, habe ich mich heute auf die Suche gemacht und die Logfiles mal genauer angesehen. Wie läuft es ab, wenn der Datenkanal bei passivem ftp geöffnet wird? Funktioniert es so, dass, nachdem Client und Server sich auf eine Datenleitung verständigt haben, diese vom Client auf einem Port > 1024 geöffnet wird (sonst käme er ja nicht durch die Firewall), anschließend antwortet der Server auf diesem Port. Wenn auf dem Server jedoch die Ports gesperrt sind, tut sich nichts. Ich habe verschiedene ausprobiert. Bei einigen ging es bei anderen nicht. Auf meinem eigenen Webserver habe ich dann die Ports freigegeben und es funktionierte. Nun frage ich mich allerdings, warum es mit den Windoof-Clients auf allen Servern immer funktioniert und mit meinem Apfel erst nach den Änderungen? Und warum ging es mal und mal nicht? Zufall? Aber ich glaube nicht an Zufälle!
 
Manjo schrieb:
...
Wie läuft es ab, wenn der Datenkanal bei passivem ftp geöffnet wird? Funktioniert es so, dass, nachdem Client und Server sich auf eine Datenleitung verständigt haben, diese vom Client auf einem Port > 1024 geöffnet wird
...
Wenn man ftp betrachtet, ist es IMO sinnvoll zwischen Wuell und Zielport zu unterscheiden.
Eine typische passive FTP Session sieht so aus:
  • Der Client kontaktiert den ftp Server mit einem beliebigen Quellport > 1023 (A) auf dem Zielport 21.
  • Der Server antwortet mit dem Quellport 21 an Zielport A und teilt dem Client einen freien Zielport (B) für den Datenkanal mit.
    Damit ist der Kontrollkanal eingerichtet.
  • Der Client öffnet auf einem mit einem beliebigen Quellport > 1023 (C) den Datenkanal zum Server auf Zielport B.
  • Der Server antwortet mit Quellport B an den Zielport C. Damit ist der Datenkanal eingerichtet.
Manjo schrieb:
...
(sonst käme er ja nicht durch die Firewall)
...
Mit der Firewall hat das eigentlich nur am Rande was zu tun.
In der Grundkonfiguration sind alle Ports von innen offen.
Antworten auf Anfragen, die vom Client initiiert wurden. sind zulässig

Manjo schrieb:
...
Wenn auf dem Server jedoch die Ports gesperrt sind, tut sich nichts.
...
Das ist richtig.
Ein FTP Server, der auf Ports, die dem Client als Datenzielport mitgeteilt werden, nicht antwortet, ist für Passives FTP fehlkonfiguriert.
 
Zurück
Oben Unten