Re: Einwahl wird allmaehlich zu einer Katastrophe
Zunaechst einmal einen Riesendank an Karsten Keil und alle, die mir bisher geholfen haben. Doch leider scheint das Ganze kein Hardwareproblem zu sein. Ich bin dabei, mich gruendlich in ISDN for Linux einzuarbeiten, habe aber natuerlich auch etwas Wichtigeres am Laufen. Die Situation: Ich kann mich etwa einmal pro Tag bei meinem Provider einwaehlen. Die XMR-Meldung kommt nicht mehr und der Provider bestaetigt, dass bei allen anderen Einwaehlversuchen, die Anwahl registriert werden kann. Also scheint die ISDN-Karte (FritzCard) zu funktionieren. Verwende HiSax (siehe vorangegangene Mails). Bei einer vergeblichen Anwahl taucht zunaechstfolgende Meldung in /var/log/messages auf: ippd[6900] PHASE_WAIT->PHASE_ESTABLISHED ifunit:0, linkunit:0, fd:11 was sicherlich nichts anderes heisst, als dass auf eine Antwort gewartet wird. Bei einer nicht erfolgreichen Anwahl bleibt kinternet an dieser Stelle haengen und legt nach einer Weile auf (welcher Prozess das auch immer veranlasst). ippd[6900] Modem hangup ippd[6900] Connection terminated ippd[6900] taking down PHASE_DEAD link 0, linkunit: 0 Bis zu dieser Stelle kann ich keine Information ueber den Grund des Abbruchs erkennen. ippd[6900] closing fd 11 from unit 0 ippd[6900] link 0 closed, linkunit: 0 ippd[6900] reinit_unit: 0 connect [0]:/dev ippp0, fd 11 isdnlog <Verbindungsinformationen> HANGUP (0:00:21 I=0.0 b O=176.0 b) ippp0 remote hangup ippp0 Chargesum is 0 ippp_ccp: freeing reset date structure f7c8300 ippp, open, slot:0, minor:0, state:0000 ippp_ccp: allocated date structure f7c8300 In diesem Listing kann ich nichts Ungewoehnliches erkennen, zumal es auch bei dem Beenden einer normalen Verbindung auftritt (oder uebersehe ich da etwas?). Wenn eine Verbindung tatsaechlich zustande kommt, so folgt auf die PHASE_WAIT-Zeile MPPP negotiation, He: No We: No CCP enabled! Trying CCP CCP: got ccp-unit 0 for link 0 ccp_resetci Und dann folgen die zugewiesenen IP-Adressen. Hat jemand irgendeine Idee, wo man hier auf den Trichter des Uebels kommen kann? Ich schrieb, dass ich etwa vor zwei Wochen feststellte, dass ich mich mindestens zweimal einwaehlen musste, bis ich eine Verbindung bekam. Die Anwahlversuche stiegen gewaltig an. Als ich gestern eine Verbindung zustande brachte, auflegte, und gleich danach noch einmal anwaehlte, war der Ofen gleich wieder aus. Es ist mir ein absolutes Raetsel. Es ist nach meiner Erinnerung allerdings nicht das erste Mal, das so etwas auftritt (z.B. SuSE 9.2). Habe einen gewohenlichen Pentium 4 und absolut nichts an der Hardware auch nur annaehernd veraendert. Normalerweise wuerde es mich reizen, so etwas mit Hilfe der ellenlangen (aber offenbar sehr guten) Dokumentation selbst herauszufinden. Aber ich bin im Moment dabei, ein wichtiges Schriftstueck fertigzustellen, dass ich nicht aufschieben kann. Deshalb bitte ich alle um Entschuldigung, wenn ich auf diese Weise um Hilfe bitte. Ich kann mir das Ganze absolut nicht erklaeren, da so etwas bei Linux voellig ungewoehnlich ist. Viele Dank fuer Eure Hilfe Heiko Schroeder, Prag
On Sun, Jul 23, 2006 at 09:10:49PM +0200, heikos@foni.net wrote:
Zunaechst einmal einen Riesendank an Karsten Keil und alle, die mir bisher geholfen haben. Doch leider scheint das Ganze kein Hardwareproblem zu sein. Ich bin dabei, mich gruendlich in ISDN for Linux einzuarbeiten, habe aber natuerlich auch etwas Wichtigeres am Laufen. Die Situation: Ich kann mich etwa einmal pro Tag bei meinem Provider einwaehlen. Die XMR-Meldung kommt nicht mehr und der Provider bestaetigt, dass bei allen anderen Einwaehlversuchen, die Anwahl registriert werden kann. Also scheint die ISDN-Karte (FritzCard) zu funktionieren. Verwende HiSax (siehe vorangegangene Mails).
Bei einer vergeblichen Anwahl taucht zunaechstfolgende Meldung in /var/log/messages auf:
ippd[6900] PHASE_WAIT->PHASE_ESTABLISHED ifunit:0, linkunit:0, fd:11
was sicherlich nichts anderes heisst, als dass auf eine Antwort gewartet wird. Bei einer nicht erfolgreichen Anwahl bleibt kinternet an dieser Stelle haengen und legt nach einer Weile auf (welcher Prozess das auch immer veranlasst).
ippd[6900] Modem hangup ippd[6900] Connection terminated ippd[6900] taking down PHASE_DEAD link 0, linkunit: 0
Bis zu dieser Stelle kann ich keine Information ueber den Grund des Abbruchs erkennen.
ippd[6900] closing fd 11 from unit 0 ippd[6900] link 0 closed, linkunit: 0 ippd[6900] reinit_unit: 0 connect [0]:/dev ippp0, fd 11 isdnlog <Verbindungsinformationen> HANGUP (0:00:21 I=0.0 b O=176.0 b) ippp0 remote hangup ippp0 Chargesum is 0 ippp_ccp: freeing reset date structure f7c8300 ippp, open, slot:0, minor:0, state:0000 ippp_ccp: allocated date structure f7c8300
In diesem Listing kann ich nichts Ungewoehnliches erkennen, zumal es auch bei dem Beenden einer normalen Verbindung auftritt (oder uebersehe ich da etwas?).
Wenn eine Verbindung tatsaechlich zustande kommt, so folgt auf die PHASE_WAIT-Zeile
MPPP negotiation, He: No We: No CCP enabled! Trying CCP CCP: got ccp-unit 0 for link 0 ccp_resetci
Und dann folgen die zugewiesenen IP-Adressen. Hat jemand irgendeine Idee, wo man hier auf den Trichter des Uebels kommen kann?
in die /etc/ppp/ioptions ein paar mehr debug Zeilen eintragen, dann sieht man das Handshake im Detail. -- Karsten Keil SuSE Labs ISDN development
participants (2)
-
heikos@foni.net
-
Karsten Keil