pppd mehre Fehler, Verbindung bricht häufig ab.
Hi, das es für das Creatix V.90 HaM internal endlich die Treiber gibt hab ich mir diese auch gleich installiert. Funktioniert soweit so gut. Nur mußte ich irgendwie feststellen das mir die Verbindung zu T-Offline häufiger abbricht als unter Windows. Außerdem, was mich noch viel mehr stört, ist das ich jedes mal wenn ich den Rechner neu gebooted habe die Device neu anlegen muß, sonst erscheint lediglich der Feler in kppp Sorry, Modem besetzt. Beim starten von Kppp erscheint dann auch noch der Fehler, No PPP support installiert nicht im Kernel und auch nicht als Modul. Lege ich dann die Devices /dev/ttyS15 /dev/modem /dev/ham neu an, erscheint keine Fehlermeldung mehr und ich kann mich ordungsgemäß einwählen. Nur bricht halt häufiger die Verbindung mit pppd died unexpectly ab. Das letzte Mal stand in /var/log/messages das auf 4 echo kein reply eingegangen ist und deswegen irgendwie der PPPD runtergefahren wurde, frage kann man diesen Wert erhöhen? Sodas er vielleicht versucht 6 oder 8 Mal ein echo zu bekommen. Die letzte Fehlermeldung sieht übrigens so aus: Beginn /var/log/messages . . . Mar 1 15:31:53 bootsy pppd[6134]: Terminating connection due to lack of activity. Mar 1 15:31:53 bootsy pppd[6134]: Script /etc/ppp/ip-down started (pid 6338) Mar 1 15:31:53 bootsy pppd[6134]: sent [LCP TermReq id=0x2 "Link inactive"] Mar 1 15:31:53 bootsy pppd[6134]: Script /etc/ppp/ip-down finished (pid 6338), status = 0x0 Mar 1 15:31:56 bootsy pppd[6134]: sent [LCP TermReq id=0x3 "Link inactive"] Mar 1 15:31:59 bootsy pppd[6134]: Connection terminated. Mar 1 15:31:59 bootsy pppd[6134]: Connect time 16.6 minutes. Mar 1 15:31:59 bootsy pppd[6134]: Sent 10366 bytes, received 49181 bytes. Mar 1 15:31:59 bootsy kernel: ham:close: for: pppd [6134] Mar 1 15:31:59 bootsy kernel: ham:rs_close: count now = 1 Mar 1 15:31:59 bootsy pppd[6134]: Exit. Mar 1 15:31:59 bootsy kernel: ham:close: for: pppd [6134] Mar 1 15:31:59 bootsy kernel: ham:rs_close: count now = 0 Mar 1 15:31:59 bootsy kernel: ham:ResetDspInternal Mar 1 15:31:59 bootsy kernel: ham:WaitForDspReady... Mar 1 15:31:59 bootsy kernel: done . . . End /var/log/messages
Am Donnerstag, 1. März 2001 16:09 schrieb Carsten Menke:
das es für das Creatix V.90 HaM internal endlich die Treiber gibt hab ich mir diese auch gleich installiert. Funktioniert soweit so gut. Nur mußte ich irgendwie feststellen das mir die Verbindung zu T-Offline häufiger abbricht als unter Windows.
Das kann ich mir vorstellen. Meine Meinung zu solchen Winmodems ist: Schrott! Wenn die Arbeiten schon von einem Hauptprozessor vorgenommen werden müssen, dann kann es ja nur recht anfällig werden. Da es sich um einen neuen Treiber handelt, sind da sicherlich noch einige Probleme.
Nur bricht halt häufiger die Verbindung mit pppd died unexpectly ab. Das letzte Mal stand in /var/log/messages das auf 4 echo kein reply eingegangen ist und deswegen irgendwie der PPPD runtergefahren wurde, frage kann man diesen Wert erhöhen? Sodas er vielleicht versucht 6 oder 8 Mal ein echo zu bekommen.
Du meinst sicherlich die EchoReq und EchoRep. Aus der Manpage zum pppd: lcp-echo-failure n If this option is given, pppd will presume the peer to be dead if n LCP echo-requests are sent without receiving a valid LCP echo-reply. If this happens, pppd will terminate the connection. Use of this option requires a non-zero value for the lcp-echo- interval parameter. This option can be used to enable pppd to terminate after the physical connec tion has been broken (e.g., the modem has hung up) in situations where no hardware modem control lines are available. lcp-echo-interval n If this option is given, pppd will send an LCP echo-request frame to the peer every n seconds. Normally the peer should respond to the echo- request by sending an echo-reply. This option can be used with the lcp-echo-failure option to detect that the peer is no longer connected. Also solltest Du einfach mal diese Option dem pppd mit entsprechenden Werten ausgestattet mitteilen. Die Parameter und Optionen des pppd stehen in der Datei /etc/ppp/options.
Mar 1 15:31:53 bootsy pppd[6134]: Terminating connection due to lack of activity.
Da steht es doch schon im besten Englisch: Die Verbindung wurde aufgrund von Inaktivität beendet. Sprich, es gab keinen Traffic mehr und nach einem TimeOut, wird dann die Verbindung unterbrochen. D.h. die o.g. Parameter werden Dir nix bringen. Bis denn dann... Torsten
Torsten Hallmann wrote:
Am Donnerstag, 1. März 2001 16:09 schrieb Carsten Menke:
Mar 1 15:31:53 bootsy pppd[6134]: Terminating connection due to lack of activity.
Da steht es doch schon im besten Englisch: Die Verbindung wurde aufgrund von Inaktivität beendet. Sprich, es gab keinen Traffic mehr und nach einem TimeOut, wird dann die Verbindung unterbrochen.
D.h. die o.g. Parameter werden Dir nix bringen.
Bis denn dann...
Torsten
Danke :-) Genau das habe ich gesucht Und jetzt wo du es sagst, fällt mir auch wieder ein das ich unter windows noch ein Tool laufen habe das alle 15 Minuten ein TimeSync Request macht. Da ich das unter Linux nicht habe ist mir schon klar warum dann die Verbindung teilweise so abbricht. Ich denke das TimeOut wird von T-Offline vorgeben, richtig? Jetzt würde mich doch nur noch interessieren, wie bekomme ich es hin das ich nicht jedes Mal wenn ich mich auslogge bzw. den Rechner herunterfahre und dann beim erneuten hochfahren (einloggen), die Devices neu anlegen muß um auf das Modem erneut zuzugreifen (also rm /dev/modem /dev/ham /dev/ttyS15) und dann mknod /dev/ham c 240 1 ln -s /dev/ham /dev/modem ln -s /dev/ham /dev/ttyS15 chgrp uucp /dev/ham chmod 666 /dev/ham Ansonsten bekomme ich immer die Meldung das das Modem besetzt sei, was ja definitiv nicht stimmt. Hat man dann die Devices neu angelegt meckert Kppp noch einmal herum das kein PPPD in den Kernel einkompiliert ist, und auch nicht als Modul verfügbar ist und danach wählt sich Kppp wunderbar ein. Any ideas? Gruß Carsten
Am Sonntag, 4. März 2001 14:49 schrieb Carsten Menke:
Da ich das unter Linux nicht habe ist mir schon klar warum dann die Verbindung teilweise so abbricht. Ich denke das TimeOut wird von T-Offline vorgeben, richtig?
Kann sein, kann aber auch nicht sein. Ich habe jetzt nicht mehr im Kopf, wie Du genau die Einwahl vornimmst. Solltest Du wvdial verwenden, dann einfach die Idle-Time in dem Menüpunkt -> Konfigurieren Sie Ihren Provider -> Expertenmenü des Programms wvdial.lxdialog
Jetzt würde mich doch nur noch interessieren, wie bekomme ich es hin das ich nicht jedes Mal wenn ich mich auslogge bzw. den Rechner herunterfahre und dann beim erneuten hochfahren (einloggen), die Devices neu anlegen muß um auf das Modem erneut zuzugreifen (also rm /dev/modem /dev/ham /dev/ttyS15) und dann
Da sollte die Frage beantwortet werden, warum es nach dem ausloggen bzw. shutdown nicht mehr funktioniert. Fehlen angelegte Devices, sind Rechte verändert worden usw.
Ansonsten bekomme ich immer die Meldung das das Modem besetzt sei, was ja definitiv nicht stimmt.
Einige Einwahlprogramme melden das wenn Sie von dem Modem keine Recktion erhalten!
Hat man dann die Devices neu angelegt meckert Kppp noch einmal herum das kein PPPD in den Kernel einkompiliert ist, und auch nicht als Modul verfügbar ist und danach wählt sich Kppp wunderbar ein.
Daraus schließe ich messerscharf, das Du das kppp aus der SuSE 7.0 verwendest. Diese erste Fehlermeldung ist ein Bug. Bis denn dann... Torsten
Torsten Hallmann wrote:
Am Sonntag, 4. März 2001 14:49 schrieb Carsten Menke:
Da ich das unter Linux nicht habe ist mir schon klar warum dann die Verbindung teilweise so abbricht. Ich denke das TimeOut wird von T-Offline vorgeben, richtig?
Kann sein, kann aber auch nicht sein. Ich habe jetzt nicht mehr im Kopf, wie Du genau die Einwahl vornimmst. Solltest Du wvdial verwenden, dann einfach die Idle-Time in dem Menüpunkt
Das habe ich mittlerweile gelöst, den in /etc/ppp/options habe ich auch dazu ein Eintrag gefunden, hab ich die Werte etwas höher gesetzt und (auch für das Echo Reply) seitdem kann ich nicht mehr klagen. Die Verbindung ist stabil bricht nicht mehr ab und das schönste Rattenschnell. :-)
Da sollte die Frage beantwortet werden, warum es nach dem ausloggen bzw. shutdown nicht mehr funktioniert. Fehlen angelegte Devices, sind Rechte verändert worden usw.
Das ist genau der Punkt, ich vermute natürlich das die Rechte irgendwie verändert werden, nur das Problem ist ja schließlich von wem, (Ok naheliegend ist das die Rechte von PPPD verändert werden)bleibt nur noch die Frage, wie kann man das unterbinden. Ich habe in der SDB gelesen das das daher kommen kann wenn der PPP nicht richtig beendet worden ist und deshalb die Rechte nicht wieder zurück gesetzt werden. Derzeit habe ich das Problem gelöst indem ich in der /sbin/init.d/boot.local den Eintrag chgrp dialout /dev/ham vorgenommen habe. Nur das kann ja nicht das Ultimo sein, das ist ja ne Quick&Dirty Lösung und bestimmt nicht im Sinne des Erfinders. Beim Logout ist das Problem übrigens behoben (d.h. man muß danach nicht mehr die Devices neu anlegen)
danach wählt sich Kppp wunderbar ein.
Daraus schließe ich messerscharf, das Du das kppp aus der SuSE 7.0 verwendest. Diese erste Fehlermeldung ist ein Bug.
Könntest echt Hellseher werden, unglaublich scharf getroffen. Eigentlich ja nicht nötig das zu beheben, aber wer Perfektionist ist... Gibt es da eine Möglichkeit? Update des Kppp? Gruß Carsten
participants (2)
-
Carsten Menke
-
Torsten Hallmann