openSUSE ISDN (Deutsch) June 2007

isdn-de@lists.opensuse.org

8 participants
10 discussions

SuSE 10.2: fehlende Integration für Siemens Gigaset ISDN Treiber

by Tilman Schmidt

Ich bin ein bisschen enttäuscht. SuSE war immer "die" Distribution für ISDN. OpenSuSE 10.2 hat mit Version 2.6.18.2 endlich einen Kernel, in dem die ISDN-Treiber für die Siemens Gigaset SX255 und Verwandte integriert sind. Eine angeschlossene Gigaset-Basis oder ein M105 USB-Adapter werden korrekt aktiviert und dank udev auch mit der entsprechenden Gerätedatei /dev/ttyG[UB]0 verknüpft. Aber unter "Netzwerkgeräte - ISDN" in YaST erscheinen sie nicht. Man kann sie nicht einmal über den Knopf "Hinzufügen" manuell eintragen, denn in den angebotenen Gerätelisten sind sie ebenfalls nicht aufgeführt - weder unter "Siemens" noch unter "Telekom". Was kann ich als Mitentwickler dieser Treiber dazu beitragen, dass YaST sie in Zukunft korrekt erkennt und einbindet? Außerdem gibt es auf http://sourceforge.net/projects/gigaset307x ein Software-Paket gigaset-frontend, das nützliche Dienstprogramme für die Benutzung dieser Geräte enthält. Gibt es eine Chance, dass dieses Paket in die OpenSuSE-Distribution aufgenommen wird, und was muss dafür geschehen? Danke und fröhliche Weihnachten Tilman -- Tilman Schmidt E-Mail: tilman(a)imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

14 years, 2 months

10.2, hisax, Fritz PCI 2.1,: isdnlog faellt staendig aus

by Ekkard Gerlach

Hallo, 10.2, hisax, Fritz PCI 2.1: der isdnlog reagiert gelegentlich nicht, genauer gesagt das /etc/isdn/isdn.conf und darin dann z.B. [MSN] NUMBER = 12345678 ALIAS = Das Buero geht jetzt online! SI = 1 ZONE = 1 START = { [FLAG] FLAGS=IR USER=root GROUP=root PROGRAM = /usr/local/bin/my_skript } wird bei Anruf nicht ausgeführt. In 50% der Fälle schon. In /var/log/messages wird der eingehende Ruf gesehen, die Meldung May 30 17:32:49 server kernel: isdn_net: call from 907218307934 -> 0 30 ignored May 30 17:32:49 server kernel: isdn_tty: call from 907218307934 -> 30 ignored May 30 17:32:53 server kernel: isdn_net: call from 907218307934 -> 0 30 ignored May 30 17:32:53 server kernel: isdn_tty: call from 907218307934 -> 30 ignored erscheint IMMER im log, die entscheidende Meldung: May 30 17:32:49 praxisserver isdnlog: May 30 17:32:49 * Call to tei 127 from +49 766x/xxxxxxxxxxx, Kirchzarten on Das Buero geht jetzt online! kommt aber eher selten. Woran könnte das liegen? - Unter Suse 9.2 dutzendfach so laufen, jetzt das erste Mal unter 10.2. Uns ps ax | grep isdnlog ist dann nichts zu finden. Eigenartigerweise funktioniert dann der isdnlog ohne reboot dann wieder doch mal wieder gelegentlich ... oder ich irre micht, so exakt habe ich das nicht verfolgt, vielleicht er tot wenn er einmal tot ist. Mit einem Hack haben wir uns geholfen: in die /etc/crontab: -*/5 * * * * root bash -c 'ulimit -c unlimited;/usr/sbin/isdnlog -f /etc/isdn/isdnlog.options.contr0 /dev/isdnctrl0' > /dev/null Vorher muß einmalig rm /var/lock/LCK..isdnctrl0 , weil der Start vom Cron aus wohl ein anderer owner ist. Dann gehts aber. Es kommen zwar ständig Fehlermeldung: May 31 12:15:01 praxisserver isdnlog: isdnlog Version 4.71 starting May 31 12:15:01 praxisserver isdnlog: Another isdnlog is running with pid 24500! May 31 12:15:01 praxisserver isdnlog: If not delete the file `/var/run/isdnlog.isdnctrl0.pid' and try it again! May 31 12:15:01 praxisserver isdnlog: exit now 37 aber es häufen sich nicht die isdnlog's an. Es wird brav ein exit gemacht. Damit ist aber sichergestellt, dass der isdnlog läuft. Warum wird der isdnlog immer wieder beendet? Gruss Ekkard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 3 months

interne isdn-Karte - Verbindung wird nicht aufgebaut

by Werner Tietz

Hallo BS: Open-suse 10.2 Karte: Elsa-Mikrolink PCI (testweise auch AVM-Fritz-Card-PCI mit Hisax-treiber) Seit einigen Tagen funktioniert hier die Interneteinwahl nur noch sehr sporadisch - mit abnehmender Erfolgsquote. Nachdem ich das mal sicherheitshalber mit einer anderen isdn-Karte, und/oder anderen Betriebssystemen (Win 98, 2 verschiedenen Knoppix'en) ohne Erfolg ausprobiert habe, schliesse ich Hardware/Softwareprobleme im Computer eigentlich aus. Aber evtl kann mir hier ein Experte anhand des angefügtem Auszugs aus var/log/messages sagen ob ich beim Internetprovider oder bei T-Com als Netzbetreiber nachhaken muss - falls ich die Mail hier noch jemals gesendet kriege. gescheiterter Verbindungversuch: Jun 26 16:43:42 linuxwerner ifup: ippp0 Jun 26 16:43:42 linuxwerner SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. Jun 26 16:43:42 linuxwerner SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jun 26 16:43:43 linuxwerner SuSEfirewall2: batch committing... Jun 26 16:43:43 linuxwerner SuSEfirewall2: Firewall rules successfully set Jun 26 16:43:43 linuxwerner kernel: ippp0: dialing 1 0192071... Jun 26 16:43:43 linuxwerner isdnlog: Jun 26 16:43:43 * tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt RING (Data) Jun 26 16:43:44 linuxwerner isdnlog: Jun 26 16:43:44 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt Time:Tue Jun 26 16:44:00 2007 Jun 26 16:43:44 linuxwerner isdnlog: Jun 26 16:43:44 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt CONNECT (Data) Jun 26 16:43:44 linuxwerner isdnlog: Jun 26 16:43:44 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt INTERFACE ippp0 calling 0192071 Jun 26 16:43:44 linuxwerner isdnlog: Jun 26 16:43:44 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt No area info for provider 33_0 (11), destination 0192071 Jun 26 16:43:44 linuxwerner kernel: isdn_net: ippp0 connected Jun 26 16:43:44 linuxwerner ipppd[14748]: Local number: 914672, Remote number: 0192071, Type: outgoing Jun 26 16:43:44 linuxwerner ipppd[14748]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 12 Jun 26 16:44:06 linuxwerner isdnlog: Jun 26 16:44:06 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt Normal call clearing (Public network serving remote user) Jun 26 16:44:06 linuxwerner isdnlog: Jun 26 16:44:06 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt HANGUP ( 0:00:22 I=370.0 b O=666.0 b) Jun 26 16:44:06 linuxwerner kernel: ippp0: remote hangup Jun 26 16:44:06 linuxwerner kernel: ippp0: Chargesum is 0 Jun 26 16:44:06 linuxwerner ipppd[14748]: Modem hangup Jun 26 16:44:06 linuxwerner ipppd[14748]: Connection terminated. Jun 26 16:44:06 linuxwerner ipppd[14748]: taking down PHASE_DEAD link 0, linkunit: 0 Jun 26 16:44:06 linuxwerner ipppd[14748]: closing fd 12 from unit 0 Jun 26 16:44:06 linuxwerner ipppd[14748]: link 0 closed , linkunit: 0 Jun 26 16:44:06 linuxwerner ipppd[14748]: reinit_unit: 0 Jun 26 16:44:06 linuxwerner ipppd[14748]: Connect[0]: /dev/ippp0, fd: 12 Jun 26 16:44:06 linuxwerner kernel: ippp_ccp: freeing reset data structure e51e9000 Jun 26 16:44:06 linuxwerner kernel: ippp, open, slot: 0, minor: 0, state: 0000 Jun 26 16:44:06 linuxwerner kernel: ippp_ccp: allocated reset data structure e51e9000 Endlich mal wieder eine erfolgreiche Verbindung var/log/messages sieht jetzt so aus: Jun 26 17:06:06 linuxwerner ifup: ippp0 Jun 26 17:06:07 linuxwerner SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. Jun 26 17:06:07 linuxwerner SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jun 26 17:06:07 linuxwerner SuSEfirewall2: batch committing... Jun 26 17:06:07 linuxwerner SuSEfirewall2: Firewall rules successfully set Jun 26 17:06:07 linuxwerner kernel: ippp0: dialing 1 0192071... Jun 26 17:06:07 linuxwerner isdnlog: Jun 26 17:06:07 * tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt RING (Data) Jun 26 17:06:08 linuxwerner isdnlog: Jun 26 17:06:08 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt Time:Tue Jun 26 17:06:00 2007 Jun 26 17:06:08 linuxwerner isdnlog: Jun 26 17:06:08 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt CONNECT (Data) Jun 26 17:06:08 linuxwerner isdnlog: Jun 26 17:06:08 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt INTERFACE ippp0 calling 0192071 Jun 26 17:06:08 linuxwerner isdnlog: Jun 26 17:06:08 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt No area info for provider 33_0 (11), destination 0192071 Jun 26 17:06:08 linuxwerner kernel: isdn_net: ippp0 connected Jun 26 17:06:08 linuxwerner ipppd[14748]: Local number: 914672, Remote number: 0192071, Type: outgoing Jun 26 17:06:08 linuxwerner ipppd[14748]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 12 Jun 26 17:06:30 linuxwerner isdnlog: Jun 26 17:06:30 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt Normal call clearing (Public network serving remote user) Jun 26 17:06:30 linuxwerner isdnlog: Jun 26 17:06:30 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt HANGUP ( 0:00:22 I=370.0 b O=666.0 b) Jun 26 17:06:30 linuxwerner ipppd[14748]: Modem hangup Jun 26 17:06:30 linuxwerner ipppd[14748]: Connection terminated. Jun 26 17:06:30 linuxwerner ipppd[14748]: taking down PHASE_DEAD link 0, linkunit: 0 Jun 26 17:06:30 linuxwerner ipppd[14748]: closing fd 12 from unit 0 Jun 26 17:06:30 linuxwerner ipppd[14748]: link 0 closed , linkunit: 0 Jun 26 17:06:30 linuxwerner ipppd[14748]: reinit_unit: 0 Jun 26 17:06:30 linuxwerner ipppd[14748]: Connect[0]: /dev/ippp0, fd: 12 Jun 26 17:06:30 linuxwerner kernel: ippp0: remote hangup Jun 26 17:06:30 linuxwerner kernel: ippp0: Chargesum is 0 Jun 26 17:06:30 linuxwerner kernel: ippp_ccp: freeing reset data structure e51e9000 Jun 26 17:06:30 linuxwerner kernel: ippp, open, slot: 0, minor: 0, state: 0000 Jun 26 17:06:30 linuxwerner kernel: ippp_ccp: allocated reset data structure e51e9000 Jun 26 17:06:42 linuxwerner isdnlog: Jun 26 17:06:42 tei 64 calling ? with ? HANGUP ( 0:05:16) Jun 26 17:07:14 linuxwerner isdnlog: Jun 26 17:07:14 tei 64 calling ? with ? Time:Tue Jun 26 17:07:00 2007 Jun 26 17:07:14 linuxwerner isdnlog: Jun 26 17:07:14 tei 64 calling ? with ? CONNECT Jun 26 17:10:27 linuxwerner ifup: ippp0 Jun 26 17:10:27 linuxwerner SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. Jun 26 17:10:27 linuxwerner SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... Jun 26 17:10:27 linuxwerner SuSEfirewall2: batch committing... Jun 26 17:10:27 linuxwerner SuSEfirewall2: Firewall rules successfully set Jun 26 17:10:27 linuxwerner kernel: ippp0: dialing 1 0192071... Jun 26 17:10:27 linuxwerner isdnlog: Jun 26 17:10:27 * tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt RING (Data) Jun 26 17:10:28 linuxwerner isdnlog: Jun 26 17:10:28 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt Time:Tue Jun 26 17:11:00 2007 Jun 26 17:10:28 linuxwerner isdnlog: Jun 26 17:10:28 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt CONNECT (Data) Jun 26 17:10:28 linuxwerner isdnlog: Jun 26 17:10:28 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt INTERFACE ippp0 calling 0192071 Jun 26 17:10:28 linuxwerner isdnlog: Jun 26 17:10:28 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt No area info for provider 33_0 (11), destination 0192071 Jun 26 17:10:28 linuxwerner kernel: isdn_net: ippp0 connected Jun 26 17:10:28 linuxwerner ipppd[14748]: Local number: 914672, Remote number: 0192071, Type: outgoing Jun 26 17:10:28 linuxwerner ipppd[14748]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 12 Jun 26 17:10:50 linuxwerner isdnlog: Jun 26 17:10:50 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt Normal call clearing (Public network serving remote user) Jun 26 17:10:50 linuxwerner isdnlog: Jun 26 17:10:50 tei 126 calling 0192-071 Online-Dienste with +49 6004/914672, Lich-Eberstadt HANGUP ( 0:00:22 I=370.0 b O=666.0 b) Jun 26 17:10:50 linuxwerner ipppd[14748]: Modem hangup Jun 26 17:10:50 linuxwerner ipppd[14748]: Connection terminated. Jun 26 17:10:50 linuxwerner ipppd[14748]: taking down PHASE_DEAD link 0, linkunit: 0 Jun 26 17:10:50 linuxwerner ipppd[14748]: closing fd 12 from unit 0 Jun 26 17:10:50 linuxwerner ipppd[14748]: link 0 closed , linkunit: 0 Jun 26 17:10:50 linuxwerner ipppd[14748]: reinit_unit: 0 Jun 26 17:10:50 linuxwerner ipppd[14748]: Connect[0]: /dev/ippp0, fd: 12 Jun 26 17:10:50 linuxwerner kernel: ippp0: remote hangup Jun 26 17:10:50 linuxwerner kernel: ippp0: Chargesum is 0 Jun 26 17:10:50 linuxwerner kernel: ippp_ccp: freeing reset data structure e51e9000 Jun 26 17:10:50 linuxwerner kernel: ippp, open, slot: 0, minor: 0, state: 0000 Jun 26 17:10:50 linuxwerner kernel: ippp_ccp: allocated reset data structure e51e9000 Jun 26 17:13:28 linuxwerner ifup: ippp0 Gruß Werner --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 3 months

Re: [opensuse-isdn-de] 4adrig vs 8adrig

by Karsten Keil

On Sun, May 20, 2007 at 11:27:24PM +0200, Karsten Keil wrote: > On Sun, May 20, 2007 at 05:32:25PM +0200, Ingo Göppert wrote: > > Am Sonntag, 20. Mai 2007 11:57 schrieb Malte Gell: > > > On Sunday 20 May 2007 10:19, Ingo Göppert wrote: > > > > Hallo Malte, > > > > > > > > On 20.05.2007 10:08, Malte Gell wrote: > > > > > Hallo, > > > > > > > > > > ich hab eine FritzCard PCI am Laufen ("FritzCard Version 1") und > > > > > brauche wohl neues Anschlusskabel. Jetzt sehe ich bei Conrad, > > > > > dass es 8adrige und 4adrige Kabel gibt. Wenn ich mir den Stecker > > > > > so ansehe, sehe ich nur 4 Adern, wozu gibt es dann 8adrige? Oder > > > > > brauchts doch das 8adrige für die PCI-Karte => NTBA ? > > > > > > > > nein, du brauchst auch für PCI-Karte -> NTBA keine 8 Adern, ISDN > > > > funktioniert mit 4. > > > > > > Ok, danke. Um meine Neugierde zu stillen, wozu nimmt man dann die > > > 8adrigen? > > > > In Verbindung mit ISDN: Keine Ahnung. Sonst halt für Netzwerkkabel. > > > > Es gibt spezielle Geraete die ueber die restlichen Adern Strom beziehen > können, ist zumindest in den Specs (wenn ich mich nicht irre I.430) so > beschrieben. Mir sind solche Geraete noch nie untergekommen und die > deutschen NTBAs unterstuetzen auch nur die Speisung ueber die 4 Adern. > Zur Ergänzung: Ich habe gerade erfahren das es die Speisung über die Extra Leitungen beim 8 poligen Kabel wohl nur im amerikanischen Raum gibt (dort ist es der Standard), aber nicht in Europa. -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 3 months

dialin: je nach USER ein Skript starten

by Ekkard Gerlach

Wie kann ich bei einem ISDN-dialin je nach USERnamen, den er ipppd z.B. in /var/log/messages loggt, ein Skript starten? Gruss Ekkard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 3 months

Crash bei DATA_B3_REQ unter 64 Bit

by Lothar Kimmeringer

Hallo, ich habe lange Zeit nach einem Fehler bei mir gesucht, aber mir gehen langsam die Ideen aus ;-) Ich erweitere gerade den JCapi-Treiber fuer die Nutzung auf 64-Bit-Systemen und fliege auf einem OpenSuSE 10.2 staendig auf die Nase. Wenn ich mir das erzeugte DATA_B3_REQ ausgeben lassen, sieht das folgendermassen aus: -------------> Fri Jun 15 10:35:10 CEST 2007 362 Message ID: 83 -------------------------------------------------------------------------------- Raw length: 30 1e 00 02 00 86 80 83 00 01 02 01 00 00 00 00 00 '????????????????' 13 00 01 00 00 00 40 1c 77 ab aa 2a 00 00 '??????@?wÂ«Âª*??' -------------------------------------------------------------------------------- DATA_B3_REQ 2 Data-Handle = 0x1 Data-Length = 0x13 Flags = 00000000000000000000000000000000 NCCI = 0x10201 Data = 0x0 Data64 = 0x2aaaab771c40 Soweit alles OK und an sich "standardkonform". Der JNI-Wrapper macht dann folgendes bevor es an den CAPI-Layer weitergegeben wird: JNIEXPORT jint JNICALL Java_net_sourceforge_jcapi_Jcapi_nPutMessage (JNIEnv *env, jclass, jint appid, jbyteArray ja) { jbyte *msg; jint rc; msg = env->GetByteArrayElements(ja, 0); rc = (jint)(*capi20_put_message)((unsigned int)appid,(unsigned char *)msg); env->ReleaseByteArrayElements(ja, msg, 0); // after call of CapiPutMessage the CAPI works with it's own copy of the message return rc; } Also auch hier keine Magie, die etwas kaputtmachen wuerde (der Datenbereich wurde schon im Vorfeld gepinned, daher ist hier nur der reine Messagebereich betroffen. Versuche ich das ganze, fliegt mir die Java Virtual Machine aber um die Ohren mit folgender Meldung: | # SIGSEGV (0xb) at pc=0x00002b278a2a6812, pid=22309, tid=1120397632 [...] | --------------- T H R E A D --------------- | | Current thread (0x00002aaaab9c0c60): JavaThread "OFTP ReceiveThread(2)" [_thread_in_native, id=22356] | | siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0xffffffffab771c40 [...] | Stack: [0x0000000042b7e000,0x0000000042c7f000), sp=0x0000000042c7cc60, free space=1019k | Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) | C [libc.so.6+0x76812] memcpy+0x52 Anhand der si_addr kann man sehen, dass der urspruenglich 8-Byte-Pointer, wie er durch Data64 uebergeben wurde, wohl an irgendeiner Stelle auf 32 Bit gecastet wurde. Und wie gesagt sehe ich in meinem Code leider nicht, wo das passieren koennte, denn die Traceausgabe von ganz oben passiert direkt vor dem Aufruf der nPutMessage im JNI-Wrapper. Meine Vermutung, warum das knallt, liegt in capi20.c in den capi4k-utils (Zeile 291f): | memcpy(&data64,Msg+22, sizeof(u_int64_t)); | if (data64 != 0) dataptr = (void *)(unsigned long)data64; | else dataptr = Msg + len; /* Assume data after message */ Laut http://www.cygwin.com/ml/libc-hacker/2006-02/msg00060.html gab es wohl mal eine Zeit, als u_int64_t in manchen Bibliotheken 32 Bit breit war bzw. habe ich mal gelernt, das long nicht immer 64 Bit sein muss. In beiden Faellen wuerde man die Haelfte der Pointerinformationen verlieren. Warum das bisher nicht aufgefallen ist, duerfte daran liegen, dass man alternativ den Datenbereich direkt im Anschluss der CAPI-Message haben kann und dann Data und Data64 auf 0 laesst (dritte Zeile im Zitat oben). Es wuerde mich freuen, wenn mir jemand sagen koennte, dass ich mich irre und das Problem trotzdem bei mir liegt, dann gehe ich gerne auch wieder zurueck in eine C-For-Beginners-Newsgroup und sage nichts mehr ;-) Als Fix muesste ich speziell fuer unixoide System den Datenbereich an das Ende des Messagebereichs umkopieren und das wuerde ich eigentlich gerne vermeiden, wenn es nicht unbedingt sein muss. Danke und Gruesse, Lothar --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 4 months

OT: zweite Mal Fritz-PCI mit 20m-Kabel-Anbindung durchgebrannt

by Ekkard Gerlach

Es ist an einem PC mit Fritz PCI und 20m ISDN-Zuleitung innerhalb von 3 Monaten das zweite mal eine Karte durchgebrannt. Es wurde der ganze ISDN Mehrgeräteanschluss gestört, so dass nix mehr möglich war, kein Sprach- und kein Datendienst. Ist da evtl. das 20m lange Zuleitungskabel mitschuld? Oder einfach nur Zufall? Die erste Karte hat gut 1 Jahr gehalten, die zweite (vom Gebrauchtmarkt, ebay). Gruss Ekkard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 4 months

OT: zweite Mal Fritz-PCI mit 20m-Kabel-Anbindung durchgebrannt

by Ekkard Gerlach

14 years, 4 months

CAPISUITE 0.5.cvs / suse10.2

by Torsten Kerstan

Hallo Liste, langsam verzweifele ich mit der capisuite.. Gibt diese capisuite.conf jemandem Hinweise darauf, warum ich keine Faxe empfangen kann (senden aktuell nicht überprüft)? Siehe insbesondere Line 15! 1. Fri Jun 1 13:22:33 2007 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81f5690: PythonScript created. 2. Fri Jun 1 13:22:33 2007 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81f5690: IdleScript created. 3. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: * 4. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: <CONNECT_IND PLCI 0x101 CIP 0x11 5. Fri Jun 1 13:22:52 2007 Connection 0x81ed448: Connection object created for incoming call PLCI 101 from **8302127797954 to 24 CIP 0x11 6. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: ** 7. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: * 8. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: <INFO_IND: Controller/PLCI 0x101, InfoNumber 1e (ignoring) 9. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: >INFO_RESP ApplId 0x2, MsgNr 0x5, Address 0x101 10. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: info: 0 11. Fri Jun 1 13:22:52 2007 Capi 0x81a2850: ** 12. Fri Jun 1 13:22:52 2007 Pythonscript /usr/lib/capisuite/incoming.py,callIncoming,0x81d4d00: PythonScript created. 13. Fri Jun 1 13:22:52 2007 Pythonscript /usr/lib/capisuite/incoming.py,callIncoming,0x81d4d00: Connection 0x81ed448 created IncomingScript 14. Fri Jun 1 13:22:53 2007 Connection 0x81ed448: Python: deleting connection object 15. Fri Jun 1 13:22:53 2007 Connection 0x81ed448: rejecting with cause 34a9 16. Fri Jun 1 13:22:53 2007 Capi 0x81a2850: >CONNECT_RESP ApplId 0x2, msgNum 0x4, PLCI 0x101, Reject 0x34a9, B1proto 0x0, B2proto 0x0, B3proto 0x0 17. Fri Jun 1 13:22:53 2007 Capi 0x81a2850: info: 0 18. Fri Jun 1 13:22:53 2007 Capi 0x81a2850: * 19. Fri Jun 1 13:22:53 2007 Capi 0x81a2850: <DISCONNECT_IND PLCI 0x101 Reason 0x0 20. Fri Jun 1 13:22:53 2007 Capi 0x81a2850: >DISCONNECT_RESP ApplId 0x2 MsgNum 0x8 PLCI 0x101 21. Fri Jun 1 13:22:53 2007 Capi 0x81a2850: info: 0 22. Fri Jun 1 13:22:53 2007 Capi 0x81a2850: ** 23. Fri Jun 1 13:22:53 2007 Connection 0x81ed448: stop_file_transmission initiated 24. Fri Jun 1 13:22:53 2007 Connection 0x81ed448: stop_file_transmission finished 25. Fri Jun 1 13:22:53 2007 Connection 0x81ed448: stop_file_reception finished 26. Fri Jun 1 13:22:53 2007 Connection 0x81ed448: Connection object deleted 27. Fri Jun 1 13:22:53 2007 Pythonscript /usr/lib/capisuite/incoming.py,callIncoming,0x81d4d00: IncomingScript deleted 28. Fri Jun 1 13:22:53 2007 Pythonscript /usr/lib/capisuite/incoming.py,callIncoming,0x81d4d00: PythonScript deleted. 29. Fri Jun 1 13:23:05 2007 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81f5690: executing idlescript... 30. Fri Jun 1 13:23:05 2007 Pythonscript /usr/lib/capisuite/idle.py,idle,0x81f5690: idlescript finished... Gruß Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 4 months

AVM FritzCard-USB2.0 / Konfiguration

by Torsten Kerstan

Hallo Liste, ich habe im Suse-10.2 Sysz´temm das Problem, dass die Fritz_Card sich nicht / merkwürdig konfigurieren läßt. Wenn ich die Karte erstmalig einrichte wird in Yast das Gerät contr0 eingerichtet, später werden aber weitere Geräte hinzugefügt, die jeweils als nicht konfiguriert gekennzeichnet werden. Nach Konfiguration werden diese dann als contr1, 2 Geräte aufgeführt. Bei der Bestätigung der Konfiguration kommt der Hinweis, dass Treiber ohne Quellcode ausgewählt wurde... Wie kann ich denn den Status der richtig installierten Hardware überprüfen? Mit capiinfo? Oder gibt es noch grundlegendere Informationsquellen? ki01:/usr/lib/capisuite # capiinfo Number of Controllers : 1 Controller 1: Manufacturer: AVM GmbH CAPI Version: 2.0 Manufacturer Version: 3.11-07 (49.23) Serial Number: 0000000 BChannels: 2 Global Options: 0x00000039 internal controller supported DTMF supported Supplementary Services supported channel allocation supported (leased lines) B1 protocols support: 0x4000011f 64 kbit/s with HDLC framing 64 kbit/s bit-transparent operation V.110 asynconous operation with start/stop byte framing V.110 synconous operation with HDLC framing T.30 modem for fax group 3 Modem asyncronous operation with start/stop byte framing B2 protocols support: 0x00000b1b ISO 7776 (X.75 SLP) Transparent LAPD with Q.921 for D channel X.25 (SAPI 16) T.30 for fax group 3 ISO 7776 (X.75 SLP) with V.42bis compression V.120 asyncronous mode V.120 bit-transparent mode B3 protocols support: 0x800000bf Transparent T.90NL, T.70NL, T.90 ISO 8208 (X.25 DTE-DTE) X.25 DCE T.30 for fax group 3 T.30 for fax group 3 with extensions Modem 0100 0200 39000000 1f010040 1b0b0000 bf000080 00000000 00000000 00000000 00000000 00000000 00000000 01000001 00020000 00000000 00000000 00000000 Supplementary services support: 0x000003ff Hold / Retrieve Terminal Portability ECT 3PTY Call Forwarding Call Deflection MCID CCBS capiinfo - ENDE Danke für Tips Gruß Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-isdn-de+help(a)opensuse.org

14 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

openSUSE ISDN (Deutsch) June 2007