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

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_

*** Birgit Kellner wrote:

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

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

* 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 " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --

* 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 " PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --