Fehlersuche bei Arktur

Fehlersuche bei Arktur - Netzzugang

DSL-Verbindung

Anleitung von Steffen Barth

Jürgen Gehlfus (fido.ger.linux)

Aber hast du mal geschaut, ob die grundsätzlichen Sachen funktionieren?

Läuft dein ppp0 interface?
Zu erfragen mit "/sbin/ifconfig" . Dann solltest du unter anderem so
was zu sehen bekommen.

--------------------------------------------------------------------------------
ppp0      Protokoll:Punkt-zu-Punkt Verbindung
          inet Adresse:80.135.157.219  P-z-P:217.5.98.69 Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:1379164 errors:0 dropped:0 overruns:0 frame:0
          TX packets:571540 errors:0 dropped:27 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:3
          RX bytes:229300574 (218.6 MiB)  TX bytes:48966218 (46.6 MiB)
 -------------------------------------------------------------------------------

Laufen die notwendigen Daemonen?

Zu erfragen mit "ps xa|grep ppp"

Dann sollte sowas erscheinen
-------------------------------------------------------------------------------

22419 ?        S      0:00 pppd call dsl-provider
17137 ?        S      1:19 pppoe -I eth1
-----------------------------------------------------------------------------

Ich setze mal voraus, dass auf deinem ADSL-Modem alle Anzeigen (LEDs)
einen normalen Betriebszustand anzeigen ;-).

Dann solltest du mit dem folgenden Befehl

"pppoe -I eth1 -A"

Die Verkabelung zwischen Modem  und Splitter zu dem Access-Concentrator läuft.

-----------------------------------------------------------------------------

Access-Concentrator: BOCX11-erx
Got a cookie: 2b 88 2b 40 84 f4 52 82 ad 1a bc 43 cd ed ec ff
--------------------------------------------------
AC-Ethernet-Address: 00:90:1a:10:11:de
--------------------------------------------------

mit "pppoe -T20 -I eth1 -D pppoe.log > /dev/null" kannst du
ueberprüfen, ob du eine Antwort bekommst.
im pppoe.log solltest du dann so was ähnliches sehen.

-----------------------------------------------------------------------------
rp-pppoe-3.3
08:56:51.900 SENT PPPoE Discovery (8863) PADI sess-id 0 length 4
SourceAddr 00:80:ad:30:9e:c5 DestAddr ff:ff:ff:ff:ff:ff 
01 01 00 00

08:56:51.955 RCVD PPPoE Discovery (8863) PADO sess-id 0 length 38
SourceAddr 00:90:1a:10:11:de DestAddr 00:80:ad:30:9e:c5
01 02 00 0a 42 4f 43 58 31 31 2d 65 72 78 01 01
00 00 01 04 00 10 2b 88 2b 40 84 f4 52 82 ad 1a
bc 43 cd ed ec ff

08:56:51.955 SENT PPPoE Discovery (8863) PADR sess-id 0 length 24
SourceAddr 00:80:ad:30:9e:c5 DestAddr 00:90:1a:10:11:de
01 01 00 00 01 04 00 10 2b 88 2b 40 84 f4 52 82
ad 1a bc 43 cd ed ec ff

Stephan Dreisbach
Hast du deinen Anschluss denn wieder synchronisiert?
Stecker ziehen vom Modem, warten, Stecker rein: Jetzt muss die Synchronisationsdiode erst rot sein, dann rot blinken und dann grün werden. Wenn nicht, liegt immer noch eine Störung bei der Telekom vor.
einige Fehlermeldungen:
- ```
LCP: timeout sending Config-Requests
```
  Überprüfe bitte die Verkabelung
  (aus dem Forum "intra2net.com", März 2005)
  das sind Symptome einer typischen DSL-Störung. Der Intranator hat eine Verbindung zum DSL-Modem, aber die Kommunikation zwischen Intranator und dem Einwahlknoten ist gestört. Da kann Ihnen leider nur die Telekom helfen.
  es war auch ein Telekom-Fehler. Der Modemtausch war erfolglos, und erst das umhängen auf einen anderen Port im Rack der Telekom hat Erfolg gebracht.
- ```
Remote Message: Request denied
```
  Überprüfe bitte die Login-Daten
- ```
Timeout Waiting for PADO packets. Check your setup and cables and try again.
```
  Wenn schon kein PADO ankommt, dann kannst Du beruhigt die typischen Fehlerquellen wie falsches Passwort etc. ausschließen (zumindest vorläufig). PADO timeout bedeutet, dass der pppd schon gar keinen AC findet; entweder, der falsche Treiber für die Netzwerkkarte wurde geladen, die Karte funktioniert nicht richtig, oder der Anschlusstyp ist falsch. ifconfig sollte Dir weiterhelfen.
  Michael Buchenrieder in de.comp.os.unix.linux.misc 24.06.04
  Ich habe einige Male die Erfahrung gemacht, dass ein Verbindungsaufbau unter Windows funktioniert, unter Linux nicht.
  Steht in der /var/log/messages "Timeout waiting for PADO packets", kommt vom Telekom-Port beim Verbindungsaufbau kein "Rückping" und Arktur legt auf. Windows-Rechner erwarten diesen "Rückping" nicht und es klappt. So hat es mir mal ein Telekom-Supportmitarbeiter erklärt und es klingt logisch. Da hilft dann nur noch ein Anruf bei der Telekom mit der Bitte, einen Port-Reset durchzuführen; danach hatte ich jedenfalls dieses Problem nicht mehr.
  Sigurd Mahr
Steffen Moser erklärt einige Mechanismen etwas ausführlicher

ISDN
Wenn die Telefonnummer des "NTBA" (das ist der weiße Kasten) bekannt ist:
- (als root)
```
tail -f /var/log/messages
```
- per Handy oder sonstigem amtsberechtigtem Telefon diese Nummer anrufen
  (sie wird als "besetzt" oder sonstwie nicht erreichbar gemeldet)
- auf dem Monitor (und in der Datei "/var/log/messages") muss angezeigt werden, dass Arktur angerufen worden ist und dass dieser Anruf nicht akzeptiert wurde (Arktur telefoniert nun mal nicht)
- Log-Meldungen beenden: "Strg-c"
Netzwerkkarte
- ```
ifconfig
```
  muss die Karte anzeigen (Ausnahme: Karte für DSL oder Router)
- ```
ping -c3 127.0.0.1
```
- ```
ping -c3 192.168.0.1
```
  (wenn es die 1. Karte ist)
- ```
ping -c3 x.y.z.w 
```
  (Adresse eines anderen Rechners im lokalen Netz)
Verbindung nach draußen
(als root)
- ```
ifconfig
```
  muss auch einen Eintrag "ippp0" oder "ppp0" für den Zugang zum Provider haben
  Sonderfall: bei Router-Betrieb muss stattdessen eine weitere Karte (z.B. "eth1") angezeigt werden
  - ISDN: erlaubt sind "ippp0", zusätzlich "ippp1" und vielleicht (bei Kanalbündelung) zusätzlich "ippp11"
  - DSL: nur 1 einziger Eintrag ist erlaubt, er muss "ppp0" heissen
- ```
ping -c3 zum.de
```
  muss spätestens beim zweiten Aufruf melden, wie lange die Pakete unterwegs sind.
  Weitere Zieladresse: "heise.de"
- ```
ping -c3 4.2.2.2
ping -c3 141.1.1.1
ping -c3 151.1.1.1
```
  Mindestens einer dieser Befehle muss melden, wie lange die Pakete unterwegs waren. Wenn "ping" auf die IP-Adresse funktioniert, aber "ping zum.de" nicht, dann funktioniert der "Name-Server" nicht.
  - Verbindung nach draussen sicher kappen:
```
	/etc/ppp/inet-off
```
  - nameserver stoppen
```
	killall named
```
  - nameserver starten
    Arktur 2.0 bis 3.3 Arktur 3.4 bis 3.6 und 5.0
    
    /sbin/init.d/named start
    
    /etc/init.d/named start
  - Kontrolle nach etwa 1 Minute
```
	pidof named
```
    muss eine Zahl liefern (Zahlenwert unerheblich)
  - wenn der nameserver sich verabschiedet haben sollte:
```
	named -D -d 5
```
    Die Ergebnisse des Startversuchs werden nach "/root/named.run" geschrieben: prüfen!
  - wenn der nameserver brav läuft:
    - Verbindung nach draussen aufbauen
    - ```
    ping -c3 4.2.2.2
```
  eventuell einmal wiederholen
- ```
ping -c3 rtl.de
```
      eventuell einmal wiederholen
- ```
pidof httpd
```
  muss etwa 5 Zahlen liefern; sonst ruht der Apache (der Webserver)
  Neustart: (als root)
  Arktur 2.0 bis 3.3 Arktur 3.4 bis 3.6 und 5.0
  /sbin/init.d/apache start
  
  /etc/init.d/apache start
- ```
pidof squid
```
  muss auch nach 5 Minuten noch eine Zahl liefern, sonst ruht der Proxy.
  Neustart: am besten mit dem Programm squidneu (als root)
```
/root/bin/squidneu
```
  (und dann 5 Minuten warten)
- Modem, ISDN, DSL
  Vielleicht liegen noch Reste von früheren Versuchen in "/var/lock" herum.
  Prinzip:
  - Verbindung beenden
  - Dann darf in "/var/lock" keine Datei existieren, in deren Namen "ppp" auftaucht
  .
  
  Weiter:
```
        ifconfig
```
  darf keinen Block anzeigen, bei dem ganz links "ppp" oder "ippp" steht.
  Und weder der PPP-Dämon noch der IPPP-Dämon darf (noch) laufen:
```
        ps waux | grep [p]pp
```
  Etliche dieser Probleme werden (eher nebenher) durch einen Neustart bereinigt, aber das ist keine sinnvolle Lösung.
  In meinem Programmpaket "raumfrei.zip" liegt auch das Skript "schaltaus"; das scheint solche Probleme auch ohne Neustart zu lösen.
E-Mail
- Post abholen
  
  Die Datei mit den Providerdaten heisst
```
	/etc/mail/fetchmailrc
```
  Sie sollte zuerst geprüft werden (richtige Schreibweise der Daten)
  Dann:
```
	fetchmail -vvv -f /etc/mail/fetchmailrc
```
  Fehler in der o.g. Datei führen sofort zu Meldungen (mitsamt Zeilennummer)
  Wenn die Post abgeholt werden konnte, sollte sie (vor allem) in "/var/spool/mail" liegen.
  Wenn "Netscape" zum Lesen der Post benutzt wird, dann sollte Post an einzelne Benutzer in deren Home-Verzeichnis im Unterverzeichnis "mail" (oder "Mail") liegen; dafür sorgt
```
	/home/<benutzer>/.procmailrc
```
- Post verschicken
  - SMTP
    Häufiger Fehler:
```
	550 x.y.z  ... relaying denied
```
    Fehlersuche:
    1. Verbindung nach draussen kappen
    2. Post an lokalen Benutzer schicken:
```
	mail postmaster
	(Betreff)	ping
	(Text)	pong
	(Text)	.
```
      das ist ein einzelner Punkt
      Muss an "root" weitergeleitet werden, muss (wenn keine sonstige Weiterleitung definiert ist), in "/var/log/root" landen.
    3. Post an den "Account" beim Provider schicken, z.B.
```
	mail xy2345@shuttle.de
	(Betreff)	ping
	(Text)	pong
	(Text)	.
```
    4. Post an einen geduldigen Empfänger schicken, z.B.
```
	mail ichselbst@web.de
	(Betreff)	ping
	(Text)	pong
	(Text)	.
```
    5. Kontrolle:
      diese beiden E-Mails müssen (mitsamt je einer weiteren Datei) in "/var/mqueue" oder (neuere Installation) "/var/spool/mqueue" landen.
      Einige Informationen über die (erfolgreiche oder aber fehlerhafte) Datenreise ist am Ende der Datei "/var/log/mail" zu finden (am sichersten über Datum und Uhrzeit zu identifizieren).
    6. Verbindung nach draussen aufbauen
    7. (als "sysadm")
      System nutzen/Mail- und Newsaustausch
      (das dauert eine Weile)
    8. "/var/mqueue" muss jetzt leer sein
      Nicht zustellbare E-Mails sollten dem Absender (hier: "root") gemeldet werden.
      Für weitere Fragen wichtig: wurden beide E-Mails abgewiesen?
  - UUCP
    
    Die Meldungen landen in einem Unterverzeichnis von "/var/spool/uucp"
isdn cause E0010
Wenn die ISDN-Verbindung nicht aufgebaut wird und u.a. "isdn cause E0010" oder "isdn cause E0410" gemeldet wird, dann kann der direkte Auslöser im Umfeld der Dateien des "revision control system" liegen.
Abhilfe:
- (als root) "PPP-chat" und "PPP-config" ins Verzeichnis "/etc/Systemverwaltung extrahieren
- im Unterverzeichnis "RCS" die zugehörigen Dateien durch Umbenennen sichern
- (als sysadm) System verwalten/Aktivieren
- isdn cause E001B
  
  Wenn in "/var/log/messages" nur einmal "isdn cause E001B" gemeldet wird, dann könnte ein Fehler in der Verkabelung sein.
  
  Wenn in "/var/log/messages" etwa im Minutentakt "isdn cause E001B" gemeldet wird, dann existiert die Verbindung zum Provider (meistens ja "t-online"), aber die Anmeldedaten werden nicht akzeptiert.
  
  Kontrolle dieser Vermutung: direkt nach der Einwahl beim Provider liefert der noch eine IP-Adresse ab, die nicht zum Netz 192.168.x.x gehört, und danach kommt "isdn cause E001B".
  
  Häufiger Auslöser: bei der zuständigen Stelle sind die Anmeldedaten vermatscht worden.
  
  Abhilfe bei T@School-Zugang
  - inoffizielle t@School-Seite
    insbesondere die FAQ hilft oft weiter
  - Telefonnummer des NTBA beschaffen (sollte auf einem Aufkleber auf dem NTBA stehen)
  - T-Online-Nummer beschaffen (steht auf dem Brief von T-Online, beginnt oft mit "7028" oder "5028")
  - T@School-Supportnummer (in Münster) 0800-56 777 56
  - eventuell (bei Leitungsproblemen) 0800 33 01172