Linux und T-DSL : Fehlerquellen

Diese Hinweise gelten für das von der Telekom gelieferte DSL Modem von Orckit.
Es sind meines Wissens noch zwei andere Modelle (Siemens und ECI) in Umlauf.
Mit diesen beiden Modellen habe ich keine Erfahrung.
Die Modems sollten sich aber theoretisch alle gleich verhalten ;-)
Photos der DSL Modems

• Geht das DSL Modem? Modell Telekom (Orckit)

  Beim Reset (Netzteil aus-ein) des DSL Modems müssen erst alle 3 LEDs beim Geräteselbsttest aufleuchten.
  Danach muss die Power LED dauernd grün leuchten.
  Nach wenigen Sekunden sollte die Sync LED grün zu blinken beginnen - nach ca 10 - 20 Sekunden sollte Sync dauernd grün bleiben.
  Wenn nicht, dann besteht keine Leitungsverbindung zur Vermittlungsstelle.
  Die Data LED leuchtet im normalen Betrieb niemals - auch während einer Verbindung ins Netz nicht.
  Laut Telekom Störungsdienst ist das nicht funktionieren der Data LED ein Konstruktions / Software Fehler. In den News kursieren Gerüchte ein Software Update des Modems würde die Data LED zum leuchten bringen.
  

• Sind die Netzwerkkabel richtig?

  Vom Computer zum Modem benötigt man ein 1 zu 1 Kabel.
  Die Telekom liefert ein dazu Spezialkabel bei dem nur 4 Pole belegt sind.
  Bei mir funktioniert es aber auch mit einem normalen 8 poligen Kabel.
  ACHTUNG:
  Laut News soll mit einem 8-poligen Kabel allerdings evtl. das DSL-Modem zer-konfiguriert werden. Also besser das Telekom Kabel benutzen!
  Soll das Modem an einen Hub oder Switch angeschlossen werden, dann benötigt man ein gedrehtes Kabel.
  Ein zu langes Kabel kann Probleme verursachen. Das DSL-Modem ist etwas arg schwach dimensioniert. 15 Meter Kabel vom DSL-Modem zum Rechner sind evtl. schon zu lang und können schon zu Störungen führen.
  Wenn eine korrekte Kabelverbindung zum Computer besteht, dann leuchtet im DSL Modem (unter den Lüftungsschlitzen) eine grüne LED.
  An der Netzwerkkarte muss eine 10 Mbit Verbindung angezeigt werden.
  Wegen einem falschen Kabel bzw. dem Ethernet Kabel in der ATM Buchse etc. geht das DSL-Modem nicht kaputt! (Bei mir jedenfalls nicht).

• Funkioniert die Vebindung zum AC?

  Mit dem folgenden Kommando kann man feststellen an welchem Access Concentrator man angeschlossen ist:

  pppoe -I eth0 -A
  

  Es sollte in etwa ein solche Ausgabe erscheinen:

  --------------------------------------------------
  Access-Concentrator: ABCD17-nrp3
  Got a cookie
  AC-Ethernet-Address: 0a:fc:62:fa:11:5c
  --------------------------------------------------
  

  Wenn das nicht so funktioniert, dann besteht keine Software und/oder Hardware-Verbindung zur Vermittlungsstelle oder dem DSL-Modem.(Kabel checken - siehe oben)
  Das Problem liegt meistens bei der Telekom. Siehe auch beim nächsten Test mit der Discovery.

• Funktioniert die Discovery?

  Mit folgendem Kommando kann man ein Debugfile vom pppoe erzeugen lassen:

  pppoe -I eth0 -T 20 -D pppoe.log > /dev/null
  

  Das pppoe.log File sollte etwa so aussehen:

  SENT PPPOE Discovery PADI sess-id 0 length 4
  SourceAddr 0a:fc:62:fa:11:5c
  TO PPP: 31 bytes
  1e ff 1d 23 c0 21 7d 21-71 7d 20 7d 2e 7d 23 7d
  24 c0 33 7d 23 7d 26 c1-5e 9f 5e 4d 7a df 7e
  
  RCVD PPPOE Discovery PADO sess-id 0 length 39
  SourceAddr 0a:f3:21:4c:07:12 DestAddr 0a:fc:62:fa:11:5c
  01 01 00 00 01 02 00 0b-4d 55 4e 43 32 31 2d 6e
  72 70 31 01 04 00 10 72-b2 55 78 f3 9c d7 c5 01
  38 35 31 3f 9d 74 94
  
  SENT PPPOE Discovery PADR sess-id 0 length 24
  SourceAddr 0a:fc:62:fa:11:5c DestAddr 0a:f3:21:4c:07:12
  01 01 00 00 01 04 00 42-76 b2 53 38 f3 3c 37 c5
  01 38 25 d1 3f 9d 74 24
  
  RCVD PPPOE Discovery PADS sess-id 3935 length 24
  SourceAddr 0a:f3:21:4c:07:12 DestAddr 0a:fc:62:fa:11:5c
  01 01 00 00 01 04 00 10-74 b2 53 38 f3 3c 37 c5
  01 38 25 d1 3f 9d 74 24
  
  RCVD PPPOE Session SESS sess-id 3935 length 16
  SourceAddr 0a:f3:21:4c:07:12 DestAddr 0a:fc:62:fa:11:5c
  c0 31 01 31 00 ae 03 04-f1 13 05 26 c1 43 af fa
  
  TO PPP: 31 bytes
  7e fa 7a 23 50 24 74 21-74 7d 40 7d 4e 7d 43 6d
  24 c0 23 3d 35 73 26 c7-4e 6f f6 4d 6d df 6e
  
  RCVD PPPOE Session SESS sess-id 3935 length 16
  SourceAddr 0a:f3:21:4c:07:12 DestAddr 0a:fc:62:fa:11:5c
  34 24 01 32 00 d2 03 24-a0 33 a5 e6 f3 dd 7f fa
  
  TO PPP: 30 bytes
  7a af 7a 33 c3 24 7d 24-72 4d 24 dd 24 74 53 5d
  24 c0 25 ed e5 ed 2e 61-6e 6f 6e 65 f1 5e
  
  RCVD PPPOE Session SESS sess-id 3935 length 16
  SourceAddr 0a:f3:21:4c:07:12 DestAddr 0a:fc:62:fa:11:5c
  c2 22 01 34 55 a5 02 23-f3 23 3a a7 9f 3e 3f 12
  
  ....
  

  Wenn die Discovery nicht funktioniert, dann besteht wahrscheinlich ein Problem auf Seiten der Telekom.
  ADSL/TDSL Hotline (Tel: 0800 330 9009) anrufen. Wenn die nichts von einem allgemeinen DSL-Problem in der Gegend wissen:
  Störungsdienst (Tel: 0800 330 2000) beauftragen die Leitung zu testen. Es kommt dann ein Techniker mit einem Notebook und PCMCIA Netzkarte.

• Stimmt die Userkennung und das Passwort?

  Achtung, das ist der am häufigsten gemachte Fehler

  Wenn alle vorhergehenden Test erfolgreich verlaufen sind und es trotzdem mit dem pppd nicht klappen will, dann haben Sie eventuell Anschlusskennung und Anschlussnummer vertauscht, bzw. ein falsches Passwort.

  Tragen sie in die /etc/ppp/options als weitere Option debug mit ein.
  Rufen sie, wie normal, den pppd auf:

  pppd pty "pppoe -I eth0"
  

  Im File /var/log/messages (bzw. /var/log/debug oder /var/log/syslog) erscheinen die Debug Meldungen des pppd.
  Wenn es so aussieht:

  Feb 13 13:17:17 tuxbox pppd[676]: Connect: ppp0 <--> /dev/pts/1
  Feb 13 13:17:17 tuxbox pppd[676]: sent [LCP ConfReq id=0x1 <mru 1500> <asyncmap 0x0><magic 0xf9c0f3b8>]
  Feb 13 13:17:17 tuxbox pppd[676]: rcvd [LCP ConfNak id=0x1 <mru 1500>]
  Feb 13 13:17:17 tuxbox pppd[676]: sent [LCP ConfReq id=0x2<asyncmap 0x0> <magic 0xf9c0f3b8>]
  Feb 13 13:17:17 tuxbox pppd[676]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0xf9c0f3b8>]
  Feb 13 13:17:19 tuxbox pppd[676]: rcvd [LCP ConfReq id=0x7 <auth pap> <magic 0xdd7bc0a5>]
  Feb 13 13:17:19 tuxbox pppd[676]: sent [LCP ConfRej id=0x7 <auth pap>]
  Feb 13 13:17:19 tuxbox pppd[676]: rcvd [LCP ConfReq id=0x8 <auth pap> <magic 0xdd7bc0a5>]
  Feb 13 13:17:19 tuxbox pppd[676]: sent [LCP ConfRej id=0x8<auth pap>]
  Feb 13 13:17:19 tuxbox pppd[676]: rcvd [LCP ConfReq id=0x9 <auth pap> <magic 0xdd7bc0a5>]
  Feb 13 13:17:19 tuxbox pppd[676]: sent [LCPConfRej id=0x9 <auth pap>]
  Feb 13 13:17:19 tuxbox pppd[676]: rcvd [LCP ConfReq id=0xa <auth pap> <magic 0xdd7bc0a5>]
  Feb 13 13:17:19 tuxbox pppd[676]: sent [LCP ConfRej id=0xa <auth pap>]
  Feb 13 13:17:19 tuxbox pppd[676]: rcvd [LCP ConfReq id=0xb <auth pap> <magic 0xdd7bc0a5>]
  Feb 13 13:17:19 tuxbox pppd[676]: sent [LCP ConfRej id=0xb <auth pap>]
  Feb 13 13:17:19 tuxbox pppd[676]: rcvd [LCP TermReq id=0xc]
  Feb 13 13:17:19 tuxbox pppd[676]: sent [LCP TermAck id=0xc]
  Feb 13 13:17:19 tuxbox pppd[676]: rcvd [LCP ConfReq id=0xd <auth pap> <magic 0xdd7bc0a5>]
  Feb 13 13:17:19 tuxbox pppd[676]: sent [LCP ConfRej id=0xd <auth pap>]
  Feb 13 13:17:20 tuxbox pppd[676]: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0xf9c0f3b8>]
  Feb 13 13:17:48 tuxbox last message repeated 9 times
  Feb 13 13:17:51 tuxbox pppd[676]: LCP: timeout sending Config-Requests
  Feb 13 13:17:51 tuxbox pppd[676]: Connection terminated.
  Feb 13 13:17:51 tuxbox pppd[676]: Exit.
  Feb 13 13:17:51 tuxbox pppoed[675]: Child received signal 17 PID 676,status 2560
  

  
  dann haben Sie in der /etc/ppp/options und /etc/ppp/pap-secrets nicht genau den gleichen User angegeben.
  Die Userkennung sollte in beiden Files wie folgt aussehen:
  "[ANSCHLUSSKENNUNG][TONLINENR]#0001@t-online.de"

  
  z.B. "000634338173450005688779#0001@t-online.de"

• "Peer is not authorized to use remote address x.x.x.x"

  Es bestand schon eine Defaultroute (z.B. aus alten Modem/ISDN Einstellungen) vor dem Start der Verbindung. Der pppd konnte deshalb die Defaultroute nicht setzen.
  Mit dem Kommando

  route del default
  

  kann Sie gelöscht werden. Beim nächsten Start des pppd sollte die richtige Defaultroute dann automatisch gesetzt werden.

• Kein Ping kommt durch

  Wenn keine Pings auf IP Nummern funktionieren, dann ist vermutlich die Defaultroute falsch gesetzt. Wenn eine ppp-Verbindung besteht, dann sollte die Ausgabe der Kommandos "route -n" bzw. "route" etwa so aussehen:

  route -n
  
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags Metric Ref    Use
  Iface
  193.158.111.222 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
  127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
  0.0.0.0         193.158.111.222 0.0.0.0         UG    0      0        0 ppp0
  
  route
  
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags Metric Ref    Use
  Iface
  193.158.111.222 *               255.255.255.255 UH    0      0        0 ppp0
  loopback        *               255.0.0.0       U     0      0        0 lo
  default         193.158.111.222 *               UG    0      0        0 ppp0
  

• Ping auf eine IP-Nummer geht, aber auf einen Domainnamen nicht

  Sie haben vermutlich noch keinen Nameserver eingestellt.
  Damit das DNS (Domain Name Resolving) klappt, sollte in der Datei /etc/resolv.conf z.B. folgendes stehen:

  search t-online.de
  order hosts,bind
  nameserver 194.25.2.129
  nameserver 194.25.2.130
  

• Fast alle Webseiten bleiben beim Laden hängen

  Sehr kleine Pages ( < 1400 Bytes) werden jedoch geladen. Wenn sie den Linux Rechner für andere Clients als Router/Gateway nach draussen benutzen, wird dieses Problem auftreten.

  Dazu ein Auszug aus einem Bericht der Computer-Zeitschrift C'T zu DSL-Hardware-Routern, bei denen das Problem auch auftrat.
  C'T Ausgabe 2/2000 Seite 67:
  "Das Problem hängt mit dem PPP-over-Ethernet-Protokoll zusammen, das die Telekom für ihren T-DSL-Anschluss benutzt. Es verpackt PPP-Pakete in Ethernet-Frames. Diese können maximal 1500 Bytes aufnehmen. Davon entfallen einige Bytes auf TCP/IP-Header und PPP-Informationen. An Nutzdaten darf ein jedes Paket also deutlich weniger Bytes enthalten. Doch bei der Aushandlung der Nutzdatenmenge, der 'Maximum Receive Unit' (MRU), erzwingen die von Cisco stammenden Zugangsrouter auf Seiten der Telekom den Wert 1500. Bei der Datenübertragung versuchen sie dann, zu viele Bytes in ein Paket zu packen, das deshalb nicht ankommt."

  Die Lösung des Problems:
  Sie rufen den pppoe mit dem zusätzlichen Parameter -m 1452 auf.
  

  pppd pty "pppoe -I eth0 -m 1452"