Frage : Kein Wählton am internen S0

[jui]

@Schorsch

Danke für das Feedback, ich hatte die Doku aus meiner "Erinnerung" zusammengebaut und Du hast die nötigen fehlenden Informationen ja nun erkannt und ich kann das korrigieren. Vielleicht sollte ich AVM-Karten mit CAPI garnicht mit berücksichtigen? Obwohl, kann man eigentlich ruhig drinlassen.

Zu Deiner Fehlermeldung: Ich hatte das auch, kann nicht mehr genau sagen woran es lag, werde aber nochmal recherchieren, ist ne reine Konfigurationssache gewesen, das weiss ich noch. Kernel ist bei mir übrigens exakt der Gleiche. Du bist aber nur noch einen Steiwurf von der funktionierenden Lösung entfernt Ich poste mal meine zapata.conf

general]

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

[channels]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;NT-Card external s0
switchtype = euroisdn
signalling = bri_net_ptmp
pridialplan = local
prilocaldialplan = local
echocancel = yes
overlapdial = no
echocancelwhenbridged=no
echotraining=no
immediate = no
usecallerid = yes
group = 1
context = isdn2out
channel => 1-2
usecallingpres=yes
nationalprefix = 0
internationalprefix = 00

Der context-Eintrag dort verweist bei Dir auch auf einen existierenden context, ja?

Und hier die zaptel.conf aus /etc

loadzone=nl
defaultzone=nl
span=1,1,3,ccs,ami
bchan=1-2
dchan=3

Ausserdem empfehle ich einen Patch für die zaphfc-Unterstützung in Asterisk einzupflegen, damit ist zaphfc bei mir dann absolut stabil und ein "make unload" lässt das System nicht mehr einfrieren. Werde das in der Anleitung noch ergänzen.

Ergänzung: prüfe mal mit "lspci", dass die HFC-Karte sauber erkannt wurde und dann verwende mal 1:1 meine zaptel.conf. Achte darauf, dass nicht die zaptel.conf aus dem /zaphfc-Verzeichnis (bristuff) verwendet wird, sondern diejenige in /etc. Die muss also stimmen!!!! Viel Glück!
Habe Deine Korrekturen schon in meine Anleitung eingepflegt. Insgesamt scheint die Anleitung dann aber zu passen, oder? Hoffe Sie hat Dir geholfen.

 

[schorsch]

Hallo, die Anleitung passt jetzt hundertprozentig, aber der Fehler bleibt der gleiche.
Den Patch habe ich durchgeführt und danach nocheinmal ./install.sh laufen lassen, was ohne Probleme ging. Deine zaptel.conf habe ich 1:1 übernommen, sie war aber bereits mit meiner (bis auf Leerzeilen und die können's ja wohl nicht sein) identisch. Testhalber habe ich auch Deine zapata.conf übernommen und den context auf default gesetzt. Dieser context existiert nachweislich in meiner extensions.conf. Die zaptel.conf und zapata.conf aus dem /zaphfc Verzeichnis habe ich vorsichtshalber gelöscht. Trotzdem: make loadNT bringt den gleichen Fehler und make unload friert nach wie vor das System ein.
Mit lspci -v erhalte ich (bevor ich make loadNT mache):

0000:02:05.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
Subsystem: Cologne Chip Designs GmbH ISDN Board
Flags: bus master, medium devsel, latency 16, IRQ 11
I/O ports at cc00
Memory at dfefff00 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 1

und danach das gleiche nur das bei den I/O ports steht:

I/O ports at cc00 [disabled]

Kann das was bedeuten?
Außerdem verwendet bei mir fast alles IRQ 11, also insb. die Netzwerkkarte und noch andere Dinge. Kann das einen Konflikt ergeben? Ich habe bereits im Bios-Setup probiert, zwangsweise einen IRQ zuzuweisen, aber anscheinend werden meine Angaben aus dem Bios Setup ignoriert. Kann/muss ich das unter Linux noch extra einstellen?
Schlussendlich: Man kann bei den Netzwerkgeräten (dort wo man die ISDN-Karte konfiguriert) das Kästchen ISDN-Protokollierung aktivieren. Wie ist das bei Dir? aktiv oder inaktiv? Manchmal liegt es ja schon an Kleinigkeiten...

Viele Grüße
schorsch

 

[jui]

@schorsch

Oh weh, jetzt wird es ja echt kompliziert ...ich hatte diese Fehlermeldung auch mal, aber es kann nichts grosses gewesen sein. IRQ-Sharing habe ich auch, das kann auf die Sprachqualität einen Einfluss haben (Knacken), aber soweit bist du ja noch nicht. Der ztcfg -v bringt also bei dir weiterhin den Fehler. Auch wundert mich, dass ein make unlload bei Dir noch das System einfriert, das war bei mir weg, muss ich aber nochmal testen. Vielleicht solltest Du Dein Problem mit der Fehlermeldung hier nochmal in einen extra Thread packen damit mehr Leute aufmerksam werden und der Titel dazu passt. Hatte es bei Dir mit den asterisk-RPM eigentlich funktioniert? Oder bist du da garnicht so weit gekommen?

Lies mal das hier (hoffe Englisch ist kein Problem, sonst melde dich nochmal), vielleicht hilft es was. Hier wird vorgeschlagen in zapata.conf die Reihenfolge anzupassen und den dummy nicht zu laden. Nehme aber an, dass weder das Eine noch das andere bei Dir zutrifft (Du hattest ja auch mal meine zapata.conf verwendet)
http://lists.digium.com/pipermail/asterisk-users/2004-December/078773.html

Ergänzung: mit lspci -v habe ich auch die Zeile mit den i/o ports disabled.

Aber wenn du schreibst "darunter nochmal das Gleiche" bedeutet das Du hast 2 HFC-Karten im Rechner? Dann muss man nämlich etwas anders vorgehen wenn man eine davon im TE und die Andere im NT Mode haben will.


Gruß,

Jui

 

[schorsch]

Hallo!
Na, ich werde selbst natürlich noch weiterprobieren. Irgendwie muss es ja doch eine Lösung geben.
Also mit den RPMs unter Suse 9.2 lief Asterisk problemlos an, ein SIP-Telefon konnte ich auch anschließen und die Demorufnummern erreichen. Nur, dass eben die ganze Geschichte mit udev und damit ISDN nicht funktionierte.
Die Angabe "und danach das gleiche" bezog sich auf das Ausführen von make loadNT. Ich habe nur eine HFC-Karte im Rechner. D. h.: bevor ich make loadNT mache, erhalte ich:
I/O ports at cc00
und nachdem ich make loadNT ausgeführt habe, erhalte ich
I/O ports at cc00 [disabled]
Was mich also wunderte ist, dass nachdem ich make loadNT durchgeführt habe, die Ports plötzlich disabled waren.
Auf die digium Mailing Liste werde ich auch schauen. Danke.
Mir ist noch nicht klar, wie all die Konfigurationsdateien ineinander greifen. Ich kann mir aber kaum vorstellen, dass make loadNT ein völlig durchkonfiguriertes Asterisk braucht, um rund durchzulaufen. Nichtsdestotrotz: ich habe auch ein richtig funktionierendes Asterisk verwendet (ohne make loadNT) und dann Asterisk gestoppt, make loadNT eingegeben und danach trat wieder der Fehler auf. Äußerst merkwürdig...

Viele Grüße
schorsch

 

[schorsch]

Noch ein Nachtrag:
Es ist wirklich äußerst merkwürdig, denn die Karte scheint korrekt eingebunden zu werden. Hier ein Auszug aus meinen /var/log/messages direkt nach dem Ausführen von make loadNT:

Jan  6 20:48:43 asterisk kernel: module zaptel unsupported by SUSE/Novell, tainting kernel.
Jan  6 20:48:43 asterisk kernel: Zapata Telephony Interface Registered on major 196
Jan  6 20:48:43 asterisk kernel: zaphfc: no version for "struct_module" found: kernel tainted.
Jan  6 20:48:43 asterisk kernel: module zaphfc unsupported by SUSE/Novell, tainting kernel.
Jan  6 20:48:43 asterisk kernel: ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 11 (level, low) -> IRQ 11
Jan  6 20:48:43 asterisk kernel: zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xe12baf00 fifo 0xd0078000(0x10078000)
 IRQ 11 HZ 1000
Jan  6 20:48:43 asterisk kernel: zaphfc: Card 0 configured for NT mode
Jan  6 20:48:44 asterisk kernel: zaphfc: 1 hfc-pci card(s) in this box.

Das ganze mit "unsupported" zu Beginn ist ja wohl nicht weiter schlimm und gerade die beiden letzten Zeilen deuten doch wohl an, dass alles in Ordnung ist. Ich muss das wohl wirklich mal in einen neuen Thread packen.

Trotzdem, falls noch jemand Rat weiß, ich hab' langsam auch keine Idee mehr, was ich noch verändern könnte. (Sogar die Karte - habe gleich mehrere identische Modelle gekauft - und den PCI-Slot habe ich schon ausgetauscht. Der Fehler bleibt der gleiche.)
Vielen Dank aber für die bisherige Mühe!
schorsch

 

[Brad]

Die Fehlermeldung

ZT_CHANCONFIG failed on channel 2: Invalid argument (22)
Did you forget that FXS interfaces are configured with FXO signalling
and that FXO interfaces use FXS signalling?
make: *** [loadlinux26NT-debug] Fehler 1

hatte ich auch. Ursache waren bei mir Original-SuSE-Kernelmodule (obwohl ich kein *-RPM installiert hatte). Abhilfe:

cd /lib/modules/`uname -r`/extra/
mv zaphfc.ko zaphfc.ko.off
mv zaptel.ko zaptel.ko.off

Damit werden die Original-Module umbenannt und machen Platz für die Bristuff-Module.

 

[MrBean]

Super Tipp!
Einfach diese beiden Dateien umbenennen und vom Verzeichnis */bristuff-*/zaphfc/zaphfc.ko & */bristuff-*/zaptel*/zaptel.ko nach /lib/modules/´uname -r´/extra kopieren.

Danke

 

[Karl23]

Super Tipp!
Einfach diese beiden Dateien umbenennen und vom Verzeichnis */bristuff-*/zaphfc/zaphfc.ko & */bristuff-*/zaptel*/zaptel.ko nach /lib/modules/´uname -r´/extra kopieren.

Danke

Richtig die SuSE module durch die eigenen ersetzen, aber
depmod -a
nicht vergessen