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