pppd ADSL LCP timeout
Hallo, ich versuche, mit SuSE 8.2 und einem Alcatel SpeedTouch 510/510i zum Netzwerk der Universität Wien zu verbinden, der Anleitung unter http://www.univie.ac.at/ZID/adsl/home/linux/adsl_linux.html folgend. Leider kriege ich immer wieder LCP timeouts: pppd 2.4.1 started by root, uid 0 Using interface ppp0 Connect: ppp0 <--> /dev/ttya0 LCP: timeout sending Config-Requests Connection terminated. Exit. Mit dem Laptop, auf dem Windows 2000 läuft, bekomme ich die Verbindung problemlos hin. Gehe ich recht in der Annahme, dass die Timeouts bedeuten, die Gegenseite reagiert nicht auf meine Anfragen? Wenn ja: Wieso macht sie das dann beim Win2K-Laptop? Oder sollte ich in /etc/ppp/options irgendwelche, äh, timeout-bezogenen Optionen angeben? Danke! Birgit Kellner
Moin Moin Birgit On Saturday 11 October 2003 19:53, Birgit Kellner wrote: [...]
ich versuche, mit SuSE 8.2 und einem Alcatel SpeedTouch 510/510i zum Netzwerk der Universität Wien zu verbinden, der Anleitung unter http://www.univie.ac.at/ZID/adsl/home/linux/adsl_linux.html folgend. Nö, tust du nicht! Du bist unfolgsam werd ich dir auch gleich beweisen.
Aber erst mal würde ich zur Entspannung vorschlagen: Brille putzen, Entspannungsübungen für die Augenmuskulatur, einen erholsamen Waldspaziergang für die strapazierten Klüsen, die Anleitung noch einmal aber mit grösserer Schriftgrösse ausdrucken. *grins*
Leider kriege ich immer wieder LCP timeouts:
pppd 2.4.1 started by root, uid 0
pppd ist falsch. Du bist nicht nach der Anleitung der Uni vorgegangen: pp_T_p ist nicht ppp_D_ PPTP installieren Für die ADSL-Verbindung benötigen Sie PPTP (Point to Point Tunneling Protocol). Damit Sie dieses Protokoll unter Linux verwenden können, muß der PPTP-Client installiert werden. Installiere das pptp RPM Paket deiner SuSE Distribution. und mach wie in der Anleitung beschrieben weiter. Am besten ausdrucken und Stück für Stück abwerkeln, so habs ich früher immer gemacht ;-) Und sonst gilt, einfach im RZ vorbeischaun und flehentlich um Hilfe winseln. Einer der Hiwis wird sich schon deiner erbarmen. Zumindestens haben wir uns früher immer erbarmt wenn wieder einmal so ein Erstsemesterwürstchen um Hilfe gefleht hat. *lach*
Using interface ppp0 Connect: ppp0 <--> /dev/ttya0 LCP: timeout sending Config-Requests Connection terminated. Exit.
Mit dem Laptop, auf dem Windows 2000 läuft, bekomme ich die Verbindung problemlos hin.
Gehe ich recht in der Annahme, dass die Timeouts bedeuten, die Gegenseite reagiert nicht auf meine Anfragen? Wenn ja: Wieso macht sie das dann beim Win2K-Laptop? Oder sollte ich in /etc/ppp/options irgendwelche, äh, timeout-bezogenen Optionen angeben? {...] Noch schlimmer, deine Gegenseite bekommt nicht mal mit das du an der Strippe hängst und flehentlich um einlass winselst. Und wenn's denn jetzt klappt dan kannst du herzhaft in die Tischkante beissen oder mit der Stirn auf die Schreibtischplatte dengeln, was dir so beliebt... *lach*
Tschüss, Thomas -- Diese Adresse wird nur für die SuSE-Linux Liste benutzt. Mails die nicht über die SuSE Liste kommen erreichen mich _garantiert_nicht_
Thomas Templin wrote:
Moin Moin Birgit On Saturday 11 October 2003 19:53, Birgit Kellner wrote: [...]
ich versuche, mit SuSE 8.2 und einem Alcatel SpeedTouch 510/510i zum Netzwerk der Universität Wien zu verbinden, der Anleitung unter http://www.univie.ac.at/ZID/adsl/home/linux/adsl_linux.html folgend.
Nö, tust du nicht! Du bist unfolgsam werd ich dir auch gleich beweisen.
Aber erst mal würde ich zur Entspannung vorschlagen: Brille putzen, Entspannungsübungen für die Augenmuskulatur, einen erholsamen Waldspaziergang für die strapazierten Klüsen, die Anleitung noch einmal aber mit grösserer Schriftgrösse ausdrucken. *grins* Du bist nicht nach der Anleitung der Uni vorgegangen:
pp_T_p ist nicht ppp_D_
PPTP installieren Für die ADSL-Verbindung benötigen Sie PPTP (Point to Point Tunneling Protocol). Damit Sie dieses Protokoll unter Linux verwenden können, muß der PPTP-Client installiert werden.
Äh, man lese man pptp: "By default, pptp establishes the PPTP call to the PPTP server, and then starts an instance of pppd to manage the data transfer." pptp war natürlich schon installiert, und die Verbindung wurde mit "pptp 10.0.0.138" aufgerufen. Dein Hinweis war freundlich, wenn auch reichlich oberlehrerhaft formuliert, aber jedenfalls ging er an der Sache vorbei. Ich habe jetzt pptp und ppp jedenfalls auf den letzten Stand aktualisiert und vorläufig die Firewall deaktiviert. Jetzt kriege ich zwar irgendeine Verbindung, bin aber nicht sicher, welche. Wenigstens sind die Timeouts weg. Was passiert, ist Folgendes: pptp verbindet unter Verwendung des interface ppp0. Die Pakete fliegen hin und her, und die CHAP authentication verläuft erfolgreich. Dann gibt's die folgende Meldung im Debugger: "not replacing existing default route to eth0 [10.0.0.138] local IP address 131.130.134.59 remote IP address 193.170.184.1. Script /etc/ppp/ip-up started (pid 5436) Script /etc/ppp/ip-up finished (pid 5346), status = 0x0 Script ?? finished (pid 5328), status = 0x0" Dann folgen Ketten von sent- und rcvd-Meldungen. Ich kann dann die remote address 193.170.184.1 erfolgreich anpingen, aber sonst nichts, weder über IP-Adresse noch über Server-Namen. ifconfig zeigt, dass eth0 mit IP 10.0.0.140 konfiguriert ist und ppp0 mit 131.130.134.59. Ich hab's auch schon ohne die vom Provider vorgegebene Option "defaultroute" in /etc/ppp/options versucht, aber das Ergebnis ist dasselbe (bis auf die erste Zeile "not replacing existing ...", die fehlt dann). Bei einer korrekten Verbindung sollte die "remote address" eigentlich auch im Bereich 131.130 sein, denke ich, oder? Kann mir da jemand auf die Sprünge helfen? (http://pptpclient.sourceforge.net/howto-diagnosis.phtml gelesen, aber da ich so überhaupt nicht weiß, wo mein Problem liegt, weiß ich auch nicht, was davon ich beherzigen soll.) Danke! Birgit Kellner
Michael Meyer wrote:
*** Birgit Kellner
wrote: Ich kann dann die remote address 193.170.184.1 erfolgreich anpingen, aber sonst nichts, weder über IP-Adresse noch über Server-Namen.
zeige doch mal bitte den output von `route -n' _nach_ verbindungsaufbau.
micha
Sieht so aus: Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 193.170.184.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 eth0 Birgit
*** Birgit Kellner
Michael Meyer wrote:
*** Birgit Kellner
wrote: Ich kann dann die remote address 193.170.184.1 erfolgreich anpingen, aber sonst nichts, weder über IP-Adresse noch über Server-Namen.
zeige doch mal bitte den output von `route -n' _nach_ verbindungsaufbau.
Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 193.170.184.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 eth0
danke, dass du dir so viel mühe gegeben hast, die ausgabe von `route -n' so _übersichtlich_ darzustellen. nimm mal `defaultroute' wieder in die `/etc/ppp/options' auf, entferne die derzeitige defaultroute mit `route del default' und versuche nochmal einen verbindungsaufbau. wenn es jetzt immer noch nicht klappt, zeige nochmal den output von `route -n' _nach_ verbindungsaufbau. dann zeige auch mal die meldungen in `/var/log/messages' _beim_ verbindungsaufbau. micha
Michael Meyer wrote:
Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 193.170.184.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 eth0
danke, dass du dir so viel mühe gegeben hast, die ausgabe von `route -n' so _übersichtlich_ darzustellen.
es freut mich, dass meine bemühungen zur perfektion von whitespace-einsatz so aufmerksam registriert werden.
nimm mal `defaultroute' wieder in die `/etc/ppp/options' auf, entferne die derzeitige defaultroute mit `route del default' und versuche nochmal einen verbindungsaufbau.
jetzt funktioniert's, bin mit der kiste im netz. route -n gibt jetzt folgendes aus: Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 193.170.184.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0 0.0.0.0 193.170.184.1 0.0.0.0 UG 0 0 0 ppp0 der entscheidende unterschied dürften der eintrag von 193.170.184.1 als router in der dritten zeile und der von "ppp0" am schluss sein (da war vorher "eth0"). ganz kapiere ich das alles nicht, aber es funktioniert jedenfalls. mal sehen, wie's bei aktivierung der firewall aussieht. danke, birgit
Hallo Birgit, hallo Michael, hallo Leute, Am Montag, 13. Oktober 2003 23:10 schrieb Birgit Kellner:
Michael Meyer wrote: [...]
nimm mal `defaultroute' wieder in die `/etc/ppp/options' auf, entferne die derzeitige defaultroute mit `route del default' und versuche nochmal einen verbindungsaufbau.
jetzt funktioniert's, bin mit der kiste im netz. [...]
Dann solltest Du Deine /etc/ppp/options noch ein wenig ergänzen, damit Du nicht immer manuell die default route löschen musst ;-) defaultroute # hast Du ja inzwischen drinstehen replacedefaultroute # nachtragen IIRC ist das übrigens etwas, das sich mit neueren Versionen [1] des pppd geändert hat - alte Versionen [1] hatten replacedefaultroute wohl als Standardeinstellung. Gruß Christian Boltz [1] _IIRC_ ist bei mir das Problem beim Umstieg auf SuSE 8.1 (von 7.3) aufgetreten. Frag aber bitte nicht nach genauen Versionsnummern ;-) -- Nobody will ever need more than 640 kB RAM. -- Bill Gates, 1983 Windows XP requires 64 MB RAM. -- Bill Gates, 2001 Nobody will ever need Windows XP. -- logical conclusion
Hallo Christian,
Dann solltest Du Deine /etc/ppp/options noch ein wenig ergänzen, damit Du nicht immer manuell die default route löschen musst ;-)
defaultroute # hast Du ja inzwischen drinstehen replacedefaultroute # nachtragen
IIRC ist das übrigens etwas, das sich mit neueren Versionen [1] des pppd geändert hat - alte Versionen [1] hatten replacedefaultroute wohl als Standardeinstellung.
Danke, Du nimmst mit der Antwort meine nächste Frage vorweg. Leider mag pppd die Option "replacedefaultroute" in den "options" nicht: "unrecognized option" meint er und bricht den Prozeß ab. Scheinbar kann man das umgehen, indem man "replacedefaultroute" in eine der /etc/ppp/peers-Dateien einträgt. Aber welche nehm ich denn da? Zur Auswahl stehen: capi-isdn kppp ppp pppoatm pppoe pppoe-rp t-dsl wvdial Ich würde mal auf eine der "ppp"-Dateien tippen - aber, ahem, welche? Oder eine neue Datei einrichten? [Nochmal: Ich versuche das mit einer österreichischen ADSL-Verbindung zu AON.] Danke, Birgit
* Mittwoch, 15. Oktober 2003 um 18:35 (+0200) schrieb Birgit Kellner:
Danke, Du nimmst mit der Antwort meine nächste Frage vorweg. Leider mag pppd die Option "replacedefaultroute" in den "options" nicht: "unrecognized option" meint er und bricht den Prozeß ab.
Scheinbar kann man das umgehen, indem man "replacedefaultroute" in eine der /etc/ppp/peers-Dateien einträgt. Aber welche nehm ich denn da? Zur Auswahl stehen:
[ ... ]
Das wird dir nichts nützen, aus 2 Gründen:
1. Falls du den pptp-Client wie bei der Uni-Wien beschrieben startest,
dann wird keine der Dateien unter /etc/ppp/peers eingelesen.
2. Die Option "replacedefaultroute" wird in den pppd-2.4.2bX nicht
mehr unterstützt (egal wo sie steht).
Sie war in 99% aller Fälle unnötig und wurde dann meist nur zum
Kaschieren einer fehlerhaften Netzwerk-Konfiguration benutzt.
Und der letzte Absatz unter Punkt 2 trifft wahrscheinlich auch bei dir
zu:
Lösche in der Konfiguration der Netzwerkkarte den Eintrag/Haken
"Default-Route"/"Standard-Gateway"(?).
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Andreas Koenecke wrote:
Das wird dir nichts nützen, aus 2 Gründen:
1. Falls du den pptp-Client wie bei der Uni-Wien beschrieben startest, dann wird keine der Dateien unter /etc/ppp/peers eingelesen.
2. Die Option "replacedefaultroute" wird in den pppd-2.4.2bX nicht mehr unterstützt (egal wo sie steht). Sie war in 99% aller Fälle unnötig und wurde dann meist nur zum Kaschieren einer fehlerhaften Netzwerk-Konfiguration benutzt.
Und der letzte Absatz unter Punkt 2 trifft wahrscheinlich auch bei dir zu: Lösche in der Konfiguration der Netzwerkkarte den Eintrag/Haken "Default-Route"/"Standard-Gateway"(?).
Gruß
Andreas
Danke. Ich wußte nicht genau, wie ich das mit YaST mache (bzw. YaST ließ mich unter SuSE 8.2 den Standard-Gateway nicht entfernen). Daher habe ich den entsprechenden Eintrag direkt aus /etc/sysconfig/network/routes gelöscht, und jetzt geht's. Jetzt bleibt nur noch die Frage: Wie sorge ich dafür, dass der Befehl "pptp 10.0.0.138" beim Hochfahren automatisch ausgeführt wird? Gruß Birgit
* Freitag, 17. Oktober 2003 um 18:05 (+0200) schrieb Birgit Kellner:
Jetzt bleibt nur noch die Frage: Wie sorge ich dafür, dass der Befehl "pptp 10.0.0.138" beim Hochfahren automatisch ausgeführt wird?
Sauber geht das IMHO nur über ein eigenes rc-Skript.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Monday 13 October 2003 00:17, Birgit Kellner wrote: > Thomas Templin wrote: > >Moin Moin Birgit > >On Saturday 11 October 2003 19:53, Birgit Kellner wrote: > >[...] > > > >>ich versuche, mit SuSE 8.2 und einem Alcatel SpeedTouch > >> 510/510i zum Netzwerk der Universität Wien zu verbinden, der > >> Anleitung unter > >> http://www.univie.ac.at/ZID/adsl/home/linux/adsl_linux.html > >> folgend. > > > >Nö, tust du nicht! > >Du bist unfolgsam werd ich dir auch gleich beweisen. > > > >Aber erst mal würde ich zur Entspannung vorschlagen: > >Brille putzen, Entspannungsübungen für die Augenmuskulatur, > > einen erholsamen Waldspaziergang für die strapazierten Klüsen, > > die Anleitung noch einmal aber mit grösserer Schriftgrösse > > ausdrucken. *grins* > >Du bist nicht nach der Anleitung der Uni vorgegangen: > > > > > >pp_T_p ist nicht ppp_D_ > > > >PPTP installieren > >Für die ADSL-Verbindung benötigen Sie PPTP (Point to Point > > Tunneling Protocol). Damit Sie dieses Protokoll unter Linux > > verwenden können, muß der PPTP-Client installiert werden. > > Äh, man lese man pptp: Touche... Glatt erwischt. :o) > "By default, pptp establishes the PPTP call to the PPTP server, > and then starts an instance of pppd to manage the data transfer." > pptp war natürlich schon installiert, und die Verbindung wurde > mit "pptp 10.0.0.138" aufgerufen. Dein Hinweis war freundlich, > wenn auch reichlich oberlehrerhaft formuliert, aber jedenfalls > ging er an der Sache vorbei. Ööerks, hhm fühlte mich nur an meine ersten Paddeligkeiten beim Verbindungsaufbau zur Hochschule erinnert und konnte bei der Antwort nur schwer ein breites Grinsen unterdrücken. Hätte wohl einige mehr :o) und :-) und ;-) einstreuen sollen. *grins* pptp ist eine speziell im Austrischen/Nedelandse Bereich eingesetzte Technik. Ich kenns bisher nur von den Kollegen aus den Niederlanden. > Ich habe jetzt pptp und ppp jedenfalls auf den letzten Stand > aktualisiert und vorläufig die Firewall deaktiviert. Jetzt kriege > ich zwar irgendeine Verbindung, bin aber nicht sicher, welche. > Wenigstens sind die Timeouts weg. > > Was passiert, ist Folgendes: pptp verbindet unter Verwendung des > interface ppp0. Die Pakete fliegen hin und her, und die CHAP > authentication verläuft erfolgreich. Dann gibt's die folgende > Meldung im Debugger: Welcher debugger? Wichtig ist erst mal was in die /var/log/messages geschrieben wird. Ich hab in solchen Fällen immer ein xterm auf in dem ich die messages mit tail'e. s.u. > "not replacing existing default route to eth0 [10.0.0.138] > local IP address 131.130.134.59 > remote IP address 193.170.184.1. > Script /etc/ppp/ip-up started (pid 5436) > Script /etc/ppp/ip-up finished (pid 5346), status = 0x0 > Script ?? finished (pid 5328), status = 0x0" > > Dann folgen Ketten von sent- und rcvd-Meldungen. > > Ich kann dann die remote address 193.170.184.1 erfolgreich > anpingen, aber sonst nichts, weder über IP-Adresse noch über > Server-Namen. ifconfig zeigt, dass eth0 mit IP 10.0.0.140 > konfiguriert ist und ppp0 mit 131.130.134.59. Ich hab's auch > schon ohne die vom Provider vorgegebene Option "defaultroute" in > /etc/ppp/options versucht, aber das Ergebnis ist dasselbe (bis > auf die erste Zeile "not replacing existing ...", die fehlt > dann). > > Bei einer korrekten Verbindung sollte die "remote address" > eigentlich auch im Bereich 131.130 sein, denke ich, oder? Muss nicht. Kann als Routing Point sein eigendlich beliebig sein. > Kann mir da jemand auf die Sprünge helfen? > (http://pptpclient.sourceforge.net/howto-diagnosis.phtml gelesen, > aber da ich so überhaupt nicht weiß, wo mein Problem liegt, weiß > ich auch nicht, was davon ich beherzigen soll.) - was siehst du wenn du ein "tail -f /var/log/messages" machst während die Verbindung aufgebaut wird - Was steht in deiner /etc/sysconfig/network/ifcfg-eth0 - was steht in der /etc/resolv.conf nameserver 131.130.1.11 nameserver 131.130.1.12 - was sagt ein "route -n" (- was sagt ein "iptables -L") wenn's die Zeit hergibt - kannst du den Rechner 131.130.1.11 mit seiner IP pingen? Tschüss, Thomas -- Diese Adresse wird nur für die SuSE-Linux Liste benutzt. Mails die nicht über die SuSE Liste kommen erreichen mich _garantiert_nicht_
participants (5)
-
Andreas Koenecke
-
Birgit Kellner
-
Christian Boltz
-
Michael Meyer
-
Thomas Templin