vielleicht kann mir ja hier jemand helfen. Ich habe das
Problem, das mein ISDN-Zugang über Linux (Fritzcard PCI/Kernel
2.4.2/T-Offline) sporadisch nicht funktioniert. Dieses nicht
funktionieren kann ich nur so beschreiben, dass es teilweise
bis zu 2 Minuten dauert, bis sich der Rechner ins Internet
eingewählt hat. Eine Absenkung von MTU und MRU haben keinen
Erfolg gebracht. Momentan laufen die beiden o.g. Werte wieder
im vorgegebenen Bereich (1500/1524). Wäre nett, wenn sich mal
jemand von Euch meinen Logbuchauszug ansehen könnte. Es
erscheint immer ein „timout sending config request“. Weiß
jemand, woran das eventuell liegen könnte?
May 22 10:56:46 schneemann2 kernel: ippp0: dialing 1 0191011…
May 22 10:56:46 schneemann2 isdnlog: May 22 10:56:46 * tei 86
calling T-ONLINE-FMay 22 10:56:46 schneemann2 isdnlog: May 22
10:56:46 tei 86 calling T-ONLINE-FLAMay 22 10:56:46 schneemann2
isdnlog: May 22 10:56:46 tei 86 calling T-ONLINE-FLAMay 22
10:56:46 schneemann2 isdnlog: May 22 10:56:46 tei 86 calling
T-ONLINE-FLAMay 22 10:56:46 schneemann2 isdnlog: May 22
10:56:46 tei 86 calling T-ONLINE-FLAMay 22 10:56:46 schneemann2
isdnlog: May 22 10:56:46 tei 86 calling T-ONLINE-FLAMay 22
10:56:47 schneemann2 ipppd[7812]: Local number: xxxxx, Remote
number: 01May 22 10:56:47 schneemann2 ipppd[7812]: PHASE_WAIT
-> PHASE_ESTABLISHED, ifunitMay 22 10:56:47 schneemann2
ipppd[7812]: sent [0][LCP ConfReq id=0x1
May 22 10:56:47 schneemann2 kernel: isdn_net: ippp0 connected
May 22 10:56:50 schneemann2 ipppd[7812]: sent [0][LCP ConfReq
id=0x1
May 22 10:57:14 schneemann2 last message repeated 8 times
May 22 10:57:17 schneemann2 ipppd[7812]: LCP: timeout sending
Config-Requests
May 22 10:57:17 schneemann2 ipppd[7812]: Connection terminated.
May 22 10:57:17 schneemann2 ipppd[7812]: taking down PHASE_DEAD
link 0, linkunitMay 22 10:57:17 schneemann2 ipppd[7812]: LCP is
down
May 22 10:57:17 schneemann2 ipppd[7812]: closing fd 8 from unit
0
May 22 10:57:17 schneemann2 ipppd[7812]: link 0 closed ,
linkunit: 0
May 22 10:57:17 schneemann2 ipppd[7812]: reinit_unit: 0
May 22 10:57:17 schneemann2 ipppd[7812]: Connect[0]:
/dev/ippp0, fd: 8
May 22 10:57:17 schneemann2 kernel: isdn_net: local hangup ippp0
May 22 10:57:17 schneemann2 kernel: ippp0: Chargesum is 0
Wäre nett, wenn sich mal
jemand von Euch meinen Logbuchauszug ansehen könnte.
Der ist total unlesnar fomatiert.
Es
erscheint immer ein „timout sending config request“. Weiß
jemand, woran das eventuell liegen könnte?
Ich tippe bei der Beschreibung auf Providerprobleme.
May 22 10:56:46 schneemann2 kernel: ippp0: dialing 1 0191011...
[...]
May 22 10:56:47 schneemann2 kernel: isdn\_net: ippp0 connected
May 22 10:56:50 schneemann2 ipppd[7812]: sent [0][LCP ConfReq id=0x1
May 22 10:57:14 schneemann2 last message repeated 8 times
May 22 10:57:17 schneemann2 ipppd[7812]: LCP: timeout sending Config-Requests
Ich kenne mich mit ISDN nicht so gut aus, aber es scheint so, als wenn Dein Provider auf Konfigurationsanfragen per LCP nicht antworten mag. Zumal es manchmal ja klappt…
Wäre nett, wenn sich mal
jemand von Euch meinen Logbuchauszug ansehen könnte.
Der ist total unlesnar fomatiert.
Es
erscheint immer ein „timout sending config request“. Weiß
jemand, woran das eventuell liegen könnte?
Ich tippe bei der Beschreibung auf Providerprobleme.
May 22 10:56:46 schneemann2 kernel: ippp0: dialing 1
0191011…
[…]
May 22 10:56:47 schneemann2 kernel: isdn_net: ippp0 connected
May 22 10:56:50 schneemann2 ipppd[7812]: sent [0][LCP ConfReq
id=0x1
May 22 10:57:14 schneemann2 last message repeated 8 times
May 22 10:57:17 schneemann2 ipppd[7812]: LCP: timeout sending
Config-Requests
Ich kenne mich mit ISDN nicht so gut aus, aber es scheint so,
als wenn Dein Provider auf Konfigurationsanfragen per LCP
nicht antworten mag. Zumal es manchmal ja klappt…
Normalerweise werden LCP-Messages gesendet und empfangen um das Handshaking durchzuführen (send, rcvd):
ipppd[10314]: sent [0][LCP ConfReq id=0x1]
ipppd[10314]: rcvd [0][LCP ConfReq id=0x1]
Wenn die Gegenseite nicht antwortet, kann es sein, daß sie nicht schnell genug hochkommt (lcp-restart erhöhen), oder kein (sync-) PPP-Daemon dort läuft. Ist dies nicht nur ein temporäres Problem, ist entweder die Nummer falsch, oder der ISP bietet tatsächlich kein syncPPP an.
Zitat Ende.
Wo Du den lcp-restart Eintrag finden kannst, steht ebenfall in dem Link. Man muss ja nicht alles vorsagen
danke für Deinen Wink mit dem ganzen Zaun, allerdings hat das
heruntersetzen von lcp-restart auf 2 bzw. in der weiteren Folge
1 nichts gebracht. Den „Fehler“ kann ich jetzt mit etwas Übung
bei jeder 3. Einwahl reproduzieren bzw. darauf warten.
Jetzt habe ich auch herausgefunden, dass ich inmitten dieses
„Hängens“ ein isdnctrl dial ippp0 machen kann und damit eine
sofortige Einwahl funktioniert. Mir ist nur nicht klar, ob es
nun an der automatischen Auflegenfunktion (nach ca. 2 Minuten)
liegt oder an irgendetwas anderem. Hast Du vielleicht noch eine
Idee, woran es sonst noch liegen könnte??? Meine Recherche bei
dejanews hat zwar eine Menge Fragen in die gleiche Richtung,
allerdings keine Antworten zu Tage gebracht.
Thomas
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ich verstehe unter „lcp-restart erhöhen“ eine Vergrößerung des
Wertes. Also nicht von 3 auf 1 sondern von 3 auf 4 oder 5.
Schonmal probiert?
Hatte ich nicht, aber soeben. Bei Einstellung 4 habe ich bei jedem EInwählvorgang Probleme, bei lcp-restart 5 geht überhaupt nichts mehr. Vor meinem letzten Posting hatte ich mich an die englische Anleitung (zu lcp-restart) in der Datei selbst gehalten und da steht: try to decrease the retry-cycle
und decrease dürfte nicht erhöhen sondern verringern sein.
