• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

IOException in fetch

arbor95

arbor95

Geoguru
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).
 
OP
O

OrbitStar

Geocacher
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

arbor95

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

(ich tippe trotzdem auf firewall)
 
OP
O

OrbitStar

Geocacher
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??
 
H

Harry1999

Geocacher
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.
 
OP
O

OrbitStar

Geocacher
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

arbor95

Geoguru
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!
 
OP
O

OrbitStar

Geocacher
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??
 
MiK

MiK

Geoguru
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.
 
OP
O

OrbitStar

Geocacher
In der letzten Antwort gab es ja wohl nichts Neues und auch nichts was irgendwie betreffend des Problems weiter geholfen hätte.

Nach etwas intensiverer Recherche bin ich dann auf folgenden Bug inklusive workaround gestoßen:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560044

Sieht so aus als würde dieses "Problem" bald mehr als nur die Leute mit einem "OS in Entwicklung" betreffen.
 
MiK

MiK

Geoguru
Ich habe dort nicht explizit gelesen, dass es nicht als Bug anerkannt würde oder nicht gefixt würde. Also gehe ich vor einem Release davon aus, dass daran noch etwas geändert wird.

Aber vielleicht habe ich das beim Überfliegen auch falsch verstanden.
 
Wutschkow

Wutschkow

Geomaster
Ich lese das auch so, dass es als Bug aufgenommen wurde mit der Einstufung "serious", also ernsthafter Fehler.
Aber dass es einstweilen einen Workaround gibt, ist doch eine gute Nachricht. Schon getestet und behebt es das Problem mit Cachewolf dann auch?

Wäre jedenfalls wirklich etwas viel verlangt, wenn CW nun Vorkehrungen für Bugs in den Prelease-Versionen einzelner Distributionen treffen sollte.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben