Asterisk bleibt beim starten bei chan_zap.so hängen

Ber5erker

Mitglied
Mitglied seit
6 Apr 2004
Beiträge
305
Punkte für Reaktionen
0
Punkte
16
So, meine ersten ISDN-Gehversuche - und schon gescheitert:

Debian mit Kernel 2.6.8, Arowana 128K ISDN (HFC), NTBA, ISDN-Telefon
ISDN-Karte im NT-Mode

Von Junghanns das bri-stuff-0.1.0-RC4a.tar.gz geladen, udev um die Einträge erweitert, ./install.sh, Konfigs angepasst, alles soweit ok.
Starte ich jetzt Asterisk bleibt er an folgender Stelle einfach hängen und wiederholt alle paar Sekunden seine NOTICE-Meldung:

asterisk -vvvvc
Code:
 [chan_zap.so] => (Zapata Telephony w/PRI)
  == Parsing '/etc/asterisk/zapata.conf': Found
    -- Registered channel 1, PRI Signalling signalling
    -- Registered channel 2, PRI Signalling signalling
    -- Automatically generated pseudo channel
Sep 10 05:30:45 NOTICE[1090182064]: pbx.c:1312 pbx_extension_helper: Cannot find extension context 'default'

ztcfg -vv
Code:
Zaptel Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)

Channel map:

Channel 01: Individual Clear channel (Default) (Slaves: 01)
Channel 02: Individual Clear channel (Default) (Slaves: 02)
Channel 03: D-channel (Default) (Slaves: 03)

3 channels configured.

Einzige Fehler bekomme ich beim Einbinden der Treiber - das Device, worüber er meckert, ist von udevd aber angelegt worden:

make loadlinux26NT
Code:
make -C /usr/src/linux-2.6 SUBDIRS=/usr/src/bri-stuff.0.1.0-RC4a/zaphfc modules
make[1]: Entering directory `/usr/src/kernel-headers-2.6.8-1-k7'
  Building modules, stage 2.
  MODPOST
*** Warning: "zt_register" [/usr/src/bri-stuff.0.1.0-RC4a/zaphfc/zaphfc.ko] undefined!
*** Warning: "zt_transmit" [/usr/src/bri-stuff.0.1.0-RC4a/zaphfc/zaphfc.ko] undefined!
*** Warning: "zt_receive" [/usr/src/bri-stuff.0.1.0-RC4a/zaphfc/zaphfc.ko] undefined!
*** Warning: "zt_ec_chunk" [/usr/src/bri-stuff.0.1.0-RC4a/zaphfc/zaphfc.ko] undefined!
*** Warning: "zt_unregister" [/usr/src/bri-stuff.0.1.0-RC4a/zaphfc/zaphfc.ko] undefined!
make[1]: Leaving directory `/usr/src/kernel-headers-2.6.8-1-k7'
modprobe zaptel
insmod ./zaphfc.ko modes=1
ztcfg -v

Zaptel Configuration
======================

SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)

3 channels configured.

Notice: Configuration file is /etc/zaptel.conf
line 8: Unable to open master device '/dev/zap/ctl'

<verzweifel>
 
Soweit ich rausgefunden habe liest Asterisk die extensions.conf nicht (mehr) ein, sobald chan_zap.so mit geladen wird.

Wenn ich Asterisk im Hintergrund starte kann ich mich über asterisk -rvvvc connecten. Gebe ich ein show dialplan bekomme ich lediglich den Dialplan von extras.conf (oder wie die nun auch heißt) ausgegeben.
 
Ok, auch unter Kernel 2.4.27 bleibt Asterisk beim Versuch chan_zap.so zu laden hängen.

Versuche ich das Modul nachzuladen kommt folgendes:

Code:
*CLI> load chan_zap.so
 Loaded /usr/lib/asterisk/modules/chan_zap.so => (Zapata Telephony w/PRI)
  == Parsing '/etc/asterisk/zapata.conf': Found
    -- Registered channel 1, PRI Signalling signalling
    -- Registered channel 2, PRI Signalling signalling
    -- Automatically generated pseudo channel

Beginning asterisk shutdown....
Executing last minute cleanups
  == Destroying any remaining musiconhold processes
Asterisk cleanly ending (2).
 
Das hatte ich auch schon!
Probier mal "modprobe zaptel" und "modprobe zaphfc modes=1" in der Konsole, vielleicht hilft das?
 
Nein, soweit war ich auch schon. Habe jetzt bri-stuff-0.0.2 draufgedübelt - jetzt funzt es (mit Kernel 2.4.27). Nur das ISDN-Telefon will noch nichts von einer Leitung wissen :-/
Wie kann man eigentlich prüfen, ob am NTBA irgendeine Verbindung steht bzw. ob das ganze überhaupt hingehauen hat?
 
Neueste BRIstuff auch ?
 
Kannst Du mal zaptel.conf und zapata.conf posten. Und das sollte auch mit Debian Sarge und 2.6 Kernel laufen.


Raffi
 
Habs jetzt alles unter Kernel 2.4 laufen und klappt super.

Die beiden .conf sind Standart, wie sie auch beim bri-stuff/zaphfc beiliegen.

Gruß Seb.
--
Standart mit "t" oder mit "d"? - Oje, diese Deutschkenntnisse...
 
Witzig: auch unter Kernel 2.4 bleibt bri-stuff-0.1.0-RC4a beim starten an folgendem Punkt hängen:

Code:
 [chan_zap.so] => (Zapata Telephony w/PRI)
  == Parsing '/etc/asterisk/zapata.conf': Found
    -- Registered channel 1, PRI Signalling signalling
    -- Registered channel 2, PRI Signalling signalling
    -- Automatically generated pseudo channel

Was macht denn dieser "pseudo channel" eigentlich?

bri-stuff-0.0.2 funzt dagegen super.
 
das gleiche problem habe ich auch. betreibe debian sarge mit kernel 2.4.27.

bristuff 0.0.2 geht ohne probleme. Mit allen neueren 0.1.0-RC4a, bzw. eigentlich alle 0.1.0, bleibt asterisk beim starten hängen.

falls jemand die ursache dieses problems kennt wäre ich sehr dankbar.

gruß,
kunze
 
Nach einer Neuinstallation von Debian Sarge mit Kernel 2.4.27 ließ sich alles mit bri-stuff-0.1.0-RC4a fehlerfrei kompilieren.

Anbei mal meine Paketliste (mittels "dpkg -l"):
 

Anhänge

  • paketliste.txt
    16.5 KB · Aufrufe: 10
deine zapata.conf datei wäre mal interessant.
/ switch * topic
ist sarge überhaupt schon stable??
 
zapata.conf:
Code:
[channels]
language=de
musiconhold = default

nationalprefix = 0
internationalprefix = 00

switchtype = euroisdn

; p2mp TE mode
;signalling = bri_cpe_ptmp
; p2p TE mode
;signalling = bri_cpe
; p2mp NT mode
signalling = bri_net_ptmp
; p2p NT mode
;signalling = bri_net

pridialplan = local
prilocaldialplan = local
echocancel = yes
echocancelwhenbridged=no
echotraining=no
usecallerid = yes
usecallingpres = yes
overlapdial =yes
immediate = no
context = default
group = 1
channel => 1-2
 
Ich habe das gleiche Problem bei Laden der chan_zap.o.
Getestet mit bristuff-0.1.0-RC4a und bristuff-0.2.0-rc2a und Kernel 2.4.20.

Ich habe dann asterisk mit strace gestartet.

Hier die Ausgabe von asterisk

Code:
[chan_zap.so] => (Zapata Telephony w/PRI)
  == Parsing '/etc/asterisk/zapata.conf': Found
Nov 14 21:47:55 WARNING[1024]: chan_zap.c:10343 setup_zap: Ignoring setcallerid
    -- Registered channel 1, PRI Signalling signalling
    -- Registered channel 2, PRI Signalling signalling
    -- Registered channel 4, PRI Signalling signalling
    -- Registered channel 5, PRI Signalling signalling
    -- Automatically generated pseudo channel

und die ensprechende Sycalls an der Stelle des hängen bleibens:
Code:
pen("/dev/zap/channel", O_RDWR)        = 26
ioctl(26, 0x40044a26, 0xbffff57c)       = 0
ioctl(26, 0x80844a05, 0xbffff610)       = 0
ioctl(26, 0xc0704a0a, 0xbffff580)       = 0
ioctl(26, 0x40184a1b, 0xbffff5f0)       = 0
brk(0x811d000)                          = 0x811d000
write(26, "\376\377\3\17&\347\6\377\0\0", 10) = 10
write(26, "\376\377\3\17E\325\6\201\0\0", 10) = 10
write(26, "\376\377\3\17CT\6\203\0\0", 10) = 10
write(26, "\376\377\3\17\227y\6\205\0\0", 10) = 10
write(26, "\376\377\3\17\377\215\6\207\0\0", 10) = 10
write(26, "\376\377\3\17i\305\6\211\0\0", 10) = 10
write(26, "\376\377\3\0173\324\6\213\0\0", 10) = 10
write(26, "\376\377\3\17\333 \6\215\0\0", 10) = 10
write(26, "\376\377\3\17fS\6\217\0\0", 10) = 10
write(26, "\376\377\3\17\372\4\6\221\0\0", 10) = 10
write(26, "\376\377\3\17\333^\6\223\0\0", 10) = 10
write(26, "\376\377\3\17\371\252\6\225\0\0", 10) = 10
write(26, "\376\377\3\17P\226\6\227\0\0", 10) = 10
write(26, "\376\377\3\17\331F\6\231\0\0", 10) = 10
write(26, "\376\377\3\17\276?\6\233\0\0", 10) = 10
write(26, "\376\377\3\17\255\35\6\235\0\0", 10) = 10
write(26, "\376\377\3\17Wg\6\237\0\0", 10

Es sieht so aus, als ob asterisk beim Schreiben auf /dev/zap/channel auf den Treiber wartet. Das Öffnen funktioniert noch, einige ioctls auch ,und dann ist nach 160 Bytes + den letzten write Schluss.

Hat jemand eine Idee?
 
> Versuche ich das Modul nachzuladen kommt folgendes:

*CLI> load chan_zap.so
Loaded /usr/lib/asterisk/modules/chan_zap.so => (Zapata Telephony w/PRI)
== Parsing '/etc/asterisk/zapata.conf': Found
-- Registered channel 1, PRI Signalling signalling
-- Registered channel 2, PRI Signalling signalling
-- Automatically generated pseudo channel

Beginning asterisk shutdown....
Executing last minute cleanups
== Destroying any remaining musiconhold processes
Asterisk cleanly ending (2).

Bei mir kommt das neuerdings beim Verlassen:


*CLI> stop now
Beginning asterisk shutdown....
Executing last minute cleanups
== Destroying any remaining musiconhold processes
Asterisk cleanly ending (0).



Muss dann immer reboot machen..ist doch ein wenig.. schlecht.

Debian 2.6.8-1-386


modprobe zaptel
FATAL: Error inserting zaptel (/lib/modules/2.6.8-1-386/misc/zaptel.ko): Invalid module format
 
Bei mir ist der zaphfc-Treiber extrem instabil und auch ich komme nur nach einem Reboot und "make loadNT" wieder zu einem Freizeichen. Führe ich dann nochmal einen ztcfg aus war es das wieder mit dem Freizeichen.

Hast du einen load-Eintrag für chan_zap.so in der modules.conf?
Ist bei mir nicht nötig und führt sogar zu Problemen. Scheinbar wird der zwingend geladen, daher taucht chan_zap garnicht in der modules.conf auf.
Welche bristuff-Version verwendest du?
 
> Hast du einen load-Eintrag für chan_zap.so in der modules.conf?

Nein.


> Welche bristuff-Version verwendest du?

Habe Anfangs versucht, alles aus bristuff-0.2.0-rc2b zu bauen, aber als ich dann gesehen habe, das es Asterisk schon als 1.0.3 gibt, habe ich ich libpri, zaptel, asterisk aus dem stable CVS geholt und davon gebaut.

Wo kann man sich jetzt die verwendete bristuff-Version anzeigen lassen?

Asterisk CVS-v1-0-12/30/04-23:57:37
 
Soweit ich das beurteilen kann musst Du, um mit der HFC zu arbeiten mit bristuff-gepatchten versionen arbeiten. Die neuste bristuff verwendet bereits die aktuellsten asterisk/libpri/zaptel 1.0.3.

http://83.137.99.170/jn/relaunch/asterisk/downloads/bristuff-0.2.0-RC3.tar.gz

Kompilier alles nochmal aus dem entpackten bristuff mit ./install.sh
Deine Konfigurationsdateien bleiben dabei erhalten, da "make smaples" auskommentiert ist. Vielleicht ist damit Dein Problem bereits gelöst.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.