Am Freitag, 18. Oktober 2002 20:12 schrieb Rolf Dreissig:
Hallo Liste,
Hoffe das mir jemand weiter helfen kann,
Mein Problem ist, dass kein Verbindungsaufbau via ISDN zu Freenet aufgebaut werden kann. Die Einwahl funktionierte bisher immer. Erst seit einer Neuinstallation der SuSE 8.0 Pro geht bei Freenet nichts mehr.
Meine Installation: Pentium 3 mit 256MB RAM, SuSe 8.0 (Neuinstallation) Kernel 2.4.18-4GB, ISDN-Treiber i4l-2002.7.31-0 oder auch AVM capi-Treiber 8.0-03.09.10 , Netzwerk eth0 192.168.1.1, ippp0 192.168.0.99
Ankommende und Abgehende Verbindungen sind mit Fritz!DSL oder auch Ffritz!Classic kein Problem. Aber keine einzige der Verbindungen mit freenet via ISDN kommt zu Stande. Die Einwahl mit Modem oder mit ISDN unter Windoof zu freenet funktioniert ebenfalls. Aus irgend einem Grund meint der PC dass da kein Freenet-Server (oder keine aktive Verbindung) ist und er legt nach ca 9 Sekunden wieder auf.
Oct 13 18:12:08 s1 kernel: ippp0: dialing 1 01929... Oct 13 18:12:08 s1 isdnlog: Oct 13 18:12:08 * tei 64 calling 01929,, with +49 xxx/xxxxx, xxxxx RING (Data) Oct 13 18:12:16 s1 isdnlog: Oct 13 18:12:16 tei 64 calling 01929,, with +49 xxx/xxxxx, xxxxx Normal call clearing (User) Oct 13 18:12:16 s1 kernel: isdn_net: local hangup ippp0 Oct 13 18:12:16 s1 kernel: ippp0: Chargesum is 0 Oct 13 18:12:17 s1 isdnlog: Oct 13 18:12:17 tei 64 calling 01929,, with +49 xxx/xxxxx, xxxxx HANGUP ...
Anbei einige Konfigurationsdateien ------------------------------------------------- ... ------------------------------------------------- Ausgabe isdnctrl
Current setup of interface 'ippp0':
EAZ/MSN: xxxxx Phone number(s): Outgoing: 01929 Incoming: Dial mode: manual Secure: on Callback: off Reject before Callback: on Callback-delay: 2 Dialmax: 1 Hangup-Timeout: 120 Incoming-Hangup: off ChargeHangup: off Charge-Units: 0 Charge-Interval: 0 Layer-2-Protocol: hdlc Layer-3-Protocol: trans Encapsulation: syncppp Slave Interface: None Slave delay: 10 Master Interface: None Pre-Bound to: Nothing PPP-Bound to: 0 -------------------------------------------------
Also, hier kommt die Auflösung. Obwohl ich den Grund für dieses Verhalten nur mutmaßen kann. Letztendlich hat mich die Liste dann auf die Idee gebracht. Wenn auch nicht die Lösung von der Liste direkt kam so habt Ihr mir bestätigt dass ich in meiner Konfiguration keinen offentsichlichen Fehler habe. Besonderen Dank geht meiner Meinung nach wiedermal an Karsten weil er hier die kreativsten Beiträge lieferte. So nun genug der Lorbeeren... ;-) Bitte beachtet den Parameter Dialmax in der oberen Ausgabe von isdnctrl ! Ich habe mich daran erinnert, dass es bei yast 1 immer möglich war den dialmax-Parameter vorzugeben (also mindestens ab SuSE 5.1) . Die Konfiguration ist mit yast 2 also "vereinfacht" wurden. Der Dialmax kann nicht mehr direkt eingegeben werden. Zum Test kann man aber manuell "isdnctrl dialmax ippp0 3" eingeben. Das z.B. erhöht die Wählversuche für ippp0 auf 3. Vielleicht kann Karsten ja nochmal kurz beschreiben an welcher Stelle er es für sinnvoll hält den Parameter in das Suse-Script einzubauen. Ich möchte an dieser Stelle keinen Vorschlag machen, da ich kein Freund von Individuallösungen bin... ;-) Also was passiert nach der Änderung des Dialmax ? Na schaut es euch doch selber an. ------------------------------------------------- Oct 27 17:23:51 s1 kernel: ippp0: dialing 1 01929... Oct 27 17:23:51 s1 isdnlog: Oct 27 17:23:51 * tei 64 calling 01929,, with myServer RING (Data) Oct 27 17:24:00 s1 kernel: ippp0: dialing 2 01929... Oct 27 17:24:00 s1 kernel: capidrv-1: dail ch=0,"01929,7,0,xxxxx" in use (plci=0x101) Oct 27 17:24:01 s1 kernel: kcapi: appl 1 ncci 0x10101 up Oct 27 17:24:01 s1 isdnlog: Oct 27 17:24:01 tei 64 calling 01929,, with myServer Time:Sun Oct 27 16:26:00 2002 Oct 27 17:24:01 s1 isdnlog: Oct 27 17:24:01 tei 64 calling 01929,, with myServer CONNECT (Data) Oct 27 17:24:01 s1 isdnlog: Oct 27 17:24:01 tei 64 calling 01929,, with myServer INTERFACE ippp0 calling 01929 Oct 27 17:24:01 s1 isdnlog: Oct 27 17:24:01 tei 64 calling 01929,, with myServer CHARGE: 0.123 EUR/60s = 0.123 EUR/Min (DTAG T-ISDN Standard, Ortszone, täglich) Oct 27 17:24:01 s1 isdnlog: Oct 27 17:24:01 tei 64 calling 01929,, with myServer HINT: Better use 01013:Tele2 Privat CbC, 0.040 EUR/60s = 0.040 EUR/Min, saving 0.082 EUR/Min Oct 27 17:24:01 s1 isdnlog: Oct 27 17:24:01 tei 64 calling 01929,, with myServer 1.CI 0.123 EUR (now) Oct 27 17:24:01 s1 isdnlog: Oct 27 17:24:01 tei 64 calling 01929,, with myServer NEXT CI AFTER 01:00 (DTAG T-ISDN Standard, Ortszone, täglich) Oct 27 17:24:01 s1 ipppd[499]: Local number: xxxxx, Remote number: 01929, Type: outgoing Oct 27 17:24:01 s1 ipppd[499]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 7 Oct 27 17:24:01 s1 ipppd[499]: sent [0][LCP ConfReq id=0x1 <mru 1524> <magic 0x443a6863> <pcomp> <accomp>] Oct 27 17:24:01 s1 kernel: isdn_net: ippp0 connected Oct 27 17:24:01 s1 kernel: capidrv-1: chan 0 up with ncci 0x10101 Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][LCP ConfReq id=0x96 <auth pap> <magic 0xa890e2e6> <MPmrru 1524> <MPdiscr: 0x1 [ 64 74 6d 32 ]>] Oct 27 17:24:02 s1 ipppd[499]: sent [0][LCP ConfRej id=0x96 <MPmrru 1524>] Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][LCP ConfAck id=0x1 <mru 1524> <magic 0x443a6863> <pcomp> <accomp>] Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][LCP ConfReq id=0x97 <auth pap> <magic 0xa890e2e6> <MPdiscr: 0x1 [ 64 74 6d 32 ]>] Oct 27 17:24:02 s1 ipppd[499]: sent [0][LCP ConfAck id=0x97 <auth pap> <magic 0xa890e2e6> <MPdiscr: 0x1 [ 64 74 6d 32 ]>] Oct 27 17:24:02 s1 ipppd[499]: lcp layer is UP Oct 27 17:24:02 s1 ipppd[499]: sent [0][PAP AuthReq id=0x1 user="freenetuser" password="free"] Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][PAP AuthAck id=0x1msg=""] Oct 27 17:24:02 s1 ipppd[499]: Remote message: Oct 27 17:24:02 s1 ipppd[499]: MPPP negotiation, He: No We: No Oct 27 17:24:02 s1 ipppd[499]: sent [0][IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>] Oct 27 17:24:02 s1 ipppd[499]: CCP enabled! Trying CCP. Oct 27 17:24:02 s1 ipppd[499]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol) Oct 27 17:24:02 s1 ipppd[499]: ccp_resetci! Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][IPCP ConfReq id=0x6a <addr 62.104.210.42>] Oct 27 17:24:02 s1 ipppd[499]: sent [0][IPCP ConfAck id=0x6a <addr 62.104.210.42>] Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][IPCP ConfRej id=0x1 <compress VJ 0f 01>] Oct 27 17:24:02 s1 ipppd[499]: sent [0][IPCP ConfReq id=0x2 <addr 0.0.0.0>] Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][IPCP ConfNak id=0x2 <addr 213.7.224.6>] Oct 27 17:24:02 s1 ipppd[499]: sent [0][IPCP ConfReq id=0x3 <addr 213.7.224.6>] Oct 27 17:24:02 s1 ipppd[499]: rcvd [0][IPCP ConfAck id=0x3 <addr 213.7.224.6>] Oct 27 17:24:02 s1 ipppd[499]: local IP address xxx.xxx.xxx.xxx Oct 27 17:24:02 s1 ipppd[499]: remote IP address 62.104.210.42 ------------------------------------------------- Also ich betrachte die Sache noch nicht als erledigt. Wie man in der log sieht klappt die Verbindung erst beim zweiten Mal. Wie man weiter sieht, es passiert 9 Sekunden lang erstmal garnichts (1.Call ). Aber dann steht die Verbindung innerhalb 1 Sekunde. Obwohl ich nicht bei einer Telefongesellschaft arbeite, könnt ihr mir erzählen was ihr wollt, da ist eindeutig was faul. Noch eine Frage schlagt ihr vor ich soll meine "Erkenntnisse" mal an suse-freedback weiterleiter oder ist das nicht notwendig oder ist alles noch zu unausgegoren ? Im Besonderen würde mich interessieren ob die Leute die sich hier gemeldet hatten, dass ihre Verbindung ohne 01019 nicht klappt, nach einer Erhöhung des dialmax Parameters vielleicht nun möglicherweise doch ohne 01019 auskommen. Auch schon um dem Gerücht das dies "überhaupt" nicht mehr geht entgegen zu treten. Tuess und danke allen die an dem Thema interessiert waren Rolf PS Wegen des "guten" Services der freenet AG habe ich mich entschlossen mein langjähriges ABO bei eben diesen Unternehmen zum Monatsende zu künden. Ich will hier keine Stimmung machen, aber es ist jedem selbst überlassen sich mal Gedanken darüber zu machen von wem Provider leben.