On Thu, Mar 22, 2001 at 06:44:06PM +0100, Konrad Stopsack wrote:
Hallo Leute,
seitdem ich von KDE 2.0.0 auf 2.1.0 upgedatet habe, läuft das Kppp nicht mehr richtig. Der PPPd wird gestartet, versucht immer wieder dasselbe zu senden, was natürlich nicht klappt. Kppp kann auch nie das PPP-Log lesen ("Cannot open logfile"), obwohl es die debug-Option gesetzt hat (nach Nachfrage, Kppp will die unbedingt, damit das syslog mit binärem Mist vollgemüllt wird)
KDE: 2.1.0 Kernel: 2.4.2 PPPd: 2.4.0 Distri: SuSE 6.4
Meldungen:
Also ich hab ja schon mehrmals die Verhandlungen zwischen meinem Rechner und dem ISP durchlesen müssen wegen ppp-Problemen, aber sowas hab ich bis jetzt noch nicht gesehen. Das Problem scheint hier auf Providerseite zu liegen. Kannst dir die Stellen ja nochmal anschauen, aber im Prinzip hast du sicher auch gemerkt, daß immer wieder dasselbe passiert: - Der Providerhost sendet einen Config Request - Dein Host sendet einen Config Reject mit der Angabe, daß ihm pap-Authentification nicht gefällt
Das wiederholt sich dann immer wieder. Üblicherweise müßte es jetzt aber weitergehen: - Der Providerhost sendet einen neuen ConfReq, der die von deinem Rechner abgelehnten Optionen brücksichtigt - Dein Rechner sendet ein ConfAck
Das sieht dann bei mir z.B. so aus (normalerweise immer ein bißchen zerstreut über das Logfile:
Mar 22 22:17:41 potato ipppd[162]: rcvd [0][LCP ConfReq id=0xf9 <auth chap md5> <magic 0xd8540264> <MPmrru 0x5f4> <MPdiscr: 0x1 [ 62 75 6e 64 6c 65 ]>] Mar 22 22:17:41 potato ipppd[162]: sent [0][LCP ConfRej id=0xf9 <MPmrru 0x5f4>] Mar 22 22:17:41 potato ipppd[162]: rcvd [0][LCP ConfReq id=0xfa <auth chap md5> <magic 0xd8540264> <MPdiscr: 0x1 [ 62 75 6e 64 6c 65 ]>] Mar 22 22:17:41 potato ipppd[162]: sent [0][LCP ConfAck id=0xfa <auth chap md5> <magic 0xd8540264> <MPdiscr: 0x1 [ 62 75 6e 64 6c 65 ]>]
Das zweite Auffällige ist die Tatsache, daß dein Rechner unter derselben id (!!!, riecht nach einem bug) immer wieder seine ConfReqs aussendet (die auch vom ISP positiv beantwortet werden). Das _könnte_ evtl. am ersten Problem liegen, daß der pppd hier Mutmaßungen anstellt. Ansonsten: hast du irgendwas am Configfile geändert? Eine neue pppd-Version genommen?
An kppp wirds kaum liegen, da das nur ein Frontend für den pppd ist.
Lösung: am besten mal bei deinem ISP anrufen oder einen neuen nehmen. Die Sturheit des Hosts könnte evtl. auch daran liegen, daß der ISP nur PAP untertützt, aber ich glaub, dann würde er einen TermReq senden, wenn eine bestimmte Anzahl von Verhandlungsversuchen fehlgeschlaen ist.
Mar 19 16:16:40 Stopsack pppd[381]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3a6452c6> <pcomp> <accomp>] Mar 19 16:16:41 Stopsack pppd[381]: rcvd [LCP ConfReq id=0x1 <mru 1514> <asyncmap 0x0> <auth pap> <magic 0x1ba1a096>] Mar 19 16:16:41 Stopsack pppd[381]: sent [LCP ConfRej id=0x1 <auth pap>] Mar 19 16:16:41 Stopsack pppd[381]: rcvd [LCP ConfRej id=0x1 <pcomp>] Mar 19 16:16:41 Stopsack pppd[381]: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x3a6452c6> <accomp>] Mar 19 16:16:41 Stopsack pppd[381]: rcvd [LCP ConfRej id=0x2 <accomp>] Mar 19 16:16:41 Stopsack pppd[381]: sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x3a6452c6>]
Dein Rechner hat hier den Bogen mit dem "richtigen" ConfReq raus...
Mar 19 16:16:41 Stopsack pppd[381]: rcvd [LCP ConfAck id=0x3 <asyncmap 0x0> <magic 0x3a6452c6>] Mar 19 16:16:44 Stopsack pppd[381]: sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x3a6452c6>] Mar 19 16:16:44 Stopsack pppd[381]: rcvd [LCP ConfReq id=0x2 <mru 1514> <asyncmap 0x0> <auth pap> <magic 0x1ba1a096>] Mar 19 16:16:44 Stopsack pppd[381]: sent [LCP ConfRej id=0x2 <auth pap>]
...aber der andere Host nicht.
Woran kann das liegen?
cu Konrad
cu, Ulf