Kernel: Versionen ab 2.4.0
Die Internet Einwahl funktioniert prinzipiell und Sie können viele Webseiten anschauen und andere Internetdienste nutzen. Zu manchen Servern können Sie aber partout keine Verbindung aufbauen. "Übliche" Verdächtige sind z.B. www.postbank.de oder z.B. www.mediamarkt.de. Wenn Sie einen Webproxy verwenden können Sie die Seiten aber wieder betrachten. Versuchen Sie aber beispielsweise im Falle der Postbank das Onlinebanking oder andere Webseiten die https verwenden aufzurufen bleibt die Verbindung wieder hängen.
Dieses Phänomen kann zwei verschiedene Ursachen haben. Hier soll Ihnen gezeigt werden wie Sie den Fehler untersuchen und beheben können.
Der 1. Fehler tritt überwiegend in Verbindung mit T-DSL oder anderen ADSL Anbietern auf die PPPoE als Protokoll einsetzen. Bei diesen Anbietern ist die zulässige Paketgröße eines Datenpaketes nicht mehr 1500 Byte sondern nur noch 1492 Byte da der PPPOE Header insgesamt 6+2 Byte verbraucht.
Der 2. Fehler tritt auf, wenn Sie die Option DISABLE_ECN
in der
Datei /etc/rc.config
auf "no" gestellt haben. Dies geschieht nur
wenn Sie diese Einstellung manuell geändert haben, da nach der Installation
diese Einstellung auf "yes" steht. Üblicherweise ist "ECN" damit deaktiviert.
Eine detaillierte technische Beschreibung was ECN ist finden Sie im RFC 2481.
Die Lösung zu Punkt 1 finden Sie erschöpfend im Artikel "T-DSL (u.a.): Manche Server sind nicht erreichbar" (http://sdb.suse.de/de/sdb/html/cg_pmtu2.html) behandelt.
Die Lösung zu Punkt 2 ist ebenfalls einfach. Geben Sie bitte folgendes Kommando ein:
echo "0" > /proc/sys/net/ipv4/tcp_ecn
Damit ist ECN deaktiviert. Wenn Sie nun probieren den Server zu erreichen so
sollte dies sofort funktionieren. Damit diese Einstellung auch nach dem reboot
aktiviert ist verändern Sie /etc/rc.config
bitte
folgendermassen:
Suchen Sie nach
DISABLE_ECN="no"
setzen Sie stattdessen ein
DISABLE_ECN="yes"
Sie können den Fehler auch mit den Kommandos tcpdump
und
lynx
(Beide Serie n
) genauer
untersuchen und voneinander unterscheiden.
Geben Sie hierzu in einem xterm oder auf der Console das folgende Kommando ein
tcpdump -p -i any port 80
Damit werden die Datenpakete einer Webanfrage die Sie über eine beliebige Netzwerkschnittstelle herausschicken auf dem Bildschirm ausgegeben.
Damit nicht zuviel auf einmal passiert verwenden Sie für die Testanfrage am besten den Consolen-Webbroswer lynx. Geben Sie in einer zweiten Console z.B. folgendes ein:
unset http_proxy lynx http://www.postbank.de/
Hier steht www.postbank.de für den zu untersuchenden Web-Server.
Wenn Sie ECN aktiviert haben und Sie den Server (Hier im Beispiel
www.mediamarkt.de) nicht erreichen
können wird die Ausgabe von tcpdump
auf dem Bildschirm ungefähr wie folgt
aussehen.
11:11:03.624736 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 492568 0,nop,wscale 0> (DF) 11:11:06.624765 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 492868 0,nop,wscale 0> (DF) 11:11:12.624823 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 493468 0,nop,wscale 0> (DF) 11:11:24.624939 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 494668 0,nop,wscale 0> (DF)
Symptom: Wie Sie sehen kommt vom entfernten Server überhaupt keine Antwort. Ihr Rechner
versucht immer wieder in wachsenden Abständen eine Verbindung aufzubauen (Das sehen
Sie an dem oben dick hervorgehobenen S) bekommt aber keine Antwort. Zusätzlich
ist ECN aktiviert (Das sehen Sie an [ECN-Echo,CWR]
).
Workaround-Lösung: Schalten Sie ECN wie oben beschrieben ab.
Eigentliche Fehlerursache: Entweder eine falsch konfigurierte Firewall oder ein Betriebssystem das die ECN Option nicht versteht und (fehlerhaft) die Pakete verwirft.
Starten Sie die beiden Programme wieder wie oben. Beobachten Sie die Ausgaben von tcpdump
:
11:21:05.943114 Plato.suse.de.3874 > www.postbank.de.http: S 933875796:933875796(0) win 32120 <mss 1460,sackOK,timestamp 1892930261 0,nop,wscale 0> (DF) 11:21:06.088764 www.postbank.de.http > Plato.suse.de.3874: S 3593485934:3593485934(0) ack 933875797 win 10136 <nop,nop,timestamp 422243768 1892930261,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF) 11:21:06.088832 Plato.suse.de.3874 > www.postbank.de.http: . 1:1(0) ack 1 win 32120 <nop,nop,timestamp 1892930276 422243768> (DF) 11:21:06.090514 Plato.suse.de.3874 > www.postbank.de.http: P 1:927(926) ack 1 win 32120 <nop,nop,timestamp 1892930276 422243768> (DF) 11:21:06.264159 www.postbank.de.http > Plato.suse.de.3874: . 1:1(0) ack 927 win 9210 <nop,nop,timestamp 422243782 1892930276> (DF)
Symptom: Wie Sie im Unterschied zum obigen Beispiel sehen können wird hier zwischen beiden Rechnern die Verbindung richtig aufgebaut. Beide Rechner haben erfolgreich "Synchronisationspakete" (Die Pakete mit dem hervorgehobenen S) ausgetauscht. Es wurden sogar richtig Daten übertragen - das sehen Sie an dem Paket mit der eingeklammerten, hervorgehobenen 926. Üblicherweise klappt allerdings nur die Anfrage an den Webserver (hier: www.postbank.de). Nach dem Bestätigungspaket daß die Daten eingetroffen sind "hängt" die Verbindung. Normalerweise würde der Web-Server jetzt die Startseite übertragen. Offensichtlich klappt das aber nicht.
Analyse: Irgendwo auf dem Weg zu Ihnen geht das Paket des Web-Servers verloren. Sehr wahrscheinlich war es zu groß und konnte nicht fragmentiert werden (Das ist durch das "DF" Bit - sehen Sie am Zeilenende - verboten).
Workaround-Lösung: Siehe "T-DSL (u.a.): Manche Server sind nicht erreichbar" (http://sdb.suse.de/de/sdb/html/cg_pmtu2.html)
Eigentliche Fehlerursache: Falsch konfigurierte Firewall auf der Seite des Betreibers des Web-Servers die ICMP Pakete verwirft.
SDB-cg_internet
)