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)
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
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
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
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
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
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
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
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