isdnlog - schreibt nichts ins Logfile
Hallo, seit einiger Zeit funktioniert isdnlog nicht mehr. Rechner: alte Krücke ;) Pentium 166. ISDN Karte: Sedlbauer speedFax PCI isdnlog version: 4.67 Kernel: 2.4.20-4GB (Original SuSE 8.2) Zur Vorgeschichte: Auf dem Server lief SuSE 7.1 jahrelang, ohne mucken. Irgendwann im August oder so hab ich dann einen neuen Kernel installiert, vorher wars glaub ich 2.4.16 nachher dann 2.4.19. Ab da ging isdnlog nicht mehr. Damals trug ich mich aber schon mit dem Gedanken SuSE 8.2 zu installieren da es verschiedene Applikationen, die ich einsetzen wollte nur noch mit glibc 2.3 gab. Das ist der Grund, weshalb ich das mit isdnlog nicht weiterverfolgt habe, ich dachte es wird bei SuSE 8.2 wieder alles laufen. Tja, denkste. Vorletzte Woche hatte ich dann einen Plattencrash und habe im Zuge der Reparatur dann eben auch gleich SuSE 8.2 installiert. Bis auf isdnlog und hylafax rennt jetzt alles. Zuerst also isdnlog, da ich glaube, dass das mit hylafax damit zu tun hat. Ich habe den kürzlichen Thread zu isdnlog mitverfolgt und alle Hinweise daraus untersucht. In /etc/isdn/isdnlog.options.contr0 diese Einträge gemacht: dual=0x100 stdout=0x7fffffff outfile=+/var/log/isdnlog.debug log=15 flush=yes eris:/etc/isdn # rcisdn stop Unloading ISDN driver hisax busy failed eris:/var/log # rcisdn start Setting up ISDN card contr0 Sedlbauer Speed Fax+ PCI done Loading Driver contr0 hisax done Loading firmware ISAR.BIN to contr0 contr0 1 4 Will overwrite entry `STDOUT'! #isdnlog.debug isdnlog: Can't open /dev/isdnctrl0 (No such device) isdnlog Version 4.64 exiting exit now 2 /dev/isdnctrl0 ist aber definitiv vorhanden. Und: isdnlog -V liefert die Version 4.67 Da ich das hisax busy nicht beseitigen konnte (rmmod bzw. init 1, init 3 reicht nicht) und ich nicht herausfinden konnte, warum hisax busy ist, hab ich auch mal einen Neustart versucht. Nützt nix... Etwas seltsames ist mir bei meinen Forschungen noch untergekommen: #/etc/sysconfig/isdn/scripts/functions # [...] get_i4l_id() { #set +x local -a _idxa local _lin _it _id card_id="-" #head -n 1 /dev/isdninfo | read _it _lin #echo "_it: $_it _lin: $_lin ii=$(head -n 1 /dev/isdninfo) test "$?" = "0" || return #echo $_lin | read -a _idxa _id=$1 _id=${_id:=0} _id=$(($_id * 2)) #was soll das? Bei >=0 ist korrekt, aber bei
0 ?? card_id=$(echo $ii|/usr/bin/awk '{ ID="`$_id`"+2; split($0,a," "); print a[ID]}') #$card_id={_idxa[$_id]} #set -x }
Das read in dieser Function geht nicht, egal was ich versucht habe, _it _lin sind immer leer. Mit meinen Änderungen liefert die Function das richtige Ergebnis so, dass das Script load_hisax damit arbeiten kann. Soweit ich das verstehe, soll contrX geliefert werden Ich habe auch versucht neue isdn4k-utils zu installieren, (CSV 2003-11-15) das compilieren bricht aber mit der Fehlermeldung ab, dass es aclocal-1.6 nicht gibt. Stimmt, aclocal-1.7 gibt es.... Any hints? -- Gruss Bernd
* Illuminatus@t-online.de (Bernd Obermayr) schrieb:
seit einiger Zeit funktioniert isdnlog nicht mehr.
Rechner: alte Krücke ;) Pentium 166. ISDN Karte: Sedlbauer speedFax PCI isdnlog version: 4.67 Kernel: 2.4.20-4GB (Original SuSE 8.2)
Zur Vorgeschichte: Auf dem Server lief SuSE 7.1 jahrelang, ohne mucken. Irgendwann im August oder so hab ich dann einen neuen Kernel installiert, vorher wars glaub ich 2.4.16 nachher dann 2.4.19. Ab da ging isdnlog nicht mehr. Damals trug ich mich aber schon mit dem Gedanken SuSE 8.2 zu installieren da es verschiedene Applikationen, die ich einsetzen wollte nur noch mit glibc 2.3 gab. Das ist der Grund, weshalb ich das mit isdnlog nicht weiterverfolgt habe, ich dachte es wird bei SuSE 8.2 wieder alles laufen. Tja, denkste. Vorletzte Woche hatte ich dann einen Plattencrash und habe im Zuge der Reparatur dann eben auch gleich SuSE 8.2 installiert. Bis auf isdnlog und hylafax rennt jetzt alles. Zuerst also isdnlog, da ich glaube, dass das mit hylafax damit zu tun hat.
Ich habe den kürzlichen Thread zu isdnlog mitverfolgt und alle Hinweise daraus untersucht.
In /etc/isdn/isdnlog.options.contr0 diese Einträge gemacht:
dual=0x100 stdout=0x7fffffff outfile=+/var/log/isdnlog.debug log=15 flush=yes
Das ist die Radikalkur zur Gewinnung möglichst vieler Logdaten falls die Protokollierung falsch läuft. Dein isdnlog bekommt offensichtlich aber gar keine D-Kanal-Daten zum verarbeiten. Generell sollte dann zunächst überprüft werden, ob das D-Kanal-Debugging im Hisax-Treiber mittels "hisaxctrl <id> 1 4" aktiviert wurde. Im speziellen Fall könnte die Ursache im Umfeld des devfs liegen, bei dem die ISDN-Gerätedateien in /dev/isdn statt in /dev liegen. Nach einem Update sind die Dateien vielleicht in beiden Verzeichnissen vorhanden, was zu Problemen führt.
Will overwrite entry `STDOUT'!
Der Eintrag stdout ist offenbar mehrfach in /etc/isdn/isdnlog.options.contr0 vorhanden.
#isdnlog.debug isdnlog: Can't open /dev/isdnctrl0 (No such device) isdnlog Version 4.64 exiting exit now 2
/dev/isdnctrl0 ist aber definitiv vorhanden. Und: isdnlog -V liefert die Version 4.67
Meistens ist isdnlog dann sowohl in /sbin als auch /usr/sbin installiert. Letzteres ist das richtigere Verzeichnis, erstere IIRC die Konfigurationsvorgabe der isdn4k-utils.
Ich habe auch versucht neue isdn4k-utils zu installieren, (CSV 2003-11-15) das compilieren bricht aber mit der Fehlermeldung ab, dass es aclocal-1.6 nicht gibt. Stimmt, aclocal-1.7 gibt es....
Hier hilft unter Umständen eine kürzliche Ergänzung der isdn4linux-FAQ weiter, unter http://www.isdn4linux.de/faq/i4lfaq-7.html#ss7.28 steht:
| 7.28 trouble_amproglibtool: When compiling isdn4k-utils I get the | error 'AM_PROG_LIBTOOL not found'? | | You have to regenerate the files from automake/autoconf with your | version of automake/autoconf. You can do it with the following shell | script (assuming you stored the source code for the isdn4k-utils under | /isdn/isdn4k-util): | | cd ~/isdn/isdn4k-utils | for i in capi20 capiinfo capifax capiinit rcapid ; do | cd $i | rm -f lt* | aclocal | libtoolize --force --automake --copy | automake --add-missing --copy | autoconf | cd .. | done | for i in eicon isdnlog ipppd ; do | cd $i | autoconf | cd .. | done
Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *
Tobias Becker schrieb:
* Illuminatus@t-online.de (Bernd Obermayr) schrieb:
seit einiger Zeit funktioniert isdnlog nicht mehr.
Rechner: alte Krücke ;) Pentium 166. ISDN Karte: Sedlbauer speedFax PCI isdnlog version: 4.67 Kernel: 2.4.20-4GB (Original SuSE 8.2)
Zur Vorgeschichte: Auf dem Server lief SuSE 7.1 jahrelang, ohne mucken. Irgendwann im August oder so hab ich dann einen neuen Kernel installiert, vorher wars glaub ich 2.4.16 nachher dann 2.4.19. Ab da ging isdnlog nicht mehr. Damals trug ich mich aber schon mit dem Gedanken SuSE 8.2 zu installieren da es verschiedene Applikationen, die ich einsetzen wollte nur noch mit glibc 2.3 gab. Das ist der Grund, weshalb ich das mit isdnlog nicht weiterverfolgt habe, ich dachte es wird bei SuSE 8.2 wieder alles laufen. Tja, denkste. Vorletzte Woche hatte ich dann einen Plattencrash und habe im Zuge der Reparatur dann eben auch gleich SuSE 8.2 installiert. Bis auf isdnlog und hylafax rennt jetzt alles. Zuerst also isdnlog, da ich glaube, dass das mit hylafax damit zu tun hat.
Ich habe den kürzlichen Thread zu isdnlog mitverfolgt und alle Hinweise daraus untersucht.
In /etc/isdn/isdnlog.options.contr0 diese Einträge gemacht:
dual=0x100 stdout=0x7fffffff outfile=+/var/log/isdnlog.debug log=15 flush=yes
Das ist die Radikalkur zur Gewinnung möglichst vieler Logdaten falls die Protokollierung falsch läuft. Dein isdnlog bekommt offensichtlich aber gar keine D-Kanal-Daten zum verarbeiten. Generell sollte dann zunächst überprüft werden, ob das D-Kanal-Debugging im Hisax-Treiber mittels "hisaxctrl <id> 1 4" aktiviert wurde.
Ja, das stand jedenfalls im Logfile.
Im speziellen Fall könnte die Ursache im Umfeld des devfs liegen, bei dem die ISDN-Gerätedateien in /dev/isdn statt in /dev liegen. Nach einem Update sind die Dateien vielleicht in beiden Verzeichnissen vorhanden, was zu Problemen führt.
Da hatte ich schon nachgesehen, /dev/isdn/ gibts nicht.
Will overwrite entry `STDOUT'!
Der Eintrag stdout ist offenbar mehrfach in /etc/isdn/isdnlog.options.contr0 vorhanden.
Stimmt: stdout=2048
#isdnlog.debug isdnlog: Can't open /dev/isdnctrl0 (No such device) isdnlog Version 4.64 exiting exit now 2
/dev/isdnctrl0 ist aber definitiv vorhanden. Und: isdnlog -V liefert die Version 4.67
Meistens ist isdnlog dann sowohl in /sbin als auch /usr/sbin installiert. Letzteres ist das richtigere Verzeichnis, erstere IIRC die Konfigurationsvorgabe der isdn4k-utils.
grmpfl ;) Das wars. Ich hab das schon mal mit locate überprüft, da war ich wohl blind. Wobei das isdnlog in /sbin das neuere war. (Übrigens auch isdnctrl) Also von /sbin nach /usr/sbin kopiert: Danke für den Tip, es geht jetzt ;))) Die Frage ist aber jetzt: Wo kommt das her? Wie gesagt es handelt sich um eine Neuinstallation von SuSE 8.2. Ich bin mir nicht bewusst, die insd4k-utils 2 mal installiert zu haben.
Ich habe auch versucht neue isdn4k-utils zu installieren, (CSV 2003-11-15) das compilieren bricht aber mit der Fehlermeldung ab, dass es aclocal-1.6 nicht gibt. Stimmt, aclocal-1.7 gibt es....
Hier hilft unter Umständen eine kürzliche Ergänzung der isdn4linux-FAQ weiter, unter http://www.isdn4linux.de/faq/i4lfaq-7.html#ss7.28 steht:
| 7.28 trouble_amproglibtool: When compiling isdn4k-utils I get the | error 'AM_PROG_LIBTOOL not found'? | | You have to regenerate the files from automake/autoconf with your | version of automake/autoconf. You can do it with the following shell | script (assuming you stored the source code for the isdn4k-utils under | /isdn/isdn4k-util): | | cd ~/isdn/isdn4k-utils | for i in capi20 capiinfo capifax capiinit rcapid ; do | cd $i | rm -f lt* | aclocal | libtoolize --force --automake --copy | automake --add-missing --copy | autoconf | cd .. | done | for i in eicon isdnlog ipppd ; do | cd $i | autoconf | cd .. | done
Gut, das werd ich vielleicht mal probieren bzw. gibts einen Grund das update auf jeden fall zu machen?
Gruß Tobias
Nochmal Danke. Gruss Bernd
* Illuminatus@t-online.de (Bernd Obermayr) schrieb:
Tobias Becker schrieb:
* Illuminatus@t-online.de (Bernd Obermayr) schrieb:
isdnlog: Can't open /dev/isdnctrl0 (No such device) isdnlog Version 4.64 exiting exit now 2
/dev/isdnctrl0 ist aber definitiv vorhanden. Und: isdnlog -V liefert die Version 4.67
Meistens ist isdnlog dann sowohl in /sbin als auch /usr/sbin installiert. Letzteres ist das richtigere Verzeichnis, erstere IIRC die Konfigurationsvorgabe der isdn4k-utils.
grmpfl ;) Das wars. Ich hab das schon mal mit locate überprüft, da war ich wohl blind. Wobei das isdnlog in /sbin das neuere war. (Übrigens auch isdnctrl)
Also von /sbin nach /usr/sbin kopiert: Danke für den Tip, es geht jetzt ;)))
Die Frage ist aber jetzt: Wo kommt das her? Wie gesagt es handelt sich um eine Neuinstallation von SuSE 8.2. Ich bin mir nicht bewusst, die insd4k-utils 2 mal installiert zu haben.
Demnach war isdnlog-4.64 in /usr/sbin und isdnlog-4.67 in /sbin installiert. isdnlog-4.64 datiert auf September 2002, isdnlog-4.67 auf Oktober 2003. Somit kann nur der 4.64er von SuSE 8.2 stammen. Beim 4.67er kann es sich dann eigentlich nur um einen selbstübersetzten isdnlog handeln, vielleicht war die Übersetzung trotz der aclocal-Versionskonflikte doch erfolgreich? Unklar bleibt weiterhin, wieso der 4.64er überhaupt nicht, auch nicht vor möglichen manuellen Installation des 4.67er funktionierte. Neuinstallation verstehe ich hier als Installation auf leere Partitionen. (Siehe http://www.isdn4linux.de/cgi-bin/viewcvs.cgi/isdn4k-utils/isdnlog/Makefile.i... für die Versionshistorie.)
Hier hilft unter Umständen eine kürzliche Ergänzung der isdn4linux-FAQ weiter, unter http://www.isdn4linux.de/faq/i4lfaq-7.html#ss7.28 steht: [...]
Gut, das werd ich vielleicht mal probieren bzw. gibts einen Grund das update auf jeden fall zu machen?
isdnlog-4.67 ist aktuell, da gibt es kein Notwendigkeit zum Update. Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Und erfahrene Menschen sagen, daß derjenige, der zu viel sieht und zu viel weiß, ähnlich wie der, der zu wenig sieht und zu wenig weiß, leicht vom richtigen Weg abkommt und untergeht. * Stefan Chwin *
participants (2)
-
Illuminatus@t-online.de
-
Tobias Becker