DSL-Testfälle

Frage: Plötzlich funktioniert mein T-DSL nicht mehr, es lassen sich keine Web-Seiten aufrufen. Wie finde ich den Fehler?

Dr. Linux: Am besten mit dem einfachsten: Sind Sie sicher, dass Sie sich in der URL nicht verschrieben haben? Kontrollieren Sie die Schreibweise noch einmal genau. Ist der Web-Server erreichbar? Ein kurzes Ping kann Ihnen da schon weiterhelfen. Ist all dies als Fehlerquelle auszuschließen, haben Sie es mit einem handfesten Netzwerkproblem zu tun. Diesem wollen wir im Folgenden, so gut es geht, mit den Bordmitteln von Linux auf den Grund gehen.

Fangen wir also direkt am Anfang an: Glücklich ist, wer Leuchtdioden zur Statuskontolle am DSL-Modem hat. Falls vorhanden, sollte auf jeden Fall die Link-LED anzeigen, dass die Netzwerkkarte am Computer auf Hardware-Basis funktioniert.

Die Sync-LED macht eine Aussage über die Verbindung zum Einwahlknoten. Ist mit einer "Blickkontrolle" kein Fehler zu ermitteln, gibt es Software, die zur Diagnose genutzt werden kann.

Das bei DSL eingesetzte Protokoll "PPP over Ethernet" (PPPoE) setzt sowohl eine Ethernet-Schnittstelle als auch ein PPP-Device voraus. Diese Schnittstellen lassen Sie sich am einfachsten mit dem Befehl ifconfig auf der Kommandozeile anzeigen.

Bei einer funktionierenden DSL-Verbindung sollte die Ausgabe ungefähr wie in diesem Beispiel aussehen:

renner@hyaden:~$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:60:08:BA:82:99
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34154326 errors:23 dropped:0 overruns:20 frame:23
          TX packets:41041342 errors:0 dropped:0 overruns:0 carrier:0
          collisions:16329 txqueuelen:100
          RX bytes:1710005681 (1.5 GiB)  TX bytes:3907524253 (3.6 GiB)
          Interrupt:5 Base address:0x320
ppp0      Link encap:Point-to-Point Protocol
          inet addr:217.230.30.17  P-t-P:217.5.98.33  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:501327 errors:0 dropped:0 overruns:0 frame:0
          TX packets:635315 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:69141770 (65.9 MiB)  TX bytes:258409218 (246.4 MiB)

Deutlich sind die beiden Schnittstellen eth0 und ppp0 zu sehen. Die Netzwerkkarte eth0 braucht nicht unbedingt eine IP-Adresse, doch ppp0 benötigt sowohl eine eigene IP-Adresse als auch die IP-Adresse der Gegenstelle (Peer) der Verbindung.

Im Beispiel ist die IP-Adresse der Gegenstelle die 217.5.98.33. Ihre eigene IP-Adresse vergibt der Einwahlknoten dynamisch bei der Anwahl. Das heißt, Sie bekommen aus einem Pool von Adressen immer wieder eine neue zugewiesen. Diese Adressen können sich aber unterscheiden.

Hat das Interface ppp0 jedoch keine IP-Adresse, ist das ein Indiz dafür, dass der Einwahlknoten, aus welchen Gründen auch immer, keine IP-Adresse vergeben hat.

Frage: ppp0 ist da, die IP-Adresse des gegenüberliegenden Points ist auch da, lässt sich jedoch nicht anpingen. Außerdem ist eth0 nicht zu sehen. Dafür meldet ifconfig eine Schnittstelle tun0. Was hat diese zusätzliche Schnittstelle zu bedeuten?

Dr. Linux: Bei DSL-Modems mit USB-Schnittstelle wird statt der Ethernet-Schnittstelle eine virtuelle Schnittstelle wie tun0 oder tap0 verwendet. So lässt sich das Fehlen der Ethernet-Schnittstelle leicht erklären.

Dass der Peer nicht anzupingen ist, mag eine harmlose Ursache haben: Leider vernachlässigen immer mehr Provider den nicht-klickbaren Bereich des Internets und unterbinden Ping-Versuche auf ihre Einwahlknoten. Damit wird die Fehlersuche unnötig erschwert.

Glücklicherweise kommt Linux dem Anwender bei der Fehlersuche sehr entgegen, wird doch vieles in den Log-Dateien im Verzeichnis /var/log/ protokolliert. Welche Meldungen in welche Dateien geschrieben werden, ist jedoch von der verwendeten Distibution abhängig. Diese folgen unterschiedlichen Vorgaben in der Datei syslog.conf.

Gehen wir im Folgenden von einer durchschnittlichen Debian-Installation aus: Von besonderem Interesse sind die Dateien debug und daemon.log, in die das Programm pppoe seine Daten schreibt. Diese geben im Falle eines Fehler Aufschluss über mögliche Ursachen.

Hier findet man Meldungen, die die Kommunikation mit dem Einwahlknoten, die Übertragung von Account-Daten (inklusive des Dialogs, bei dem das Passwort übergeben wird) sowie Anmerkungen zum Verbindungsaufbau oder unerwarteten Verbindungsabbrüchen betreffen.

Sollten sich hier verdächtige Meldungen finden, kann es hilfreich sein den Debuglevel in der Datei /etc/ppp/options zu erhöhen, um dem Fehler weiter auf die Spur zu kommen.

Finden sich dort keine verdächtigen Einträge, ist ein Blick in die Dateien kernel.log, messages und syslog angeraten. In diesen Dateien protokolliert der Linux-Kernel unter anderem, Daten, die das PPP-Device und das Netzwerk betreffen.

Denkbar wäre eine Situation, in der die Verbindung zum DSL-Anbieter durchaus funktioniert, aber eine falsch konfigurierte Firewall die Pakete rausfiltert und verwirft. Auch Pakete, die von außen von einer Anwendung angefordert werden, können unter Umständen an einer Firewall hängen bleiben.

Generell ergibt es auch Sinn, die aktuellen Fehlermeldungen mit den Meldungen zu vergleichen, die geloggt wurden, als noch alles funktionierte.

Gibt der Blick in die Log-Dateien keinen eindeutigen Aufschluss über die Fehlerursache, kann man weitere Tests durchführen. Mit pppoe prüft man die Erreichbarkeit des Einwahlknoten (Access Concentrator). Dies geschieht mit folgendem Befehl:

hyaden:~# pppoe -I eth0 -A
Access-Concentrator: STGX12-erx
Got a cookie: 6a d3 82 2b 33 69 29 6b 5c 5f 8f 4d fe 0a 5b 70
————————————————–
AC-Ethernet-Address: 00:90:1a:10:14:77
————————————————–

Andere Rückmeldungen wie no such interface oder gar pppoe: Timeout waiting for PADO packets lassen auf Leitungsprobleme schließen, die verhindern, dass der Einwahlknoten erreicht wird. Ob der Einwahlknoten an sich funktioniert, lässt sich mit folgendem kleinen Test (wiederum mit Root-Rechten) ermitteln:

hyaden:~# pppoe -I eth0 -T 20 -D /tmp/pppoe.log

Wurde die Datei geschrieben, sieht sie bei funktionierender Verbindung zur Vermittlungsstelle wie in Listing 1 aus.

rp-pppoe-3.3
12:26:22.988 SENT PPPoE Discovery (8863) PADI sess-id 0 length 4
SourceAddr 00:60:08:ba:82:99 DestAddr ff:ff:ff:ff:ff:ff
01 01 00 00                                       ….
12:26:23.044 RCVD PPPoE Discovery (8863) PADO sess-id 0 length 38
SourceAddr 00:90:1a:10:14:77 DestAddr 00:60:08:ba:82:99
01 02 00 0a 53 54 47 58 31 32 2d 65 72 78 01 01   ….STGX12-erx..
00 00 01 04 00 10 6a d3 82 2b 33 69 29 6b 5c 5f   ……j..+3i)k\_
8f 4d fe 0a 5b 70                                 .M..[p
12:26:23.047 SENT PPPoE Discovery (8863) PADR sess-id 0 length 24
SourceAddr 00:60:08:ba:82:99 DestAddr 00:90:1a:10:14:77
01 01 00 00 01 04 00 10 6a d3 82 2b 33 69 29 6b   ……..j..+3i)k
5c 5f 8f 4d fe 0a 5b 70                           \_.M..[p
12:26:28.050 SENT PPPoE Discovery (8863) PADR sess-id 0 length 24
SourceAddr 00:60:08:ba:82:99 DestAddr 00:90:1a:10:14:77
01 01 00 00 01 04 00 10 6a d3 82 2b 33 69 29 6b   ……..j..+3i)k
5c 5f 8f 4d fe 0a 5b 70                           \_.M..[p
12:26:38.053 SENT PPPoE Discovery (8863) PADR sess-id 0 length 24
SourceAddr 00:60:08:ba:82:99 DestAddr 00:90:1a:10:14:77
01 01 00 00 01 04 00 10 6a d3 82 2b 33 69 29 6b   ……..j..+3i)k
5c 5f 8f 4d fe 0a 5b 70                           \_.M..[p

Verlaufen diese Tests erfolgreich, besteht unter Umständen ein Problem beim Routing der Datenpakete. Zuerst sollte mit route kontrolliert werden, dass die PPP-Schnittstelle die Defaultroute (0.0.0.0) für alle Verbindungen ist.

hyaden:~# route -n
Kernel IP routing table
Destination  Gateway      Genmask         Flags Metric Ref  Use Iface
217.5.98.33  0.0.0.0      255.255.255.255 UH    0      0      0 ppp0
0.0.0.0      217.5.98.33  0.0.0.0         UG    0      0      0 ppp0

Hier sehen wir, dass die direkte Verbindung zur IP-Adresse 217.5.98.33 eingetragen ist. In der Zeile darunter fängt der Eintrag 0.0.0.0 auch alle anderen IP-Adressen ab und leitet die Pakete über das Gateway ins Netz. In der letzten Zeile sehen Sie, dass jeweils bei beiden Einträgen das Interface ppp0 zum Einsatz kommt.

Haben Sie noch zusätzlich ein lokales Netzwerk über eine zweite Karte konfiguriert, finden Sie eine zusätzliche Zeile, die unter Umständen so aussieht:

192.168.1.0  0.0.0.0      255.255.255.0   U     0      0      0 eth1

Mit dieser Zeile leiten Sie alle IP-Pakete, die für das lokale Netzwerk bestimmt sind, auf das Interface eth1, also die zweite Netzwerkkarte um.

Ist das ebenfalls in Ordnung, dann gibt es nicht mehr viel, was mit Hausmitteln geprüft werden kann. Wichtig ist noch die Erreichbarkeit des Nameservers und dass dieser funktioniert. Seine IP-Adresse findet sich in der Datei /etc/resolv.conf.

Funktioniert ein ping auf eine beliebige IP-Adresse, auf Hostnamen jedoch nicht, ist schlicht der Nameserver ausgefallen oder nicht erreichbar.

Solch ein Ausfall dauert erfahrungsgemäß nicht lange und lässt sich aussitzen. Besser ist es jedoch, sich bei Gelegenheit über alle zur Verfügung stehenden Nameserver des Providers zu informieren und diese gegebenenfalls von Hand in die /etc/resolv.conf einzutragen.