Doku für capiinit, capi.conf, /etc/sysconfig/isdn, yast isdn
Hallo SuSE-ISDNler (falls es noch welche gibt), ich versuche gerade einen selbstgeschriebenen CAPI-Treiber (drivers/isdn/gigaset im Linux-Quellbaum, falls es jemanden interessiert) in openSUSE 11.2 zu integrieren. Wenn ich das CAPI-Subsystem von Hand starte (modprobe capi bzw. capiinit) funktioniert es einwandfrei, aber ich würde gerne erreichen, dass man das Gerät wie mit dem bisherigen ISDN4Linux-Treiber in "yast2 isdn" konfigurieren kann und es beim Systemstart automatisch aktiviert wird. Leider wollen sich die Puzzleteile der openSUSE-CAPI-Integration noch nicht so recht zusammenfügen. Eine zentrale Komponente ist wohl das Programm /sbin/capiinit aus dem Paket capi4linux. Zu dem scheint aber es außer der von "capiinit --help" ausgegebenen Usage-Meldung keinerlei Dokumentation zu geben. Weder "man capiinit" noch http://www.google.de/search?q=capiinit ergaben irgendetwas sachdienliches, und der Quellcode ist, nunja, nicht so ganz selbsterklärend. Fragen: - Was tut dieses Programm über ein schlichtes "modprobe capi" hinaus? - Was ist der Unterschied zwischen "capiinit start", "capiinit load" und "capiinit activate"? - Warum bleibt "capiinit stop" bei meinem Treiber einfach hängen? Was müsste er tun, damit das funktioniert? - "capiinit show" meldet: ERROR: no cards configured in /etc/capi.conf Was muss ich in /etc/capi.conf eintragen und wozu? (Außer damit diese Fehlermeldung weggeht.) Wo und wie wirken sich die dort eingetragenen Werte konkret aus? Eine weitere wichtige Komponente bilden nach meinem bisherigen Forschungsstand die Skripte in /etc/sysconfig/isdn/scripts. Es sieht so aus, als ob ich dort für den Gigaset-Treiber zwei Skripte "load-gigaset" und "stop-gigaset" hinterlegen sollte. Fragen: - Was genau sollten diese Skripte tun? - Welche Rolle spielt dabei das Skript "load-capi"? - Brauche ich auch ein Skript "add-gigaset"? - Sollte ich die USB IDs der Gigaset-Geräte in das Skript "hotplug_usb" eintragen? Geladen wird der Treiber auch so, und die Fehlermeldung "unknown USB product: $VENDID", die es andernfalls ausgeben müsste, habe ich noch nie zu Gesicht bekommen. - In "functions" gibt es eine Funktion "test_driver_loaded()", die offenbar eine hartcodierte Liste von CAPI-Treibernamen enthält, aber soweit ich sehen (d.h. greppen) konnte, nirgends benutzt wird. Welche Rolle spielt diese Funktion? Sollte ich die Liste ergänzen? Schließlich das YaST-Modul "isdn". Die bisherige I4L-Variante des Treibers habe ich ihm dank Unterstützung von Karsten Keil mit einem Patch für /usr/share/hwinfo/ISDN.CDB.txt (siehe https://bugzillafiles.novell.org/attachment.cgi?id=116705) beigebogen. Wie erweitere ich das nun auf die CAPI-Variante? Gibt es vielleicht sogar eine Möglichkeit, automatisch zu erkennen, ob die CAPI- oder die I4L-Variante des Treibers installiert ist? (Kconfig-Variable CONFIG_GIGASET_CAPI) Danke für alle Tipps. -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Was sucht ihr den Lebenden bei den Toten?
Noch eine Frage an die SuSE-ISDNler: In der Ausgabe von isdnlog stolpere ich über die Meldung "TERMINATOR IN LLO" - kann ich etwas aus dieser Meldung lernen? Die betreffende Zeile folgt auf eine Meldung "Destination out of order (Public network serving local user)", gefolgt wird sie von "HANGUP Destination out of order (Public network serving local user)". Hier die etwas betagten Versionsinformationen: isdnlog Version 4.59 Copyright (C) 1995 .. 2002 by Andreas Kool (akool@isdn4linux.de) Insbesondere interessiert mich, ob ich diese mit einem Ausfall der Datenübertragung verbundene Meldung auf den rufenden oder auf den angerufenen Rechner oder vielleicht auch auf den Übertragungsweg (Deutsche Telekom, T- Home) eingrenzen kann. Jeder Hinweis ist willkommen! Vielen Dank Sigward Funke -- Sigward Funke Institut fuer Geophysik und Geologie Tel. 0341 97-32816 Universitaet Leipzig Fax. 0341 97-32809 Talstr. 35, 04103 Leipzig E-mail: sfunke@rz.uni-leipzig.de Raum 2-15 -- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-isdn-de+help@opensuse.org
* Sigward Funke schrieb:
In der Ausgabe von isdnlog stolpere ich über die Meldung "TERMINATOR IN LLO" - kann ich etwas aus dieser Meldung lernen?
Die betreffende Zeile folgt auf eine Meldung "Destination out of order (Public network serving local user)", gefolgt wird sie von "HANGUP Destination out of order (Public network serving local user)".
Bist Du sicher, dass die Meldung von isdnlog stammt? Im Quelltext der isdn4k-utils ist sie nicht zu finden, im Gegensatz zu "Destination out of order", siehe http://www.isdn4linux.de/cgi-bin/viewcvs.cgi/isdn4k-utils/isdnlog/isdnlog/me... LLO als Abkürzung für "local lockout" kenne ich vom GPIB/IEEE488-Bus.
Insbesondere interessiert mich, ob ich diese mit einem Ausfall der Datenübertragung verbundene Meldung auf den rufenden oder auf den angerufenen Rechner oder vielleicht auch auf den Übertragungsweg (Deutsche Telekom, T- Home) eingrenzen kann.
Dem Wortlaut der Nachricht nach meldet die Vermittlungstelle des rufenden Rechners, dass der gerufene nicht erreichbar ist. Wenn Du es genauer wissen möchtest, müsstest Du die Layer-3-Meldungen mitschneiden (isdnlog -v1 ... "cat /dev/isdnctrl0") und dann anhand der Norm ITU Q.931 bzw. der ETSI-Präzisierung davon decodieren. Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Die Götter sind korrupt / Das Leben ist nicht fair / Der Himmel ist kaputt / Die Träume stehen leer / Die Wahrheit tut oft weh * Jochen Distelmeyer * -- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-isdn-de+help@opensuse.org
Hallo Tobias, Am Montag 12 April 2010 19:50:53 schrieb Tobias Becker:
* Sigward Funke schrieb:
In der Ausgabe von isdnlog stolpere ich über die Meldung "TERMINATOR IN LLO" - kann ich etwas aus dieser Meldung lernen?
Die betreffende Zeile folgt auf eine Meldung "Destination out of order (Public network serving local user)", gefolgt wird sie von "HANGUP Destination out of order (Public network serving local user)".
Bist Du sicher, dass die Meldung von isdnlog stammt?
Ja. Soweit ich es verstehe, landen auf meinem wählenden Rechner DOLLY zumindest manche Ausschriften von isdnlog im syslog. Jedenfalls finde ich dort neben Kernel-Meldungen auch welche von isdnlog. "irohr" ist der IP-Name des angerufenen Rechners. Hier ein paar Zeilen aus dem syslog. Die über mehrere Stunden scheiternden Anrufversuche passieren immer im 5er-Pack, die Meldung "TERMINATOR IN LLO" kommt hier nur bei den Versuchen 2 und 4 vor. [...] Apr 10 00:24:09 dolly kernel: irohr: dialing 2 0037438xxxxx... Apr 10 00:24:10 dolly isdnlog: Apr 10 00:24:10 tei 65 calling +49 37438/xxxxx, Bad Bramberg with DOLLY Destination out of order (Public network serving local user) Apr 10 00:24:10 dolly isdnlog: Apr 10 00:24:10 tei 65 calling +49 37438/xxxxx, Bad Bramberg with DOLLY TERMINATOR IN LLO Apr 10 00:24:10 dolly isdnlog: Apr 10 00:24:10 tei 65 calling +49 37438/xxxxx, Bad Bramberg with DOLLY HANGUP Destination out of order (Public network serving local user) Apr 10 00:24:14 dolly kernel: NETDEV WATCHDOG: irohr: transmit timed out [...]
Im Quelltext der isdn4k-utils ist sie nicht zu finden, im Gegensatz zu "Destination out of order", siehe http://www.isdn4linux.de/cgi-bin/viewcvs.cgi/isdn4k-utils/isdnlog/ isdnlog/messages.c
Könnte es bei meinem "alten" isdnlog anders sein? Hier nochmal die etwas betagten Versionsinformationen: isdnlog Version 4.59 Copyright (C) 1995 .. 2002 by Andreas Kool (akool@isdn4linux.de)
LLO als Abkürzung für "local lockout" kenne ich vom GPIB/IEEE488-Bus.
Klingt plausibel, mit dem Bus kenne ich mich aber überhaupt nicht aus.
Insbesondere interessiert mich, ob ich diese mit einem Ausfall der Datenübertragung verbundene Meldung auf den rufenden oder auf den angerufenen Rechner oder vielleicht auch auf den Übertragungsweg (Deutsche Telekom, T- Home) eingrenzen kann.
Dem Wortlaut der Nachricht nach meldet die Vermittlungstelle des rufenden Rechners, dass der gerufene nicht erreichbar ist.
Das ist ja soweit auch korrekt.
Wenn Du es genauer wissen möchtest, müsstest Du die Layer-3-Meldungen mitschneiden (isdnlog -v1 ... "cat /dev/isdnctrl0")
Kann ich das vorübergehend parallel zur bisherigen Konfiguration von isdnlog einrichten oder sollte ich das lieber alternativ machen? Wo könnte meine aktuelle Konfiguration stehen? Könnte /etc/isdn/isdnlog.isdnctrl0.options der richtige Ort sein?
und dann anhand der Norm ITU Q.931 bzw. der ETSI-Präzisierung davon decodieren.
Falls ich im syslog neue Meldungen finde, muss ich fürs Dekodieren noch mal nachfragen...
Gruß Tobias
Jetzt erst mal vielen Dank für die Hinweise! Sigward -- Sigward Funke Institut fuer Geophysik und Geologie Tel. 0341 97-32816 Universitaet Leipzig Fax. 0341 97-32809 Talstr. 35, 04103 Leipzig E-mail: sfunke@rz.uni-leipzig.de Raum 2-15 -- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-isdn-de+help@opensuse.org
* Sigward Funke schrieb am 13.04.2010 13:38:
Am Montag 12 April 2010 19:50:53 schrieb Tobias Becker:
Bist Du sicher, dass die Meldung von isdnlog stammt?
Ja. Soweit ich es verstehe, landen auf meinem wählenden Rechner DOLLY zumindest manche Ausschriften von isdnlog im syslog. Jedenfalls finde ich dort neben Kernel-Meldungen auch welche von isdnlog. "irohr" ist der IP-Name des angerufenen Rechners. Hier ein paar Zeilen aus dem syslog. Die über mehrere Stunden scheiternden Anrufversuche passieren immer im 5er-Pack, die Meldung "TERMINATOR IN LLO" kommt hier nur bei den Versuchen 2 und 4 vor.
[...] Apr 10 00:24:09 dolly kernel: irohr: dialing 2 0037438xxxxx... Apr 10 00:24:10 dolly isdnlog: Apr 10 00:24:10 tei 65 calling +49 37438/xxxxx, Bad Bramberg with DOLLY Destination out of order (Public network serving local user) Apr 10 00:24:10 dolly isdnlog: Apr 10 00:24:10 tei 65 calling +49 37438/xxxxx, Bad Bramberg with DOLLY TERMINATOR IN LLO Apr 10 00:24:10 dolly isdnlog: Apr 10 00:24:10 tei 65 calling +49 37438/xxxxx, Bad Bramberg with DOLLY HANGUP Destination out of order (Public network serving local user) Apr 10 00:24:14 dolly kernel: NETDEV WATCHDOG: irohr: transmit timed out [...]
Was mir noch eingefallen ist: Möglicherweise sendet deine Vermittlungsstelle (deine Telefonanlage) das "TERMINATOR IN LLO" als Textnachricht an den Anrufer. Ein ISDN-Telefon würde den Text im Display darstellen, isdnlog schreibt ihn ins Log. Insofern könnte "TERMINATOR IN LLO" dann die Übersetzung deiner Vermittlungsstelle für den numerischen Code sein, den isdnlog als "Destination out of order" bezeichnet.
Im Quelltext der isdn4k-utils ist sie nicht zu finden, im Gegensatz zu "Destination out of order", siehe http://www.isdn4linux.de/cgi-bin/viewcvs.cgi/isdn4k-utils/isdnlog/ isdnlog/messages.c
Könnte es bei meinem "alten" isdnlog anders sein? Hier nochmal die etwas betagten Versionsinformationen:
isdnlog Version 4.59 Copyright (C) 1995 .. 2002 by Andreas Kool (akool@isdn4linux.de)
Der ist zwar älter als die neueste Version der messages.c, deren Änderungen sind hier aber nicht relevant.
Wenn Du es genauer wissen möchtest, müsstest Du die Layer-3-Meldungen mitschneiden (isdnlog -v1 ... "cat /dev/isdnctrl0")
Kann ich das vorübergehend parallel zur bisherigen Konfiguration von isdnlog einrichten oder sollte ich das lieber alternativ machen? Wo könnte meine aktuelle Konfiguration stehen? Könnte /etc/isdn/isdnlog.isdnctrl0.options der richtige Ort sein?
Der Dateiname passt zu der Datei mit Einstellungen, die isdnlog üblicherweise beim Start mit der -f Option übergeben wird. In dieser Datei schreibst Du dann nicht "-v 1" sondern "log=1". Siehe "man isdnlog" für weitere Details. Dadurch werden die Protokoll-Nachrichten nach /tmp/isdnctrl0 kopiert, isdnlog läuft ansonsten normal weiter. Gruß Tobias -- Tobias Becker E-Mail tobiasb@talypso.de PGP 0xD06BB70D * Die Götter sind korrupt / Das Leben ist nicht fair / Der Himmel ist kaputt / Die Träume stehen leer / Die Wahrheit tut oft weh * Jochen Distelmeyer * -- To unsubscribe, e-mail: opensuse-isdn-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-isdn-de+help@opensuse.org
participants (3)
-
Sigward Funke -
Tilman Schmidt -
Tobias Becker