isdnrep -keine incoming calls-
Hallo, ich habe ein Problem mit isdnrep und eingehenden Anrufen und habe in den Archiven dazu leider nichts gefunden. Konfiguration: SuSE 8.1, zwei aktive B1-Karten am Anlagenanschluss, für HylaFAX konfiguriert. i4l-isdnlog-2002.9.8-4 Die Datei /var/log/isdn.log ist prächtig mit mannigfaltigen Daten gefüllt. Mein Problem ist, dass ich keinerlei Informationen zu den eingehenden Anrufen erhalte, wenn ich isdnrep -a ausführe. <schnipp> Outgoing calls (calling:) Summary for Fri Aug 01 2003 .. Fri Aug 15 2003 ------------------------------------------------------------------------------ UNKNOWN 58 call(s) 0:36:27 4.4449 EUR Incoming calls (called by:) Summary for Fri Aug 01 2003 .. Fri Aug 15 2003 ------------------------------------------------------------------------------ </schnapp> ein isdnrep -i zeigt gar nix an.. Wenn ich die Datei /var/log/isdn.log aber nach eingegangenen Anrufen durchgreppe, dann finde ich sie auch, das logging scheint also stattzufinden.. Ich habe das gleiche auf einer SuSE 8.2-Installation versucht (mit isdnrep -a -f /file/von/anderem/server/isdn.log) ->genau das gleiche.. Woran kann das liegen? Wenn ich mir /var/log/messages anschaue kriege ich bei eingehenden Anrufen neben den üblichen Informationen immer das hier: <schnipp> Aug 15 14:36:14 faxserver isdnlog: Aug 15 14:36:14 * tei 0 calling +49 711/555, Stuttgart with +49 711/xxxxxx743, Stuttgart UNKNOWN ELEMENT 32: 80 [ ], length=1 -- complete frame ignored! <schnapp> Hat das vielleicht was damit zu tun? Merci, Klaus. -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
* Klaus Heske
ich habe ein Problem mit isdnrep und eingehenden Anrufen und habe in den Archiven dazu leider nichts gefunden.
Konfiguration: SuSE 8.1, zwei aktive B1-Karten am Anlagenanschluss, für HylaFAX konfiguriert. i4l-isdnlog-2002.9.8-4
Die Datei /var/log/isdn.log ist prächtig mit mannigfaltigen Daten gefüllt.
Mein Problem ist, dass ich keinerlei Informationen zu den eingehenden Anrufen erhalte, wenn ich isdnrep -a ausführe. [...] Wenn ich die Datei /var/log/isdn.log aber nach eingegangenen Anrufen durchgreppe, dann finde ich sie auch, das logging scheint also stattzufinden..
Zeig mal einige dieser Einträge, die Rufnummern (Felder 2 und 3) können dabei unkenntlich gemacht sein, nach Möglichkeit sollte aber die Ziffernzahl unverändert bleiben. Eigene Rufnumern dabei bitte markieren. So sollte sich die Fehlerquelle (isdnlog oder isdnrep) bestimmen lassen. Beim Logging der ausgehenden Anrufe treten keine Fehler auf?
Wenn ich mir /var/log/messages anschaue kriege ich bei eingehenden Anrufen neben den üblichen Informationen immer das hier:
<schnipp> Aug 15 14:36:14 faxserver isdnlog: Aug 15 14:36:14 * tei 0 calling +49 711/555, Stuttgart with +49 711/xxxxxx743, Stuttgart UNKNOWN ELEMENT 32: 80 [ ], length=1 -- complete frame ignored! <schnapp>
Hat das vielleicht was damit zu tun?
Das ist gut möglich. Wenn isdnlog beim Verarbeiten einer D-Kanal-Schicht-3-Nachricht auf ein unbekanntes Informationselement stößt, bricht er die Verarbeitung dieser Nachricht ab, mit der Folge dass evtl. weitere Informationselemente nicht mehr ausgewertet werden. Ein Informationselement mit dieser Nummer (hexadezimal 32) kennt übrigens auch der Webdecoder (http://www.engelschall.com/~martin/webdecoder/webdecoder.cgi) nicht. Was mich an der obigen isdnlog-Meldung aber verwundert ist die Tatsache, dass isdnlog hier das Ausgabeformat für gehende Rufe verwendet. In diesem Zusammenhang wäre der Kontext dieser Meldung interessant, wie lauten die vorhergehenden und nachfolgenden Meldung von isdnlog? 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 *
* Klaus Heske
ich habe ein Problem mit isdnrep und eingehenden Anrufen und habe in den Archiven dazu leider nichts gefunden. [...] Wenn ich die Datei /var/log/isdn.log aber nach eingegangenen Anrufen durchgreppe, dann finde ich sie auch, das logging scheint also stattzufinden..
Ich habe das gleiche auf einer SuSE 8.2-Installation versucht (mit isdnrep -a -f /file/von/anderem/server/isdn.log) ->genau das gleiche..
Das Problem ist mit dem neuen isdnlog-4.66 behoben, welchen ich vor kurzem ins CVS bei isdn4linux.de eingepflegt habe. Ursache war der Betrieb der AVM B1 Karten an einem Anlangenanschluß hinter einer Telefonanlage. Beim Anlagenschluß (Punkt-zu-Punkt) ist die TEI auf 0 festgesetzt, so daß der Ansatz von isdnlog, eine eingehende Verbindung an der Broadcast-TEI 127 zu erkennen, hier nicht funktioniert. Der neue isdnlog bestimmt bei einer AVM B1 Karte (mit D2 Trace) die Richtung anhand der Ursprungsseite der Call Reference. In der vorliegenden Konfiguration ist es empfehlenswert in /etc/isdn/isdn.conf unter AREACODE nicht nur die Vorwahl sondern dahinter auch die Kopfrufnummer der Telefonanlage einzutragen, um vollständige eigene Rufnummern in der isdn.log zu erhalten.
Wenn ich mir /var/log/messages anschaue kriege ich bei eingehenden Anrufen neben den üblichen Informationen immer das hier:
<schnipp> Aug 15 14:36:14 faxserver isdnlog: Aug 15 14:36:14 * tei 0 calling +49 711/555, Stuttgart with +49 711/xxxxxx743, Stuttgart UNKNOWN ELEMENT 32: 80 [ ], length=1 -- complete frame ignored! <schnapp>
Diese Meldung hat nichts mit dem eigentlichen Problem zu tun. Wie hier in letzter Zeit bereits mehrfach zu lesen war, sendet die Telefonalage in einer D-Kanal-Nachricht ein unbekanntes Informationselement, dass isdnlog bislang zu dieser Ausgabe veranlasste. Der neue isdnlog unterstützt Codeset-Umschaltungen und sollte dies nur noch für unbekannte Informationselemente im durch ITU und ETSI genormten Codeset 0 tun und unbekannte Informationselemente in anderen Codesets stillschweigend ignorieren. Das zitierte Informationselement 0x32 im Codeset 5 entstammt übrigens einer Norm für private Telefonnetze (u. a. ECMA-143) und gibt die "Party Category" an, die hier unbekannt ist. Andere mögliche Werte wären Nebenstelle, Operator oder Notruf. 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 (3)
-
Klaus Heske
-
Tobias Becker
-
Tobias Becker