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-DatenTimeout 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 wiederholenping -c3 rtl.de
eventuell einmal wiederholen
- Verbindung nach draussen sicher kappen:
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 meinem 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.
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:- Verbindung nach draussen kappen
- 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. - Post an den "Account" beim Provider schicken, z.B.
mail xy2345@shuttle.de (Betreff) ping (Text) pong (Text) .
- Post an einen geduldigen Empfänger schicken, z.B.
mail ichselbst@web.de (Betreff) ping (Text) pong (Text) .
- 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). - Verbindung nach draussen aufbauen
- (als "sysadm")
System nutzen/Mail- und Newsaustausch
(das dauert eine Weile) - "/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) 01805-724853
- eventuell (bei Leitungsproblemen) 0800 33 01172
- inoffizielle t@School-Seite
Sehr wahrscheinlich hat wegen der vielen Fehlversuche ausserdem die Sperr-Automatik von T-Online zugeschlagen: nach 3 Fehlversuchen wird der Zugang für den Rest des Tages blockiert. Also: Abwarten (und T trinken)