Re: [suse-isdn] Re: Nachfrage zu AVM Treibern
Anbei ein Screenshot (wenn er durchkommt), welcher zeigt, daß sowohl kernel-default, als auch kernel-default-nongpl und kernel-source in Version 2.6.8-24.10 installiert sind ...
Ich hätte es auch ohne geglaubt. (Wie macht man den Screenshots unter Linux?) Ich empfehle dann zusätzlich noch km_fritzcapi-2.6-32.i586.rpm zu installieren und in /usr/src/kernel-modules/fritzcapi make make install
Holger Krull scribbled on 04.01.2005 17:03:
Anbei ein Screenshot (wenn er durchkommt), welcher zeigt, daß sowohl kernel-default, als auch kernel-default-nongpl und kernel-source in Version 2.6.8-24.10 installiert sind ...
Ich hätte es auch ohne geglaubt. (Wie macht man den Screenshots unter Linux?)
Ich greife hier via puTTY auf die Linuxmaschine zu ...
Ich empfehle dann zusätzlich noch km_fritzcapi-2.6-32.i586.rpm zu
suse92:/home/torsten # rpm -qa | grep km_* km_fcdsl-2.6-27 km_fritzcapi-2.6-32 suse92:/home/torsten #
installieren und in /usr/src/kernel-modules/fritzcapi make make install
Das werde morgen früh mal ausführen, und dann über das Resultat informieren ... muß nun weg. Danke für Deine Zeit & Mühen! ;-) Gruß
Guten Morgen! :-) Torsten E. scribbled on 04.01.2005 18:00:
Holger Krull scribbled on 04.01.2005 17:03:
[...]
installieren und in /usr/src/kernel-modules/fritzcapi make make install
Das werde morgen früh mal ausführen, und dann über das Resultat informieren ... muß nun weg.
Hier nun die Ausgabe: suse92:/usr/src/kernel-modules/fritzcapi # make set -e; for i in fritz.pci fritz.pcmcia fritz.pnp fritz.classic fritz.usb fritz.usb2 fritz.xusb fritz.xusb_CZ e2220pc e5520pc; do \ make KDIR=/lib/modules/2.6.8-24.10-default/build -C $i/src ;\ done make[1]: Entering directory `/usr/src/kernel-modules/fritzcapi/fritz.pci/src' make -C /lib/modules/2.6.8-24.10-default/build SUBDIRS=/usr/src/kernel-modules/fritzcapi/fritz.pci/src modules make[2]: Entering directory `/usr/src/linux-2.6.8-24.10-obj/i386/default' make -C ../../../linux-2.6.8-24.10 O=../linux-2.6.8-24.10-obj/i386/default modules CC [M] /usr/src/kernel-modules/fritzcapi/fritz.pci/src/main.o CC [M] /usr/src/kernel-modules/fritzcapi/fritz.pci/src/driver.o CC [M] /usr/src/kernel-modules/fritzcapi/fritz.pci/src/tools.o CC [M] /usr/src/kernel-modules/fritzcapi/fritz.pci/src/tables.o CC [M] /usr/src/kernel-modules/fritzcapi/fritz.pci/src/queue.o CC [M] /usr/src/kernel-modules/fritzcapi/fritz.pci/src/lib.o LD [M] /usr/src/kernel-modules/fritzcapi/fritz.pci/src/fcpci.o ld: /usr/src/linux-2.6.8-24.10/../lib/fcpci-lib.o: No such file: Datei oder Verzeichnis nicht gefunden make[5]: *** [/usr/src/kernel-modules/fritzcapi/fritz.pci/src/fcpci.o] Fehler 1 make[4]: *** [_module_/usr/src/kernel-modules/fritzcapi/fritz.pci/src] Fehler 2 make[3]: *** [modules] Fehler 2 make[2]: *** [modules] Fehler 2 make[2]: Leaving directory `/usr/src/linux-2.6.8-24.10-obj/i386/default' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/usr/src/kernel-modules/fritzcapi/fritz.pci/src' make: *** [modules] Fehler 2 suse92:/usr/src/kernel-modules/fritzcapi # Ich nehme an, daß es schiefgeht, da ja keine oben aufgeführte Karte verbaut ist ... ?
Danke für Deine Zeit & Mühen! ;-)
Gruß
Gruß Torsten
Ich nehme an, daß es schiefgeht, da ja keine oben aufgeführte Karte verbaut ist ... ?
Nein, daran kann es nicht liegen. Es wird ja nur kompiliert, nicht versucht einen Treiber zu starten. Ich habe keine Ahnung warum das kompilieren fehlschlägt, denn fcpci-lib.o baut er ja einen Moment vorher. Vielleicht ja make clean mal vorher. ld: /usr/src/linux-2.6.8-24.10/../lib/fcpci-lib.o: No such file: Datei oder Verzeichnis nicht gefunden Und hier meldet der Linker das er es nicht findet. Eigentlich müsste /usr/src/kernel-modules/fritzcapi/fritz.pci/lib/fcpci-lib.o vorhanden sein. An deinem System ist was komisch.
Holger Krull scribbled on 05.01.2005 11:50:
Ich nehme an, daß es schiefgeht, da ja keine oben aufgeführte Karte verbaut ist ... ?
Nein, daran kann es nicht liegen. Es wird ja nur kompiliert, nicht versucht einen Treiber zu starten. Ich habe keine Ahnung warum das kompilieren fehlschlägt, denn fcpci-lib.o baut er ja einen Moment vorher. Vielleicht ja make clean mal vorher.
Das ergibt selbstredend selbige Meldung.
ld: /usr/src/linux-2.6.8-24.10/../lib/fcpci-lib.o: No such file: Datei oder Verzeichnis nicht gefunden Und hier meldet der Linker das er es nicht findet. Eigentlich müsste /usr/src/kernel-modules/fritzcapi/fritz.pci/lib/fcpci-lib.o vorhanden sein. An deinem System ist was komisch.
Das einzig komische ist, daß es sich um ein SuSE System handelt (;-)), bei welchem seit SuSE 8.2 sofort nach dem jeweils ersten Kernelupdate das ISDN-Logging aufhört zu arbeiten ... SuSE will nicht helfen (scheint zumindest so), AVM verweist (telefonisch) an SuSE ... :-( ... ggf. probiere ich es doch mal mit dem Vanilla Kernel Gruß Torsten
An deinem System ist was komisch.
Das einzig komische ist, daß es sich um ein SuSE System handelt (;-)), bei welchem seit SuSE 8.2 sofort nach dem jeweils ersten Kernelupdate das ISDN-Logging aufhört zu arbeiten ... SuSE will nicht helfen (scheint zumindest so), AVM verweist (telefonisch) an SuSE ... :-( ... ggf. probiere ich es doch mal mit dem Vanilla Kernel
Hm, dh. capi funktioniert bei dir noch, nur das Logging geht nicht? Baust du dir mit den Suse Quellen einen eigenen Kernel oder nimmst du den von Suse. Wenn du einen Vanilla Kernel nimmst musst du die AVM Treiber auch kompilieren, und wenn das schon jetzt nicht geht wird das vielleicht schwierig.
Holger Krull scribbled on 05.01.2005 12:16:
An deinem System ist was komisch.
Das einzig komische ist, daß es sich um ein SuSE System handelt (;-)), bei welchem seit SuSE 8.2 sofort nach dem jeweils ersten Kernelupdate das ISDN-Logging aufhört zu arbeiten ... SuSE will nicht helfen (scheint zumindest so), AVM verweist (telefonisch) an SuSE ... :-( ... ggf. probiere ich es doch mal mit dem Vanilla Kernel
Hm, dh. capi funktioniert bei dir noch, nur das Logging geht nicht?
Exakt! Ich kann Faxe versenden & empfangen, auch capisuite loggt jeden eingehenden Anruf, etc. - nur das ISDN Logging funzt nicht. Tobias Becker schickte mir (14. November 2004 18:21) daraufhin einen Link zu einem netten Schaubild http://www.heise.de/ct/04/03/182/bild.gif. So wie es interpretiere, muß das ISDN Logging Problem nichts mit capi zu tun haben ... kann aber (da ich nicht weiß, wie capi & capidrv zusammenhänegn ...). Auf jeden Fall arbeiten capisuite & hylafax mit der kernelcapi, während isdnlog mit dem capidrv (ich nehme an, daß dieser Teil von AVM stammt) werkelt.
Baust du dir mit den Suse Quellen einen eigenen Kernel oder nimmst du den von Suse. Wenn du einen Vanilla Kernel nimmst musst du die AVM Treiber auch kompilieren, und wenn das schon jetzt nicht geht wird das vielleicht schwierig.
Das kommt darauf an, s. o. Gruß Torsten
Exakt! Ich kann Faxe versenden & empfangen, auch capisuite loggt jeden eingehenden Anruf, etc. - nur das ISDN Logging funzt nicht. Tobias Becker schickte mir (14. November 2004 18:21) daraufhin einen Link zu einem netten Schaubild http://www.heise.de/ct/04/03/182/bild.gif.
Hübsches Bild.
So wie es interpretiere, muß das ISDN Logging Problem nichts mit capi zu tun haben
Das sehe ich auch so. Fall von anderer Baustelle. Was sagt den lsmod | egrep 'capi|isdn' und ps u -p `pgrep isdnlog`
Holger Krull scribbled on 05.01.2005 12:47:
Exakt! Ich kann Faxe versenden & empfangen, auch capisuite loggt jeden
eingehenden Anruf, etc. - nur das ISDN Logging funzt nicht. Tobias Becker schickte mir (14. November 2004 18:21) daraufhin einen Link zu einem netten Schaubild http://www.heise.de/ct/04/03/182/bild.gif.
Hübsches Bild.
So wie es interpretiere, muß das ISDN Logging Problem nichts mit capi zu tun haben
Das sehe ich auch so. Fall von anderer Baustelle.
Was sagt den lsmod | egrep 'capi|isdn'
suse92:/ # lsmod | egrep 'capi|isdn' capidrv 28852 2 isdn 133324 5 capidrv slhc 7936 2 ppp_generic,isdn capi 17472 16 capifs 5896 2 capi kernelcapi 45984 3 fcdsl,capidrv,capi suse92:/ #
und ps u -p `pgrep isdnlog`
root 6571 0.0 0.1 2824 616 ? S Jan03 0:00 /usr/sbin/isdnlog -f /etc/isdn/isdnlog.options.contr0 /dev/isdnctrl0 Gruß Torsten
Am Mittwoch, 5. Januar 2005 13:50 schrieb Torsten E.:
Holger Krull scribbled on 05.01.2005 12:47:
Exakt! Ich kann Faxe versenden & empfangen, auch capisuite loggt jeden
eingehenden Anruf, etc. - nur das ISDN Logging funzt nicht. Tobias Becker schickte mir (14. November 2004 18:21) daraufhin einen Link zu einem netten Schaubild http://www.heise.de/ct/04/03/182/bild.gif.
Hübsches Bild.
So wie es interpretiere, muß das ISDN Logging Problem nichts mit capi zu tun haben
Das sehe ich auch so. Fall von anderer Baustelle.
Was sagt den lsmod | egrep 'capi|isdn'
suse92:/ # lsmod | egrep 'capi|isdn' capidrv 28852 2 isdn 133324 5 capidrv slhc 7936 2 ppp_generic,isdn capi 17472 16 capifs 5896 2 capi kernelcapi 45984 3 fcdsl,capidrv,capi suse92:/ #
und ps u -p `pgrep isdnlog`
root 6571 0.0 0.1 2824 616 ? S Jan03 0:00 /usr/sbin/isdnlog -f /etc/isdn/isdnlog.options.contr0 /dev/isdnctrl0
Gruß Torsten Hallo Torsten,
mein Vorschlag geh mal auf den Suse Standard Kernel zurück..teste ob es klappt mein lsmod | egrep 'capi|isdn' sieht so aus: capidrv 34484 1 isdn 144972 5 capidrv slhc 11392 1 isdn capi 22592 8 capifs 9992 2 capi kernelcapi 51584 3 fcpci,capidrv,capi uname -a Linux Server 2.6.10 #1 SMP Tue Dec 28 15:37:32 CET 2004 i686 i686 i386 GNU/Linux meine bescheidene Meinung: Ich tippe mal ganz bescheiden auf eine Fehlkonfiguration des Kernels. Falls es mit dem Standardkernel nicht geht könnte es auch ein Hardwareproblem sein. G. Roland
Ich tippe mal ganz bescheiden auf eine Fehlkonfiguration des Kernels. Falls es mit dem Standardkernel nicht geht könnte es auch ein Hardwareproblem sein.
Ein Hardwareproblem halte ich für ausgeschlossen wenn die Capi-Anwendungen gehen und nur Isdnlog nicht mag.
Was sagt den lsmod | egrep 'capi|isdn'
suse92:/ # lsmod | egrep 'capi|isdn' capidrv 28852 2 isdn 133324 5 capidrv slhc 7936 2 ppp_generic,isdn capi 17472 16 capifs 5896 2 capi kernelcapi 45984 3 fcdsl,capidrv,capi
ps u -p `pgrep isdnlog`
root 6571 0.0 0.1 2824 616 ? S Jan03 0:00 /usr/sbin/isdnlog -f /etc/isdn/isdnlog.options.contr0 /dev/isdnctrl0
Alles da. Meldet sich capidrv bei einem Anruf? Dh. was sagt grep capidrv /var/log/messages.
Holger Krull scribbled on 05.01.2005 14:29:
Was sagt den lsmod | egrep 'capi|isdn'
suse92:/ # lsmod | egrep 'capi|isdn' capidrv 28852 2 isdn 133324 5 capidrv slhc 7936 2 ppp_generic,isdn capi 17472 16 capifs 5896 2 capi kernelcapi 45984 3 fcdsl,capidrv,capi
ps u -p `pgrep isdnlog`
root 6571 0.0 0.1 2824 616 ? S Jan03 0:00 /usr/sbin/isdnlog -f /etc/isdn/isdnlog.options.contr0 /dev/isdnctrl0
Alles da. Meldet sich capidrv bei einem Anruf? Dh. was sagt grep capidrv /var/log/messages.
Die ist das gesamte Logging, wenn ein Anruf für eine auf dem Linuxsystem hinterlegte Rufnummer ankommt (AB Funktion von capisuite): Jan 5 15:09:14 suse92 kernel: capidrv-1: incoming call ,1,1,501383 Jan 5 15:09:14 suse92 kernel: capidrv-1: patching si2=1 to 0 for VBOX Jan 5 15:09:14 suse92 kernel: isdn_net: Incoming call without OAD, assuming '0' Jan 5 15:09:14 suse92 kernel: isdn_net: call from 0 -> 0 501383 ignored Jan 5 15:09:14 suse92 kernel: isdn_tty: Incoming call without OAD, assuming '0' Jan 5 15:09:14 suse92 kernel: isdn_tty: call from 0 -> 501383 ignored Jan 5 15:09:14 suse92 kernel: capidrv-1: incoming call ,1,0,501383 ignored Jan 5 15:09:29 suse92 kernel: capilib_new_ncci: kcapi: appl 3 ncci 0x20201 up Jan 5 15:09:48 suse92 kernel: kcapi: appl 3 ncci 0x20201 down Anschließend wird das Gespräch vom AB angenommen, und die Nachricht des Anrufers aufgezeichnet (und dann per Email zugestellt) - also funktioniert dies so wie vorgesehen. Währenddessen: suse92:/ # ls -l /var/log/isdn* -rw-r--r-- 1 root root 1460 2004-10-30 12:52 /var/log/isdn.log suse92:/ # Gruß Torsten
Jan 5 15:09:14 suse92 kernel: capidrv-1: incoming call ,1,1,501383 Jan 5 15:09:14 suse92 kernel: capidrv-1: patching si2=1 to 0 for VBOX Jan 5 15:09:14 suse92 kernel: isdn_net: Incoming call without OAD, assuming '0' Jan 5 15:09:14 suse92 kernel: isdn_net: call from 0 -> 0 501383 ignored Jan 5 15:09:14 suse92 kernel: isdn_tty: Incoming call without OAD, assuming '0' Jan 5 15:09:14 suse92 kernel: isdn_tty: call from 0 -> 501383 ignored Jan 5 15:09:14 suse92 kernel: capidrv-1: incoming call ,1,0,501383 ignored Jan 5 15:09:29 suse92 kernel: capilib_new_ncci: kcapi: appl 3 ncci 0x20201 up Jan 5 15:09:48 suse92 kernel: kcapi: appl 3 ncci 0x20201 down
Sieht doch soweit auch gut aus, der Anruf kommt mindestens mal bis capidrv durch. Was sagt lsof /dev/isdnctrl0 und ls -ld /dev/isdnctrl0
Holger Krull scribbled on 05.01.2005 15:31:
Jan 5 15:09:14 suse92 kernel: capidrv-1: incoming call ,1,1,501383 Jan 5 15:09:14 suse92 kernel: capidrv-1: patching si2=1 to 0 for VBOX Jan 5 15:09:14 suse92 kernel: isdn_net: Incoming call without OAD, assuming '0' Jan 5 15:09:14 suse92 kernel: isdn_net: call from 0 -> 0 501383 ignored Jan 5 15:09:14 suse92 kernel: isdn_tty: Incoming call without OAD, assuming '0' Jan 5 15:09:14 suse92 kernel: isdn_tty: call from 0 -> 501383 ignored Jan 5 15:09:14 suse92 kernel: capidrv-1: incoming call ,1,0,501383 ignored Jan 5 15:09:29 suse92 kernel: capilib_new_ncci: kcapi: appl 3 ncci 0x20201 up Jan 5 15:09:48 suse92 kernel: kcapi: appl 3 ncci 0x20201 down
Sieht doch soweit auch gut aus, der Anruf kommt mindestens mal bis capidrv durch. Was sagt lsof /dev/isdnctrl0
suse92:/ # lsof /dev/isdnctrl COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME isdnlog 6571 root 3r CHR 45,64 117442908 /dev/isdnctrl0 suse92:/ #
und ls -ld /dev/isdnctrl0
suse92:/ # lsof /dev/isdnctrl COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME isdnlog 6571 root 3r CHR 45,64 117442908 /dev/isdnctrl0 suse92:/ # Das sollte doch gleichfalls i. O. sein ... Gruß Torsten
Das sollte doch gleichfalls i. O. sein ...
Ja, sieht auch gut aus. Nun ist die Frage wo die Info hängenbleibt. Wie sieht deine isdnlog.options.contr0 aus? Starte doch mal isdnlog manuell mit /usr/sbin/isdnlog -P /dev/isdnctrl0 kommen dann Meldungen bei einem Anruf?
Holger Krull scribbled on 05.01.2005 16:03:
Das sollte doch gleichfalls i. O. sein ...
Ja, sieht auch gut aus. Nun ist die Frage wo die Info hängenbleibt.
Wie sieht deine isdnlog.options.contr0 aus?
Nur die relevanten Zeilen (also keine auskommentierten): [options] daemon=yes syslog=1013 monitor=yes stdout=2048 newline=yes width=80 start=yes thruput=5 time=0 bilingual=no
Starte doch mal isdnlog manuell mit
/usr/sbin/isdnlog -P /dev/isdnctrl0
kommen dann Meldungen bei einem Anruf?
Nein, leider nicht: suse92: # ps ax | grep isdnlog 6571 ? S 0:00 /usr/sbin/isdnlog -f /etc/isdn/isdnlog.options.contr0 /dev/isdnctrl0 25270 pts/0 R+ 0:00 grep isdnlog suse92: # kill 6571 suse92: # ps ax | grep isdnlog 25272 pts/0 S+ 0:00 grep isdnlog suse92: # /usr/sbin/isdnlog -P /dev/isdnctrl0 isdnlog Version 4.69 starting Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/lib/isdn/holiday-de.dat] Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH Zone V1.25: Provider 0 File '/usr/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5 Rates Version 3.10 [25-Aug-2004 00:58:04] loaded [81 Providers, 691 Zones, 3207 Areas, 41 Services, 668 Comments, 9 eXce ptions, 67 Redirects, 2254 Rates from /usr/lib/isdn/rate-de.dat] (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) isdn.conf:3 active channels, 2 MSN/SI entries (Data versions: iprofd=0x06 net_cfg=0x06 /dev/isdninfo=0x01) Everything is fine, isdnlog-4.69 is running in full featured mode. Got signal 2 exit now 7 File /var/run/isdnlog.isdnctrl0.pid removed! File /var/lock/LCK..isdnctrl0 removed! (Abgebrochen mittels Strg-C) suse92: # ls -l /var/log/isdn.log -rw-r--r-- 1 root root 1460 2004-10-30 12:52 /var/log/isdn.log suse92: # Gruß Torsten
suse92: # /usr/sbin/isdnlog -P /dev/isdnctrl0 isdnlog Version 4.69 starting Holiday Version 1.10-Germany [12-Apr-1999] loaded [11 entries from /usr/lib/isdn/holiday-de.dat] Dest V1.01: File '/usr/lib/isdn/dest.cdb' opened fine - Dest 1.0 int (+h) AT DE NL CH Zone V1.25: Provider 0 File '/usr/lib/isdn/zone-de-dtag.cdb' opened fine - V1.25 K2 C2 N256 T157147 O1 L5 Rates Version 3.10 [25-Aug-2004 00:58:04] loaded [81 Providers, 691 Zones, 3207 Areas, 41 Services, 668 Comments, 9 eXce ptions, 67 Redirects, 2254 Rates from /usr/lib/isdn/rate-de.dat] (ISDN subsystem with ISDN_MAX_CHANNELS > 16 detected, ioctl(IIOCNETGPN) is available) isdn.conf:3 active channels, 2 MSN/SI entries (Data versions: iprofd=0x06 net_cfg=0x06 /dev/isdninfo=0x01) Everything is fine, isdnlog-4.69 is running in full featured mode. Got signal 2 exit now 7 File /var/run/isdnlog.isdnctrl0.pid removed! File /var/lock/LCK..isdnctrl0 removed!
Der einzige erkennbare Unterschied zu meinem System ist das bei mir am Ende Everything is fine, isdnlog-4.69 is running in full featured mode. (AVM B1 driver detected (D2)) steht. Isdnlog holt seine Informationen aus /dev/isdnctrl0 und /dev/isdninfo wenn lsof /dev/isdninfo auch ausgibt das isdnlog dran hängt, dann weiss ich nicht weiter. Die Info bleibt zwischen capidrv und den /dev/isdn* Einträgen hängen. Ich habe keine Ahnung wie der Weg dazwischen funktioniert. Bleibt noch zu kontrollieren wie die dev Einträge aussehen. Was sagt ls -l /dev/isdnctrl0 und ls -l /dev/isdninfo? In dem hübschen Bild hängt zwischen capidrv und /dev/isdnctrl noch die Hardware Interface genannte Komponente, keine Ahnung was das sein soll (ich glaube die existiert nicht wirklich). capidrv stammt aus dem ISDN4Linux Paket, vielleicht gibt es da ja weitere Infos.
Holger Krull schrieb: [...]
Der einzige erkennbare Unterschied zu meinem System ist das bei mir am Ende Everything is fine, isdnlog-4.69 is running in full featured mode. (AVM B1 driver detected (D2)) steht.
Isdnlog holt seine Informationen aus /dev/isdnctrl0 und /dev/isdninfo wenn lsof /dev/isdninfo auch ausgibt das isdnlog dran hängt, dann weiss ich nicht weiter. Die Info bleibt zwischen capidrv und den /dev/isdn* Einträgen hängen. Ich habe keine Ahnung wie der Weg dazwischen funktioniert. Bleibt noch zu kontrollieren wie die dev Einträge aussehen. Was sagt ls -l /dev/isdnctrl0 und ls -l /dev/isdninfo?
suse92:/ # ls -l /dev/isdnctrl0 crw------- 1 root root 45, 64 2004-10-02 10:38 /dev/isdnctrl0 suse92:/ # suse92:/ # ls -l /dev/isdninfo cr--r--r-- 1 root root 45, 255 2004-10-02 10:38 /dev/isdninfo suse92:/ #
In dem hübschen Bild hängt zwischen capidrv und /dev/isdnctrl noch die Hardware Interface genannte Komponente, keine Ahnung was das sein soll (ich glaube die existiert nicht wirklich). capidrv stammt aus dem ISDN4Linux Paket, vielleicht gibt es da ja weitere Infos.
Das geht mir eigentlich schon zu tief in die Eingeweide des Kernels ;-) Auf jeden Fall Danke ich Dir schon einmal für Deine Bemühungen! Gruß Torsten
suse92:/ # ls -l /dev/isdnctrl0 crw------- 1 root root 45, 64 2004-10-02 10:38 /dev/isdnctrl0
Hoppla, hier ist ein Unterschied crw----rw- 1 root root 45, 64 Oct 2 10:38 /dev/isdnctrl0 Ändert sich was wenn du rw für alle freigibst? (Muss man da isdnlog neu starten?)
In dem hübschen Bild hängt zwischen capidrv und /dev/isdnctrl noch die Hardware Interface genannte Komponente, keine Ahnung was das sein soll (ich glaube die existiert nicht wirklich). capidrv stammt aus dem ISDN4Linux Paket, vielleicht gibt es da ja weitere Infos.
Das geht mir eigentlich schon zu tief in die Eingeweide des Kernels ;-) Auf jeden Fall Danke ich Dir schon einmal für Deine Bemühungen!
Das muss ja nicht unbedingt der Kernel sein. Und da es auch nicht an den AVM Modulen muss man wohl jemand fragen der sich mit capidrv auskennt.
Holger Krull schrieb:
suse92:/ # ls -l /dev/isdnctrl0 crw------- 1 root root 45, 64 2004-10-02 10:38 /dev/isdnctrl0
Hoppla, hier ist ein Unterschied crw----rw- 1 root root 45, 64 Oct 2 10:38 /dev/isdnctrl0 Ändert sich was wenn du rw für alle freigibst? (Muss man da isdnlog neu starten?)
torsten@suse92:~> ls -l /dev/isdnctrl* lrwxrwxrwx 1 root root 9 2004-10-26 12:29 /dev/isdnctrl -> isdnctrl0 crw----rw- 1 root root 45, 64 2004-10-02 10:38 /dev/isdnctrl0 crw------- 1 root root 45, 65 2004-10-02 10:38 /dev/isdnctrl1 crw------- 1 root root 45, 74 2004-10-02 10:38 /dev/isdnctrl10 crw------- 1 root root 45, 75 2004-10-02 10:38 /dev/isdnctrl11 crw------- 1 root root 45, 76 2004-10-02 10:38 /dev/isdnctrl12 crw------- 1 root root 45, 77 2004-10-02 10:38 /dev/isdnctrl13 crw------- 1 root root 45, 78 2004-10-02 10:38 /dev/isdnctrl14 crw------- 1 root root 45, 79 2004-10-02 10:38 /dev/isdnctrl15 crw------- 1 root root 45, 66 2004-10-02 10:38 /dev/isdnctrl2 crw------- 1 root root 45, 67 2004-10-02 10:38 /dev/isdnctrl3 crw------- 1 root root 45, 68 2004-10-02 10:38 /dev/isdnctrl4 crw------- 1 root root 45, 69 2004-10-02 10:38 /dev/isdnctrl5 crw------- 1 root root 45, 70 2004-10-02 10:38 /dev/isdnctrl6 crw------- 1 root root 45, 71 2004-10-02 10:38 /dev/isdnctrl7 crw------- 1 root root 45, 72 2004-10-02 10:38 /dev/isdnctrl8 crw------- 1 root root 45, 73 2004-10-02 10:38 /dev/isdnctrl9 torsten@suse92:~> Anschließend habe ich das System neu gestartet ... und dann: torsten@suse92:~> ls -l /var/log/isdn.log -rw-r--r-- 1 root root 1460 2004-10-30 12:52 /var/log/isdn.log torsten@suse92:~> Es hat also keine Veränderung erbracht.
In dem hübschen Bild hängt zwischen capidrv und /dev/isdnctrl noch die Hardware Interface genannte Komponente, keine Ahnung was das sein soll (ich glaube die existiert nicht wirklich). capidrv stammt aus dem ISDN4Linux Paket, vielleicht gibt es da ja weitere Infos.
Das geht mir eigentlich schon zu tief in die Eingeweide des Kernels ;-) Auf jeden Fall Danke ich Dir schon einmal für Deine Bemühungen!
Das muss ja nicht unbedingt der Kernel sein. Und da es auch nicht an den AVM Modulen muss man wohl jemand fragen der sich mit capidrv auskennt.
Wer auch immer das sein mag ... ggf. werde ich mal eine Email an den einen oder anderen Kerneldeveloper schicken, um nachzifragen, wer sich damit beschäftigt (andere fallen mir momentan nicht ein) - aber da werde ich schon eine Info dazu erhalten. Gruß Torsten
Anschließend habe ich das System neu gestartet ... und dann:
Wenn du das System neu startest wird üblicherweise die Rechtezuteilung wieder zurückgesetzt (udev).
Wer auch immer das sein mag ... ggf. werde ich mal eine Email an den einen oder anderen Kerneldeveloper schicken, um nachzifragen, wer sich damit beschäftigt (andere fallen mir momentan nicht ein) - aber da werde ich schon eine Info dazu erhalten.
Wie wäre es mit dem Autor von capidrv /* $Id: capidrv.c,v 1.1.2.2 2004/01/12 23:17:24 keil Exp $ * * ISDN4Linux Driver, using capi20 interface (kernelcapi) * * Copyright 1997 by Carsten Paeth <calle@calle.de>
Holger Krull schrieb:
Anschließend habe ich das System neu gestartet ... und dann:
Wenn du das System neu startest wird üblicherweise die Rechtezuteilung wieder zurückgesetzt (udev).
Aber offenbar zumindest nicht /dev/isdnctrl*
Wer auch immer das sein mag ... ggf. werde ich mal eine Email an den einen oder anderen Kerneldeveloper schicken, um nachzifragen, wer sich damit beschäftigt (andere fallen mir momentan nicht ein) - aber da werde ich schon eine Info dazu erhalten.
Wie wäre es mit dem Autor von capidrv /* $Id: capidrv.c,v 1.1.2.2 2004/01/12 23:17:24 keil Exp $ * * ISDN4Linux Driver, using capi20 interface (kernelcapi) * * Copyright 1997 by Carsten Paeth <calle@calle.de>
Argh ... klar, hätte ich auch darauf kommen sollen ... können ... müssen ;-)
On Wed, Jan 05, 2005 at 06:41:00PM +0100, Torsten E. wrote:
Holger Krull schrieb:
Anschließend habe ich das System neu gestartet ... und dann:
Wenn du das System neu startest wird üblicherweise die Rechtezuteilung wieder zurückgesetzt (udev).
Aber offenbar zumindest nicht /dev/isdnctrl*
Nein, die werden zum GlÃŒck von udev nicht angefasst. Die Rechte sind aber eigentlich egal, da isdnlog von init als root gestartet wird.
Wer auch immer das sein mag ... ggf. werde ich mal eine Email an den einen oder anderen Kerneldeveloper schicken, um nachzifragen, wer sich damit beschäftigt (andere fallen mir momentan nicht ein) - aber da werde ich schon eine Info dazu erhalten.
Wie wäre es mit dem Autor von capidrv /* $Id: capidrv.c,v 1.1.2.2 2004/01/12 23:17:24 keil Exp $ * * ISDN4Linux Driver, using capi20 interface (kernelcapi) * * Copyright 1997 by Carsten Paeth <calle@calle.de>
Argh ... klar, hätte ich auch darauf kommen sollen ... können ... müssen ;-)
Ich konnte das bisher nicht nachvollziehen, isdnlog arbeitet bei mir mit den CAPI Treibern. Zu dem CT Bild (stammt uebrigens von mir): Das HW interface ist die Schnittstelle zwischen dem I4L core und den verschiedenen HW Treibern, capidrv ist ein I4L Hardwaretreiber fuer CAPI Karten. Das HW Interface ist wie alle anderen I4L Kern Komponenten Bestandteil des isdn Moduls (isdn.o bzw. isdn.ko). Der Source des Hardwareinterfaces ist in isdn_common.c. -- Karsten Keil SuSE Labs ISDN development
N'Abend, Karsten Keil scribbled on 10.01.2005 20:25:
On Wed, Jan 05, 2005 at 06:41:00PM +0100, Torsten E. wrote:
Holger Krull schrieb:
[...]
Ich konnte das bisher nicht nachvollziehen, isdnlog arbeitet bei mir mit den CAPI Treibern.
Hier leider nicht. Das Angebot aus 2003 bzgl. einem SSH Zugang besteht selbstredend immer noch.
Zu dem CT Bild (stammt uebrigens von mir):
Nett! ;-)
Das HW interface ist die Schnittstelle zwischen dem I4L core und den verschiedenen HW Treibern, capidrv ist ein I4L Hardwaretreiber fuer CAPI Karten. Das HW Interface ist wie alle anderen I4L Kern Komponenten Bestandteil des isdn Moduls (isdn.o bzw. isdn.ko). Der Source des Hardwareinterfaces ist in isdn_common.c.
Sorry, aber das sagt mir nun wahrlich nicht viel. Für mich ist bei alledem einfach nur nicht wirklich nachvollziehbar, warum die Programmteile der capisuite sämtliche Infos erhalten, daß ISDN Log aber nichts erhalt bzw. aufzeichnet. Eine Rückmeldung gleich welcher Art gab es bis dato von Carsten Paeth übrigens nicht. Gruß Torsten
On Mon, Jan 10, 2005 at 08:42:24PM +0100, Torsten E. wrote:
N'Abend,
Karsten Keil scribbled on 10.01.2005 20:25:
On Wed, Jan 05, 2005 at 06:41:00PM +0100, Torsten E. wrote:
Holger Krull schrieb:
[...]
Ich konnte das bisher nicht nachvollziehen, isdnlog arbeitet bei mir mit den CAPI Treibern.
Hier leider nicht. Das Angebot aus 2003 bzgl. einem SSH Zugang besteht selbstredend immer noch.
OK, teil mir die Daten per PMail mit, das sollte ein debugging beschleunigen.
Zu dem CT Bild (stammt uebrigens von mir):
Nett! ;-)
Das HW interface ist die Schnittstelle zwischen dem I4L core und den verschiedenen HW Treibern, capidrv ist ein I4L Hardwaretreiber fuer CAPI Karten. Das HW Interface ist wie alle anderen I4L Kern Komponenten Bestandteil des isdn Moduls (isdn.o bzw. isdn.ko). Der Source des Hardwareinterfaces ist in isdn_common.c.
Sorry, aber das sagt mir nun wahrlich nicht viel. Für mich ist bei alledem einfach nur nicht wirklich nachvollziehbar, warum die Programmteile der capisuite sämtliche Infos erhalten, daß ISDN Log aber nichts erhalt bzw. aufzeichnet.
Schau Dir nochmal das Bild an und ziehe mitten drin einen senkrechten dicken Strich (praktisch zwischen dem Kasten capisuite und dem der u.a. vbox/hylafax enthaelt bis ganz nach unten). Links von dem Strich ist CAPI, funktioniert auch ohne I4L, deshalb geht auch capisuite, capiinfo usw. Der Rechte Teil ist ISDN4Linux (I4L), das mit CAPI garnichts zu tun hat, aber z.B. isdnlog ansteuert. capidrv ist praktisch dazwischen, fuer die CAPI Seite ist es eine Applikation fuer die I4L Seite ist es ein Hardwaretreiber. Jetzt klarer ?
Eine Rückmeldung gleich welcher Art gab es bis dato von Carsten Paeth übrigens nicht.
Calle arbeitet nur noch selten an I4L/CAPI. -- Karsten Keil SuSE Labs ISDN development
participants (4)
-
Holger Krull -
Karsten Keil -
Roland May -
Torsten E.