Speicherzugriffsfehler bei R-Taste

[jaw]

Am Asterisk hängt eine TK-Anlage per ISDN (Anlagenkopplung). Wenn ich dort automatische Amtsholung einstelle, und bei einem Telefon den Hörer abnehme, fällt die TK-Anlage beim Asterisk in die s-Extension (wieso eigentlich? ich dachte, die würde nur bei Analogleitungen verwendet? Die Anrufernummer sollte doch über die MSNs bekannt sein?). Benutzt ich statt der Amtsholung eine "Raustelefonier-Taste", fällt die TK-Anlage erst nach der Amtstaste plus einer weiteren Ziffer in die s-Extension.

Drücke ich in der s-Extension die R-Taste am Telefon, beendet sich der Asterisk mit einem Speicherzugriffsfehler. Keine Einträge im CLI oder in den Logfiles.
Interne Gespräche sind mit automatischer Amtsholung daher nicht möglich. Die werden aber unbedingt benötigt, weil da z.B. auch die Türsprechanlage dran hängt.
Externe Gespräche funktionieren genau so wie sie sollen - Höhrer abnehmen, Nummer wählen (ohne Amtsvorwahl etc) und telefonieren, genau so, wie ich es gerne hätte).
Gibts da irgendwie einen Trick, wie man das trotzdem hin bekommt?
Zur Amtsholung müssen zwei '0'en vorgewählt werden, was ich irgendwie sehr unschön finde.
Die erste '0' 'holt' die Amtsleitung der TK-Anlage (Amtston), die 2. '0' dann die s-Extension vom Asterisk (hier geht auch jede beliebige andere Ziffer, das scheint mir eine Macke der TK-Anlage zu sein). Erst dann können Nummern gewählt werden.
Da die Telefonanlage nach der 1. '0' schon einen Amtston generiert, ist das sehr verwirrend, denn wenn man dann eine Nummer wählt, wird die erste Ziffer nicht an den Asterisk weiter gereicht. Das macht das ganze mit manueller Amtsholung leider ziemlich unbrauchbar.

die s-Extension spielt per background noch mal einen 'Amtston' ab, aber das ist trotzdem sehr unschön so.

die Zaptel-Module sind Version 1.2.11,
der Asterisk ist Bristuff-Version 1.2.13,
Die TK-Anlage ist eine T-Concept XL 520, welche Firmware kann ich leider nicht sagen.
Die ISDN Karte im Asterisk ist eine HFC-PCI.
Kernel: 2.6.19 (selber compiliert)
Basissystem: Debian stable

 

[mindflow]

Hi, könntest du den Fehler etwas genauer beschreiben? Ich habe nämlich so ein ähnlichen Fehler.

Im /tmp verzeichnis gibt es nach jedem Asterisk-Crash einen Dump. Damit kannst du genau feststellen wann und mit welchem Fehler die Asterisk crasht.
Hast du das Full-Log aktiviert?

Ich habe vor jedem Crash immer genau die Meldung

Mar 20 16:14:19 DEBUG[27485] chan_zap.c: Received REMOTE_HOLD notification on NETWORK channel. Starting MoH

Im dump steht immer

Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7b99acb in local_ast_moh_start (chan=0x0, class=0x0)
    at ../include/asterisk/strings.h:35
35              return (!s || (*s == '\0'));

Bis jetzt habe ich noch nicht herausgefunden was dieses Problem verursacht.

Viele Grüße

Florian

 

[jaw]

ich hab das full_log aktiviert, aber leider erscheint dort nichts mehr vom Crash - ich hab leider aktuell noch überhaupt keinen Hinweis, wo ich mit der Suche anfangen soll.

unter /tmp/ gibts leider auch kein Dump. :-(

Muss erst mal noch weiter suchen, so bräuchte ich dringend eine Kristallkugel.

 

[jaw]

leider finde ich keine Möglichkeit, an Infos ran zu kommen. Es scheint an einem Buffer Overflow im zaphfc-Modul zu liegen, oder zumindest damit zusammen zu hängen. Wenn ich das Modul aber aus den aktuellen Sourcen neu übersetze, dann kann ich es leider nicht laden - obwohl ich alle Kernelquellen etc. habe (Ladefehler wegen undefinierten Symbolen). Das laufende Modul hab ich ja auf der selben Maschine compiliert, und alle Module von denen zaphfc abhängt mit neu geladen.
Leider alles noch sehr undurchsichtig :-(

 

[fsiggi]

Siehe auch:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448171

 

[mindflow]

Hast du schon mal Probiert ob es mit Bristuff-0.4.0 auch auftritt?
Ich habe ein ähnliches Problem, und laut Junghanns soll es in 0.3.0-PRE-1y-r gelöst sein (kommt ca. diese Woche) und bei 0.4.0 gar nicht erst auftreten

Gruß

Florian