Linux-Einwahl in Linux-Server klappt nicht; Win-Einwahl geht...
Hallo zusammen, ich habe hier zwei SuSE 9.1-Rechner (Laptop+Server). Jetzt will ich mich vom Laptop in den Server per Modem einwählen. Bei meiner Google-Suche bin ich auf mgetty+pppd gestoßen. Also ich dann sofort ans werk und auf dem Server die /etc/ppp/options erweitert mit proxyarp passive 192.168.0.251:192.168.0.250 require-chap refuse-pap und in /etc/inittab mo:235:respawn:/usr/sbin/mgetty -s 115200 modem aktiviert. Eine Einwahl mit dem Windows-DFÜ-Netz vom Laptop klappt auch sehr gut. Aber will ich mich mit kinternet von der SuSE-Partiton des Laptops aus auf den Server einwählen, bekomme ich keine IP-Verbindung hin. Ich glaube es muß irgentwas mit LCP zu tun haben. Kennt sich da einer von euch aus? Gruß Gerd. PS: hier das Protokoll von kinternet: SuSE Meta pppd (smpppd-ifcfg), Version 1.16 on Shadow. Status is: disconnected trying to connect to smpppd connect to smpppd Status is: disconnected Status is: connecting pppd[0]: Plugin passwordfd.so loaded. pppd[0]: --> WvDial: Internet dialer version 1.54.0 pppd[0]: --> Initializing modem. pppd[0]: --> Sending: ATM1 pppd[0]: ATM1 pppd[0]: OK pppd[0]: --> Modem initialized. pppd[0]: --> Sending: ATDTxxxxxxxxxxxxx pppd[0]: --> Waiting for carrier. pppd[0]: ATDTxxxxxxxxxxxxxxx pppd[0]: CONNECT 31200 pppd[0]: --> Carrier detected. Waiting for prompt. pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel pppd[0]: (l). pppd[0]: Galaxy-L!login: pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel pppd[0]: (l). pppd[0]: Galaxy-L!login: pppd[0]: --> Looks like a login prompt. pppd[0]: --> Sending: limbeck pppd[0]: limbeck pppd[0]: Password: pppd[0]: --> Looks like a password prompt. pppd[0]: --> Sending: (password) pppd[0]: Last login: Sun Sep 12 15:40:08 from 192.168.0.250 pppd[0]: Have a lot of fun... pppd[0]: limbeck@Galaxy-L:~> pppd[0]: --> Hmm... a prompt. Sending "ppp". pppd[0]: ppp pppd[0]: -bash: ppp: command not found pppd[0]: limbeck@Galaxy-L:~> pppd[0]: --> Hmm... a prompt. Sending "ppp". pppd[0]: ppp pppd[0]: -bash: ppp: command not found pppd[0]: limbeck@Galaxy-L:~> pppd[0]: --> Hmm... a prompt. Sending "ppp". pppd[0]: --> Don't know what to do! Starting pppd and hoping for the best. pppd[0]: Serial connection established. pppd[0]: Using interface ppp0 Status is: connecting pppd[0]: Connect: ppp0 <--> /dev/modem Status is: disconnecting pppd[0]: Terminating on signal 15. Status is: disconnecting pppd[0]: Connection terminated. Status is: disconnected pppd[0] died: non-normal exit
* Sonntag, 12. September 2004 um 16:37 (+0200) schrieb Gerd Limbeck:
ich habe hier zwei SuSE 9.1-Rechner (Laptop+Server). Jetzt will ich mich vom Laptop in den Server per Modem einwählen. Bei meiner Google-Suche bin ich auf mgetty+pppd gestoßen. Also ich dann sofort ans werk und auf dem Server die /etc/ppp/options erweitert mit
proxyarp passive 192.168.0.251:192.168.0.250 require-chap refuse-pap
(Während der Testphase würde ich noch "debug" hinzufügen.)
und in /etc/inittab
mo:235:respawn:/usr/sbin/mgetty -s 115200 modem
aktiviert. Eine Einwahl mit dem Windows-DFÜ-Netz vom Laptop klappt auch sehr gut.
Dann ist vermutlich mgettys "AutoPPP" aktiviert (Das ist prinzipiell gut, nützt aber mit 'WvDial' nichts...). Aber kontrolliere doch bitte trotzdem, ob die Zeile beginnend mit "/AutoPPP/" in "/etc/mgetty+sendfax/login.config" nicht auskommentiert ist.
Aber will ich mich mit kinternet von der SuSE-Partiton des Laptops aus auf den Server einwählen, bekomme ich keine IP-Verbindung hin.
[ ... ]
PS: hier das Protokoll von kinternet:
[ ... ]
pppd[0]: --> Carrier detected. Waiting for prompt. pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel pppd[0]: (l). pppd[0]: Galaxy-L!login: pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel pppd[0]: (l). pppd[0]: Galaxy-L!login: pppd[0]: --> Looks like a login prompt. pppd[0]: --> Sending: limbeck pppd[0]: limbeck pppd[0]: Password: pppd[0]: --> Looks like a password prompt. pppd[0]: --> Sending: (password) pppd[0]: Last login: Sun Sep 12 15:40:08 from 192.168.0.250 pppd[0]: Have a lot of fun... pppd[0]: limbeck@Galaxy-L:~> pppd[0]: --> Hmm... a prompt. Sending "ppp". pppd[0]: ppp pppd[0]: -bash: ppp: command not found [ ... ]
Jedes der beiden beteiligten Programme ('mgetty' und 'wvdial') erwartet, dass
das andere Programm mit dem LCP-Handshake beginnt. Nach kurzer Zeit startet
'mgetty' deshalb 'login'...
Es gibt mehrere Möglichkeiten zur Abhilfe. Die am wenigsten aufwändigen sind
IMHO:
1. 'wvdial' so konfigurieren, dass es die Verbindung im "Stupid Mode" (siehe
'man 5 wvdial.conf') aufbaut. ('wvdial' startet dann sofort nach dem
Verbindungsaufbau den 'pppd', so dass 'mgettys' AutoPPP-Feature zum Einsatz
kommen kann.)
oder
2. Auf dem Server eine ausführbare Datei oder einen Shell-Alias mit Namen
"ppp" anlegen, in denen der 'pppd' gestartet wird. (Die 'pppd'-Optionen aus
der "/AutoPPP/"-Zeile in "/etc/mgetty+sendfax/login.config" nehmen.)
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Hallo Andreas, danke für Deine Antwort. Jedoch habe ich bislang noch keinen Erfolg gehabt. Deine Hinweise habe ich verfolgt: 1.) In /etc/mgetty+sendfax/login.config steht: /AutoPPP/ - a_ppp /usr/sbin/pppd auth * - - /bin/login @ 2.) der "Stupid Mode" in /etc/wvdial.conf scheint aktiv zu sein: [Dialer Defaults] Modem = /dev/modem Baud = 57600 Init1 = ATZ Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 Init3 = Area Code = Phone = 0 Username = Password = Ask Password = 0 Dial Command = ATDT Stupid Mode = 1 Compuserve = 0 Force Address = Idle Seconds = 300 DialMessage1 = DialMessage2 = ISDN = 0 Auto DNS = 1 3.) Schließlich habe auf dem server ein /usr/bin/ppp mit folgenden Inhalt angelegt: "/usr/sbin/pppd auth". Nun bringt kinternet mir etwas andere Meldungen, jedoch scheint da immer noch was nicht zustimmen: SuSE Meta pppd (smpppd-ifcfg), Version 1.16 on Shadow. Status is: disconnected trying to connect to smpppd connect to smpppd Status is: disconnected Status is: connecting pppd[0]: Plugin passwordfd.so loaded. pppd[0]: --> WvDial: Internet dialer version 1.54.0 pppd[0]: --> Initializing modem. pppd[0]: --> Sending: ATM1 pppd[0]: ATM1 pppd[0]: OK pppd[0]: --> Modem initialized. pppd[0]: --> Sending: ATDTxxx pppd[0]: --> Waiting for carrier. pppd[0]: ATDTxxx pppd[0]: CONNECT 33600 pppd[0]: --> Carrier detected. Waiting for prompt. pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel pppd[0]: (l). pppd[0]: Galaxy-L!login: pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel pppd[0]: (l). pppd[0]: Galaxy-L!login: pppd[0]: --> Looks like a login prompt. pppd[0]: --> Sending: limbeck pppd[0]: limbeck pppd[0]: Password: pppd[0]: --> Looks like a password prompt. pppd[0]: --> Sending: (password) pppd[0]: Last login: Mon Sep 13 23:36:30 on modem pppd[0]: Have a lot of fun... pppd[0]: limbeck@Galaxy-L:~> pppd[0]: --> Hmm... a prompt. Sending "ppp". pppd[0]: ppp pppd[0]: ~[7f]}#@!}!}!} }9}"}&} } } } }#}%B#}%}%}&[1e]Vko}'}"}(}"71~ pppd[0]: --> PPP negotiation detected. pppd[0]: Serial connection established. pppd[0]: Using interface ppp0 Status is: connecting pppd[0]: Connect: ppp0 <--> /dev/modem pppd[0]: LCP terminated by peer (Authentication failed) pppd[0]: Connection terminated. Status is: disconnected pppd[0] died: PPP negotiation failed (exit code 10) Weitere Hinweise? Gruß Gerd
* Dienstag, 14. September 2004 um 00:06 (+0200) schrieb Gerd Limbeck:
2.) der "Stupid Mode" in /etc/wvdial.conf scheint aktiv zu sein: [Dialer Defaults] [ ... ] Stupid Mode = 1 [ ... ]
Yepp, das sieht so aus. Seltsam, dass 'wvdial' laut 'kinternet/smppd'-Log trotzdem auf ein Prompt wartet... Aber egal.
3.) Schließlich habe auf dem server ein /usr/bin/ppp mit folgenden Inhalt angelegt: "/usr/sbin/pppd auth". Nun bringt kinternet mir etwas andere Meldungen, jedoch scheint da immer noch was nicht zustimmen:
SuSE Meta pppd (smpppd-ifcfg), Version 1.16 on Shadow. [ ... ] pppd[0]: Galaxy-L!login: pppd[0]: --> Looks like a login prompt. pppd[0]: --> Sending: limbeck pppd[0]: limbeck pppd[0]: Password: pppd[0]: --> Looks like a password prompt. pppd[0]: --> Sending: (password) pppd[0]: Last login: Mon Sep 13 23:36:30 on modem pppd[0]: Have a lot of fun... pppd[0]: limbeck@Galaxy-L:~> pppd[0]: --> Hmm... a prompt. Sending "ppp". pppd[0]: ppp pppd[0]: ~[7f]}#@!}!}!} }9}"}&} } } } }#}%B#}%}%}&[1e]Vko}'}"}(}"71~ pppd[0]: --> PPP negotiation detected. pppd[0]: Serial connection established. pppd[0]: Using interface ppp0 Status is: connecting pppd[0]: Connect: ppp0 <--> /dev/modem pppd[0]: LCP terminated by peer (Authentication failed) pppd[0]: Connection terminated. Status is: disconnected pppd[0] died: PPP negotiation failed (exit code 10)
Du bist schon einen Schritt weiter: Der 'pppd' auf dem Server und auf dem
Laptop wird gestartet; er scheitert aber bei der Authentifizierung.
Überprüfe auf dem Laptop noch einmal Benutzername und Passwort.
Falls das nicht hilft, dann setze auf dem Server "debug" und "dump" in
"/etc/ppp/options" und poste die entsprechenden Zeilen eines
Verbindungsversuches aus "/var/log/messages".
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Dienstag, 14. September 2004 17:12 schrieb Andreas Koenecke:
Du bist schon einen Schritt weiter: Der 'pppd' auf dem Server und auf dem Laptop wird gestartet; er scheitert aber bei der Authentifizierung. Überprüfe auf dem Laptop noch einmal Benutzername und Passwort.
Ja, ich glaube da hatte ich das passwort wohl falsch. Scheint nämlich was
gebracht zu haben....
Jedoch kommt die Kommunikation immer noch nicht in die Gänge.
Hier das Protokoll von kinternet des Laptops:
SuSE Meta pppd (smpppd-ifcfg), Version 1.16 on Shadow.
Status is: disconnected
trying to connect to smpppd
connect to smpppd
Status is: disconnected
Status is: connecting
pppd[0]: Plugin passwordfd.so loaded.
pppd[0]: --> WvDial: Internet dialer version 1.54.0
pppd[0]: --> Initializing modem.
pppd[0]: --> Sending: ATM1
pppd[0]: ATM1
pppd[0]: OK
pppd[0]: --> Modem initialized.
pppd[0]: --> Sending: ATDT0105102247968496
pppd[0]: --> Waiting for carrier.
pppd[0]: ATDT0105102247968496
pppd[0]: CONNECT 28800
pppd[0]: --> Carrier detected. Waiting for prompt.
pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel
pppd[0]: (l).
pppd[0]: Galaxy-L!login:
pppd[0]: Welcome to SuSE Linux 9.1 (i586) - Kernel
pppd[0]: (l).
pppd[0]: Galaxy-L!login:
pppd[0]: --> Looks like a login prompt.
pppd[0]: --> Sending: limbeck
pppd[0]: limbeck
pppd[0]: Password:
pppd[0]: --> Looks like a password prompt.
pppd[0]: --> Sending: (password)
pppd[0]: Last login: Tue Sep 14 22:43:13 from console
pppd[0]: Have a lot of fun...
pppd[0]: limbeck@Galaxy-L:~>
pppd[0]: --> Hmm... a prompt. Sending "ppp".
pppd[0]: ppp
pppd[0]: ~[7f]}#@!}!}!} }9}"}&} } } } }#}%B#}%}%}&G9[0e] }'}"}(}"L[11]~
pppd[0]: --> PPP negotiation detected.
pppd[0]: Serial connection established.
pppd[0]: Using interface ppp0
Status is: connecting
pppd[0]: Connect: ppp0 <--> /dev/modem
pppd[0]: CHAP authentication succeeded: Access granted
pppd[0]: Deflate (15) compression enabled
Und hier das zugehörige /var/log/messages vom Server:
Sep 14 22:53:42 Galaxy-L kernel: CSLIP: code copyright 1989 Regents of the
University of California
Sep 14 22:53:42 Galaxy-L kernel: PPP generic driver version 2.4.2
Sep 14 22:53:42 Galaxy-L pppd[5479]: pppd options in effect:
Sep 14 22:53:42 Galaxy-L pppd[5479]: debug # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: nodetach # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: idle 600 # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: dump # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: active-filter xxx # [don't know how to
print value] # (from /etc/ppp/filters)
Sep 14 22:53:42 Galaxy-L pppd[5479]: auth # (from command line)
Sep 14 22:53:42 Galaxy-L pppd[5479]: refuse-pap # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: lock # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: crtscts # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: modem # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: asyncmap 0 # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: passive # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: lcp-echo-failure 4 #
(from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: lcp-echo-interval 30 #
(from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: lcp-restart 2 # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: lcp-max-configure 60 #
(from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: noipdefault # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: ms-dns xxx # [don't know how to print
value] # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: proxyarp # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: 192.168.0.251:192.168.0.250 #
(from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: noipx # (from /etc/ppp/options)
Sep 14 22:53:42 Galaxy-L pppd[5479]: pppd 2.4.2 started by limbeck, uid 1000
Sep 14 22:53:42 Galaxy-L pppd[5479]: using channel 1
Sep 14 22:53:42 Galaxy-L pppd[5479]: Using interface ppp0
Sep 14 22:53:42 Galaxy-L pppd[5479]: Connect: ppp0 <--> /dev/modem
Sep 14 22:53:42 Galaxy-L pppd[5479]: sent [LCP ConfReq id=0x1
* Dienstag, 14. September 2004 um 23:17 (+0200) schrieb Gerd Limbeck:
Und hier das zugehörige /var/log/messages vom Server:
[ ... ]
Sep 14 22:53:45 Galaxy-L pppd[5479]: sent [CHAP Success id=0x3d "Access granted"]
So weit, so gut...
[ ... ]
Sep 14 22:53:45 Galaxy-L pppd[5479]: sent [IPCP ConfReq id=0x2
] Sep 14 22:53:45 Galaxy-L pppd[5479]: rcvd [IPCP ConfReq id=0x2 ] Sep 14 22:53:45 Galaxy-L pppd[5479]: sent [IPCP ConfNak id=0x2 ] Sep 14 22:53:45 Galaxy-L pppd[5479]: rcvd [IPCP ConfNak id=0x2 ] Sep 14 22:53:45 Galaxy-L pppd[5479]: sent [IPCP ConfReq id=0x3 ] Sep 14 22:53:45 Galaxy-L pppd[5479]: rcvd [IPCP ConfReq id=0x3 ] [ u.s.w., u.s.w. ...]
Alles, was an das Laptop gesendet wird, kommt anscheinend als Echo zurück...
Die Frage ist, wo das Echo erzeugt wird: Lokal auf dem Server oder "äfft" das
Laptop den Server nach?
Ich würde erst einmal auf dem Server "nobsdcomp" und "nodeflate" setzen, um
Störungen durch die Kompression auszuschliessen. Hilft das nicht, dann setze
doch auch auf dem Laptop noch die 'pppd'-Optionen "debug" und "dump" und poste
die Meldungen beider Rechner.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Mittwoch, 15. September 2004 18:33 schrieb Andreas Koenecke:
Ich würde erst einmal auf dem Server "nobsdcomp" und "nodeflate" setzen, um Störungen durch die Kompression auszuschliessen. Hilft das nicht, dann setze doch auch auf dem Laptop noch die 'pppd'-Optionen "debug" und "dump" und poste die Meldungen beider Rechner.
Habe ich gemacht. Keine Veränderung.
Also hier zunächst die Meldungen auf dem Laptop (die Uhrzeit von Laptop und Server unterscheiden sich etwa fünf Minuten):
Sep 15 21:49:13 Shadow pppd[4897]: Plugin passwordxxxxx loaded.
Sep 15 21:49:13 Shadow kernel: CSLIP: code copyright 1989 Regents of the University of California
Sep 15 21:49:13 Shadow kernel: PPP generic driver version 2.4.2
Sep 15 21:49:13 Shadow pppd[4897]: pppd options in effect:
Sep 15 21:49:13 Shadow pppd[4897]: debug # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: nodetach # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: idle 300 # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: logfd 8 # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: dump # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: plugin passwordxxxxx # (from /etc/ppp/peers/ppp)
Sep 15 21:49:13 Shadow pppd[4897]: active-filter xxx # [don't know how to print value] # (from /etc/ppp/filters)
Sep 15 21:49:13 Shadow pppd[4897]: noauth # (from /etc/ppp/peers/ppp)
Sep 15 21:49:13 Shadow pppd[4897]: user limbeck # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: passwordxxxxx # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: /dev/modem # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: 115200 # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: lock # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: connect /usr/bin/wvdial --chat --no-syslog --config /var/run/smpppd/wvdial-ppp0.conf smpppd # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: crtscts # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: modem # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: asyncmap 0 # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: lcp-echo-failure 4 # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: lcp-echo-interval 30 # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: lcp-restart 2 # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: lcp-max-configure 60 # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: ipparam 'ifcfg-ppp0' 'provider0' # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: noipdefault # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: usepeerdns # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: 192.168.0.251:192.168.0.250 # (from command line)
Sep 15 21:49:13 Shadow pppd[4897]: noipx # (from /etc/ppp/options)
Sep 15 21:49:13 Shadow pppd[4897]: pppd 2.4.2 started by root, uid 0
Sep 15 21:49:14 Shadow wvdial[4915]: WvDial: Internet dialer version 1.54.0
Sep 15 21:49:14 Shadow wvdial[4915]: Initializing modem.
Sep 15 21:49:14 Shadow wvdial[4915]: Sending: ATM1
Sep 15 21:49:15 Shadow wvdial[4915]: ATM1
Sep 15 21:49:15 Shadow wvdial[4915]: OK
Sep 15 21:49:15 Shadow wvdial[4915]: Modem initialized.
Sep 15 21:49:15 Shadow wvdial[4915]: Sending: ATDTxxx
Sep 15 21:49:15 Shadow wvdial[4915]: Waiting for carrier.
Sep 15 21:49:15 Shadow wvdial[4915]: ATDTxxx
Sep 15 21:49:40 Shadow wvdial[4915]: CONNECT 28800
Sep 15 21:49:40 Shadow wvdial[4915]: Carrier detected. Waiting for prompt.
Sep 15 21:49:41 Shadow wvdial[4915]: Welcome to SuSE Linux 9.1 (i586) - Kernel
Sep 15 21:49:41 Shadow wvdial[4915]: (l).
Sep 15 21:49:41 Shadow wvdial[4915]: Galaxy-L!login:
Sep 15 21:49:41 Shadow wvdial[4915]: Welcome to SuSE Linux 9.1 (i586) - Kernel
Sep 15 21:49:41 Shadow wvdial[4915]: (l).
Sep 15 21:49:41 Shadow wvdial[4915]: Galaxy-L!login:
Sep 15 21:49:41 Shadow wvdial[4915]: Looks like a login prompt.
Sep 15 21:49:41 Shadow wvdial[4915]: Sending: limbeck
Sep 15 21:49:41 Shadow wvdial[4915]: limbeck
Sep 15 21:49:41 Shadow wvdial[4915]: Password:
Sep 15 21:49:41 Shadow wvdial[4915]: Looks like a password prompt.
Sep 15 21:49:41 Shadow wvdial[4915]: Sending: (password)
Sep 15 21:49:42 Shadow wvdial[4915]: Last login: Wed Sep 15 21:40:40 from console
Sep 15 21:49:42 Shadow wvdial[4915]: Have a lot of fun...
Sep 15 21:49:43 Shadow wvdial[4915]: limbeck@Galaxy-L:~>
Sep 15 21:49:43 Shadow wvdial[4915]: Hmm... a prompt. Sending "ppp".
Sep 15 21:49:43 Shadow wvdial[4915]: ppp
Sep 15 21:49:43 Shadow wvdial[4915]: ~[7f]}#@!}!}!} }9}"}&} } } } }#}%B#}%}%}&F}2S>}'}"}(}"IV~
Sep 15 21:49:43 Shadow wvdial[4915]: PPP negotiation detected.
Sep 15 21:49:43 Shadow pppd[4897]: Serial connection established.
Sep 15 21:49:44 Shadow pppd[4897]: using channel 1
Sep 15 21:49:44 Shadow pppd[4897]: Using interface ppp0
Sep 15 21:49:44 Shadow pppd[4897]: Connect: ppp0 <--> /dev/modem
Sep 15 21:49:45 Shadow pppd[4897]: sent [LCP ConfReq id=0x1
* Mittwoch, 15. September 2004 um 22:26 (+0200) schrieb Gerd Limbeck:
Also hier zunächst die Meldungen auf dem Laptop (die Uhrzeit von Laptop und Server unterscheiden sich etwa fünf Minuten):
[ ... ]
Sep 15 21:49:13 Shadow pppd[4897]: 192.168.0.251:192.168.0.250 # (from command line)
Das muss weg. Es sollte nur einer der beiden Rechner die IPs vorschlagen, und zwar IMHO in deinem Fall der Server. Auf gar keinen Fall darf obige Zeile in beiden Konfigurationen stehen.
Und nun die dazu passenden Meldungen des Servers:
[ ... ] Sep 15 21:54:55 Galaxy-L pppd[4968]: 192.168.0.251:192.168.0.250 # (from /etc/ppp/options) [ ... ]
Jetzt bin ich ja doch mal gespannt...
Ich auch...
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Sep 15 21:49:13 Shadow pppd[4897]: 192.168.0.251:192.168.0.250 # (from command line)
Das muss weg.
Ja!!!!!!!!!! Jetzt kommen wir der Sache näher. Danke schon mal! Habe ne Verbindung:
ppp0 Protokoll:Punkt-zu-Punkt Verbindung
inet Adresse:192.168.0.250 P-z-P:192.168.0.251 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:3
RX bytes:89 (89.0 b) TX bytes:95 (95.0 b)
Doch irgentwie komm ich vom Laptop nicht weiter als 192.168.0.251, was eigentlich bei der angezeigten
Maske:255.255.255.255 nicht verwunderlich sein sollte (falls ich das richtig verstanden habe). Ein Ping
zum DSL-Router 192.168.0.1 klappt nicht.
Doch ein Test mit Arcor jedoch läßt mich mit meiner Masken-Theorie zweifeln:
ppp0 Protokoll:Punkt-zu-Punkt Verbindung
inet Adresse:212.144.32.49 P-z-P:145.253.1.42 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:37 errors:0 dropped:0 overruns:0 frame:0
TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:3
RX bytes:6962 (6.7 Kb) TX bytes:2728 (2.6 Kb)
Auch hier ne Maske:255.255.255.255, aber sofort ping an www.google.de möglich und daher natürlich auch http.
Bei einem Vergleich der Einwahlvorgänge habe ich nichts gefunden. Hier der von der Laptop-Verbindung
zu meinen Server:
SuSE Meta pppd (smpppd-ifcfg), Version 1.16 on Shadow.
Status is: disconnected
trying to connect to smpppd
connect to smpppd
Status is: disconnected
Status is: connecting
pppd[0]: Plugin passwordfd.so loaded.
pppd[0]: pppd options in effect:
pppd[0]: debug # (from /etc/ppp/options)
pppd[0]: nodetach # (from command line)
pppd[0]: idle 300 # (from command line)
pppd[0]: logfd 8 # (from command line)
pppd[0]: dump # (from /etc/ppp/options)
pppd[0]: plugin passwordfd.so # (from /etc/ppp/peers/ppp)
pppd[0]: active-filter xxx # [don't know how to print value] # (from /etc/ppp/filters)
pppd[0]: noauth # (from /etc/ppp/peers/ppp)
pppd[0]: user limbeck # (from command line)
pppd[0]: passwordfd 9 # (from command line)
pppd[0]: /dev/modem # (from command line)
pppd[0]: 115200 # (from command line)
pppd[0]: lock # (from /etc/ppp/options)
pppd[0]: connect /usr/bin/wvdial --chat --no-syslog --config /var/run/smpppd/wvdial-ppp0.conf smpppd # (from command line)
pppd[0]: crtscts # (from /etc/ppp/options)
pppd[0]: modem # (from /etc/ppp/options)
pppd[0]: asyncmap 0 # (from /etc/ppp/options)
pppd[0]: lcp-echo-failure 4 # (from /etc/ppp/options)
pppd[0]: lcp-echo-interval 30 # (from /etc/ppp/options)
pppd[0]: lcp-restart 2 # (from /etc/ppp/options)
pppd[0]: lcp-max-configure 60 # (from /etc/ppp/options)
pppd[0]: ipcp-accept-local # (from command line)
pppd[0]: ipcp-accept-remote # (from command line)
pppd[0]: ipparam 'ifcfg-ppp0' 'provider1' # (from command line)
pppd[0]: noipdefault # (from /etc/ppp/options)
pppd[0]: defaultroute # (from command line)
pppd[0]: replacedefaultroute # (from command line)
pppd[0]: usepeerdns # (from command line)
pppd[0]: noipx # (from /etc/ppp/options)
pppd[0]: --> WvDial: Internet dialer version 1.54.0
pppd[0]: --> Initializing modem.
pppd[0]: --> Sending: ATM1
pppd[0]: ATM1
pppd[0]: OK
pppd[0]: --> Modem initialized.
pppd[0]: --> Sending: ATDT0105102247968496
pppd[0]: --> Waiting for carrier.
pppd[0]: ATDT0105102247968496
pppd[0]: CONNECT 12000
pppd[0]: --> Carrier detected. Chatmode finished.
pppd[0]: Serial connection established.
pppd[0]: using channel 16
pppd[0]: Using interface ppp0
Status is: connecting
pppd[0]: Connect: ppp0 <--> /dev/modem
pppd[0]: sent [LCP ConfReq id=0x1
Hallo Gerd, hallo Leute, Am Donnerstag, 16. September 2004 23:43 schrieb Gerd Limbeck:
Ja!!!!!!!!!! Jetzt kommen wir der Sache näher. Danke schon mal! Habe ne Verbindung:
ppp0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:192.168.0.250 P-z-P:192.168.0.251 Maske:255.255.255.255 UP PUNKTZUPUNKT RUNNING NOARP MULTICAST
pppd[0]: local IP address 192.168.0.250 pppd[0]: remote IP address 192.168.0.251
Doch irgentwie komm ich vom Laptop nicht weiter als 192.168.0.251,
Du hast vermutlich auf dem Server (192.168.0.251) das Forwarding ("Routing") nicht aktiviert. Aktiviere in /etc/sysconfig/SuSEfirewall2 FW_ROUTE, eine Lektüre des zugehörigen Kommentars kann nicht schaden.
was eigentlich bei der angezeigten Maske:255.255.255.255 nicht verwunderlich sein sollte (falls ich das richtig verstanden habe).
Die Netmask ist erstmal unwichtig, da ja laut Log auch die default route gesetzt wird:
pppd[0]: replacing old default route to eth0 [192.168.0.1]
Und dadurch gehen alle Pakete, die keinen speziellen Eintrag in der Routingtabelle (/sbin/route -n) haben, grundsätzlich über die ppp-Verbindung. Gruß Christian Boltz -- Das Wort "WINDOWS" stammt aus einem alten Sioux-Dialekt und bedeutet: "Weißer Mann starrt durch Glasscheibe auf Sanduhr."(gefunden in d.c.t)
* Donnerstag, 16. September 2004 um 23:43 (+0200) schrieb Gerd Limbeck:
Ja!!!!!!!!!! Jetzt kommen wir der Sache näher. Danke schon mal! Habe ne Verbindung:
ppp0 Protokoll:Punkt-zu-Punkt Verbindung inet Adresse:192.168.0.250 P-z-P:192.168.0.251 Maske:255.255.255.255 UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:3 RX bytes:89 (89.0 b) TX bytes:95 (95.0 b)
Doch irgentwie komm ich vom Laptop nicht weiter als 192.168.0.251, was eigentlich bei der angezeigten Maske:255.255.255.255 nicht verwunderlich sein sollte (falls ich das richtig verstanden habe).
Ja, deshalb heisst es auch "Punkt-zu-Punkt Verbindung".
Ein Ping zum DSL-Router 192.168.0.1 klappt nicht.
Die "proxyarp"-Option allein reicht nicht, es muss (wie von Christian Boltz
bereits erwähnt) zusatzlich noch "IP-Forwarding" im Kernel aktiviert sein.
Als Alternative zu Christians Vorschlag, die SuSE-Firewall einzusetzen, kannst
du auch auf dem Server in der 'pppd'-Konfiguration noch die Option "ktune"
hinzufügen. Dann schaltet der 'pppd' das IP-Forwarding ein.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Hallo Andreas, tja, irgendwie klappts immer noch nicht ganz. Die Firewall ist nicht aktiv (laut yast) und in /etc/ppp/options auf dem Server habe 'ktune' hinzugefügt. Leider nix Ping zum DSL-Router. :-| Gruß Gerd
Hmm, ich denke auch eher, daß es an den Einstellungen am Client, also Laptop, liegen muß. Denn wie im Betreff geschrieben und gerade auch nochmal getestet: Windoof-Einwahl klappt (ping zum DSL-Router, somit auch z.B. ping www.heise.de). Gruß Gerd.
* Samstag, 18. September 2004 um 22:41 (+0200) schrieb Gerd Limbeck:
Hmm, ich denke auch eher, daß es an den Einstellungen am Client, also Laptop, liegen muß. Denn wie im Betreff geschrieben und gerade auch nochmal getestet: Windoof-Einwahl klappt (ping zum DSL-Router, somit auch z.B. ping www.heise.de).
Welche Meldung gibt denn ein 'ping -c 2 192.168.0.1' aus?
Welche Meldung 'route -n'? (Alles auf dem Laptop.)
Die SuSE-FW kannst du mit 'iptables -L -nv' überprüfen.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Am Samstag, 18. September 2004 23:43 schrieb Andreas Koenecke:
Welche Meldung gibt denn ein 'ping -c 2 192.168.0.1' aus?
Während der Modem-Verbindung: Shadow:/home/limbeck # ping -c 2 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. From 192.168.0.51: icmp_seq=1 Destination Host Unreachable From 192.168.0.51 icmp_seq=1 Destination Host Unreachable From 192.168.0.51 icmp_seq=2 Destination Host Unreachable --- 192.168.0.1 ping statistics --- 2 packets transmitted, 0 received, +3 errors, 100% packet loss, time 999ms , pipe 2 Ohne Modem-Verbindung: Shadow:/home/limbeck # ping -c 2 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. From 192.168.0.51: icmp_seq=1 Destination Host Unreachable From 192.168.0.51 icmp_seq=1 Destination Host Unreachable From 192.168.0.51 icmp_seq=2 Destination Host Unreachable --- 192.168.0.1 ping statistics --- 2 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1000ms , pipe 2 Shadow:/home/limbeck # Ein Millisekunde Unterschied. Nicht viel, was? ;-)
Welche Meldung 'route -n'? (Alles auf dem Laptop.)
Während der Modem-Verbindung: Shadow:/home/limbeck # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.251 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.251 0.0.0.0 UG 0 0 0 ppp0 Ohne Modem-Verbindung: Shadow:/home/limbeck # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Die SuSE-FW kannst du mit 'iptables -L -nv' überprüfen.
Galaxy-L:/home/limbeck # iptables -L -nv Chain INPUT (policy ACCEPT 465 packets, 46670 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 1981 packets, 737K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 389 packets, 24469 bytes) pkts bytes target prot opt in out source destination Gruß Gerd
* Sonntag, 19. September 2004 um 15:34 (+0200) schrieb Gerd Limbeck:
Welche Meldung 'route -n'? (Alles auf dem Laptop.)
Während der Modem-Verbindung:
Shadow:/home/limbeck # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface [ ... ] 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Da ist ja auch schon der Übeltäter...
Obige Zeile muss raus.
Am elegantesten durch einen entsprechenden Eintrag in "/etc/ppp/ip-up.local"
(und in "/etc/ppp/ip-down.local" kann die Route nach der Modem-Verbindung
wieder gesetzt werden...) oder am einfachsten durch ein manuelles 'ifconfig
eth0 down' für den Zeitraum der Modem-Verbindung.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
Oh Ha, ich glaube ich hab's jetzt. 'ifconfig eth0 down' brachte den Erfolg. Wobei ich dann doch noch mit den *.local-files gekämpft habe: Nachdem ich sie dann ausführbar ('chmod u+x /etc/ppp/ip-down.local' und 'chmod u+x /etc/ppp/ip-up.local') gemacht habe und ich den kompletten Pfad, also '/sbin/ifconfig eth0 up' bzw. '/sbin/ifconfig eth0 down' (also mit sbin!), angegeben habe, kann ich mich nun endlich ohne Probleme einwählen. Nochmals Danke. Gruß Gerd
participants (3)
-
Andreas Koenecke -
Christian Boltz -
Gerd Limbeck