IOException in fetch

[arbor95]

nein, das passt schon so:
Aus dem letzten sieht man das
beim Aufruf der Seite http://www.geocaching.com/login/Default.aspx
dieser IOException Fehler kommt.

Das ist der Aufruf

Socket sock = conn.connect();

bei ("[fetch]:Connecting "+address);

Ich vermute mal, dass das etwas mit der Brandschutzmauer zu tun hat (Firewall).

[OrbitStar]

Hat ein bisschen gedauert, aber nun habe ich folgendes verifiziert:
Kein Problem der Brandschutzmauer - gibt keine ;-)
Kein Problem der HW - Mit Ubuntu 9.04 Live CD funktioniert's auf Anhieb
Kein Problem mit Debian (Lenny) - Funktioniert problemlos unter Lenny auf anderem Notebook
So wie es aussieht scheint es ein Problem mit der installierten Debian-Squeeze bzw. Java Runtime Version zu geben.
Gibt es eine Möglichkeit das irgendwie weiter einzuschränken??

[arbor95]

socket connect ist (fast) der unterste level der programmierung.

(ich tippe trotzdem auf firewall)

[OrbitStar]

Hmm, gibt's eine Möglichkeit socket connect zu debugen/testen ?

BTW, warum eigentlich "ewe.io.IOException..." kommt die ewe vm im Paket für Linux mit?

Bezüglich der Firewall wüsste nicht welche das sein sollte.
Aber wenn ich das richtig verstehe sollte CW die Seite genau so aufrufen (z.B. Protocol/Port) wie es auch der Browser tut. Und aus dem Browser funktioniert es ohne Probleme. Wie sollte eine Firewall hier zwischen dem Traffic von Browser und CW unterscheiden??

[Harry1999]

Firewalls haben manchmal die Aufgabe sicherzustellen, dass nur zugelassene Programme eine Connection aufbauen dürfen... ist mit der eingebauten Firewall in Windows genauso. Da kann man konfigurieren, dass nur vom Admin zugelassene Progs loslegen dürfen.

[OrbitStar]

Also, auf dem Rechner ist absolut keine Firewall installiert. Weder auf Paketen noch auf Applikationslevel. Und eine Firewall ausserhalb des Rechners sollte hier keinen Unterschied sehen.
Warum sollte eine Application based FW die DNS Abfrage aus CW zulassen und den HTTP request unterdrücken. Macht irgendwie keinen Sinn.

Edit:
Hab jetzt nochmal die Paketverwaltung bemüht:
Auf diesem Rechner ist absolut keine Firewall installiert!!!

[arbor95]

Die Meldung "Could not connect" ist auf jeden Fall eindeutig. Da hakt etwas im System. Du hast ja schon mal eine tcp - trace mitlaufen lassen. Wenn ich mich recht erinnere ist da gleich schon die DNS-Anfrage nicht beantwortet worden!

[OrbitStar]

Nicht ganz korrekt.
Die DNS Anfrage wird gesendet UND beantwortet!!
Nur anschließend, beim Aufruf der Login-Seite, kommt kein Paket mehr auf die Schnittstelle.

Edit:
Au Backe...
Ich habe mich nochmal auf die Leitung einer funktionierenden Installation und der Problem-Installation aufgeschaltet und folgendes beobachtet:

Debian Lenny:
0.000000 DNS Standard query A www.geocaching.com
0.015648 DNS Standard query response A 66.150.167.171
-> anschließend Verbindungsaufbau via TCP und CW spidert.

Debian Squeeze:
0.000000 DNS Standard query A www.geocaching.com
0.000040 DNS Standard query AAAA www.geocaching.com
0.016041 DNS Standard query response A 66.150.167.171
0.019219 DNS Standard query response
-> anschließend keine weiteren Pakete aber "Fehler beim laden der Login Seite"

Sieht so aus als ob CW wohl die DNS Abfrage (Type A) startet und dann aus irgendeinem Grund sofort eine weitere (Type AAAA) sendet ohne auf die Response der ersten (die wohl kommt, jedoch anscheinend nicht ausgewertet wird) zu warten.

Gibt es eine Möglichkeit im Sourcecode nachzuschaun warum CW die Type AAAA query sendet??

[arbor95]

http://www.geoclub.de/viewtopic.php?f=4 ... 10&start=0

[MiK]

Wenn auf dem einen System nur der A Query gemacht wird und CW dann wartet bis die Antwort kommt und alles normal läuft, und auf dem anderen System kommen auf einmal noch andere Anfragen, dann liegt es wohl an dem System.

Aber das ist auch nicht verwunderlich, wenn man ein OS in Entwicklung benutzt anstatt eine stabile Version.