WGET und WPUT ›klemmen‹ - Kommunikation, aber kein Datenverkehr

cumulonimbus8

Fleet Admiral
Registriert
Apr. 2012
Beiträge
19.481
Hallo!

Da habe ich unsere auf XP ausgeklügelte Konstruktion unter meinem W8/64 angeworfen und hatte keinen Datenverkehr; die CMD-Box meldetet zwar das Einloggen, aber der Ladeversuch lief ins Leere. Ursache offenbar die Firewall. Also flott für beide eingehend wie ausgehend alles geöffnet - lief.

Und nun sollte ich das auf dem W7/64 des Kollegen (von mir aufgesetzt, anscheinend korrekt und erfolgreich) in Gang bekommen. Pustekuchen, auch nach Öffnen in der Firewall.

Was könnten wir da vergessen haben? Ich komme vorläufig nicht an die W7-Maschine, also will ich wenigstens Ideen sammeln mit denen ich den Kollegen zumindest fernsteuern kann.
Im Virenschild (Avast) etwas nicht geöffnet? Ich sehe bei mir da nix, weder im Guten wie im Bösen.
Missgeschick mit WGET 32- und 64-bit-Version? Aber warum sollte «ich mich» dann anmelden können?

Ich habe das Gefühl als sähe ich den Wald vor lauter Bäumen nicht!

CN8
 
Du sprichst in Rätseln! Wenn du ernsthaft Hilfe haben möchtest, solltest du das Problem noch ein wenig genauer beschreiben!
 
Und was ist unverständlich??


WGET baut eine Verbindung zum Server auf, überträgt User und Passwort und bekommt ein OK. Nur der anschließende Datentransfer kommt nicht zu Stande. WGET pollt, es kommen aber keine Daten.

Unter W8/64 genügten 2x2 Firewall-Reglen, ausgehend wie eingehend, um WGET und WPUT an die Arbeit zu bekommen. Die selben handwerklichen Maßnahmen führen aber unter dem W7/64 des Kollegen nicht zum gewünschten Erfolg.

Was sonst noch behindert die beiden Kommandozeilentools?

Gewisse andere Einstellungen und Programme funktionieren problemlos (FTP, mit FileZilla z.B.), und zwar genauso problemlos und auf Anhieb wie unter meinem WIN8. Daher unterstelle ich W7 etwas zu blockieren.

CN8
 
Da habe ich unsere auf XP ausgeklügelte Konstruktion unter meinem W8/64 angeworfen und hatte keinen Datenverkehr;

Das fand ich ein wenig kryptisch; was die Konstruktion genau ist wurde hier absolut nicht klar. Läuft der Traffic im Netzwerk evtl. über einen Proxy? Was passiert, wenn die Firewall test-halber komplett deaktiviert wird, läuft wget dann? Was sagt der Server, wenn der Handshake stattfindet? Ggf. könnte Wireshark noch zur Aufklärung helfen.

Zu guter letzt könnte natürlich Avast (o.ä.) noch dazwischen funken.
 
Die ausgekügelte Konstruktion…

…ist ein XL-Mappe die WGET (und WPUT) mit nötigen Befehlen füttert und auslöst (das Geschehen kann man in CMD-Boxen verfolgen, wenn man flott genug ist). Das wurde unter XP erfunden, läuft da (mit 2 Servern) und auch genauso unter W8. Und auf diversen XP-Systemen.

Nur unter 7 tut es nicht. Die Firewall abzuschalten kann die Lösung nicht sein; ich habe die Einstellschritte sogar 2x unter W8 getätigt und in den selben Dialogen unter W7. Wenn muss sich W7 signifikant im Verhalten unterscheiden, »der Rest« funktioniert ja da - nur musste ich dafür auch nichts an Firewalls drehen.

Avast ›beleuchtet‹ bei mir (XP, 8…) nichts bzw. kennt es als Ausnahme was nicht genauso unter 7 von mir eingestellt worden wäre.

CN8
 
Moin cumulonimbus8,

Klar - die Firewall dauerhaft abstellen ist keine Lösung, die Frage war ja auch nur ob ein Test aufzeigt das es hieran liegt?
Und nochmal die Frage: Was passiert denn auf dem Server, sobald wget startet - gibt es dort vll Infos im Log?
 
Auf dem Server - was soll da passieren wenn die selbe (!) WGET.EXE mit der selben Syntax ihre Anfrage stellt und dann auch wie gewollt ein Datenfluss kommt?
Das Problem muss lokal bei 7 liegen. Irgendwas im FTP-Stack vielleicht, da sich offenbar korrekt angemeldet wird; das spräche ja auch wieder gegen einen blockierten Port 21 (oder findet das Einloggen auf einem anderen statt, sollte mich schwer wundern). Zu blöd auch.

Firewall abschalten - wird dauern bis sich dazu komme..: ist ja wieder mal was Anderes viel wichtiger…

CN8
 
Trotzdem doof, dass ich in den Regeln meinem Aberglauben nach durchaus alles für WGET und WPUT geöffnet habe. Dumme Sache…
CN8
 
Abschluss
Ursache war eine ZyWALL 5 mit alter Firmware die sehr effektiv W7 & W8 (64&32) mattgesetzt hat.
CN8
 
Zurück
Oben