junghanns quadBRI will nicht anspringen

[kremin]

Hallo Forum,

ich versuche jetzt schon seit 6 Stunden eine junghanns quadBRI ans laufen zu bekommen, aber ohne Erfolg. Ich habe folgendes vor:

2 x Anlagenanschlüsse <-> quadBRI

Das einzige was passiert, ist das ich solche Meldungen auf der Konsole und in die Logs kriege:
qozap: CRC error for HDLC frame on card 1 (cardID 255) S/T port 1

Ich bin wie folgt vorgegangen:

1. Port 1 und 2 der junghanns Karte auf "TE" jumpern
2. modprobe zaptel
3. insmod /lib/modules/2.6.8-2-386/zaptel/qozap.ko ports=12
4. Im syslog sehe ich danach:

kernel: qozap: S/T ports: 4 [ TE TE NT NT ]
kernel: qozap: 1 multiBRI card(s) in this box, 4 BRI ports total.

5. Meine zapata.conf

loadzone=nl
defaultzone=nl
span=1,1,3,ccs,ami
span=2,2,3,ccs,ami

bchan=1,2
dchan=3
bchan=4,5
dchan=6

6. Und meine zapata.conf

[channels]
language=de
switchtype = euroisdn

signalling = bri_cpe

pridialplan = local
prilocaldialplan = dynamic
nationalprefix = 0
internationalprefix = 00

priindication = passthrough

echocancel = yes

context=incoming
group = 1
channel => 1-2
group = 2
channel => 4-5

7. Die Anlagenanschlüsse sind mit normalen Patchkabeln mit der quadBRI-karte verbunden.

Es geht kein LED an der quadBRI-Karte an. Das einzige was passiert sind diese ...

qozap: CRC error for HDLC frame on card 1 (cardID 255) S/T port 1

... Meldungen.

Dann dachte ich mir, ich probiere mal die kleine Variante gegen einen ISDN Mehrgeräteanschluss, aber da passiert genau das gleiche. Ich verstehe einfach nicht wo das Problem ist? :noidea:

Über Google findet man auch nicht gerade viel zu dem Thema.

Ich hoffe jemand kann mir helfen oder einen Tipp geben.

Gruss,
kremin

 

[speedy1980]

pri intense debug span 1

Schau mal ob das überhaupt was über die Leitung geht.

 

[clan]

Ist vermutlich 'ne dumme Frage. aber hast du mal 'ztcfg -v' gemacht?

 

[kremin]

pri intense debug span 1
Schau mal ob das überhaupt was über die Leitung geht.

Habe ich mal in der zapata.conf eingebaut. Ich sehe aber nirgendwo Meldungen?

Ist vermutlich 'ne dumme Frage. aber hast du mal 'ztcfg -v' gemacht?

Ja, habe ich gemacht:

phone:/etc/asterisk# ztcfg -v

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

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

12 channels configured.

 

[speedy1980]

Bitte auf der Asterisk-CLI:
pri intense debug span 1
Und dann einmal Kabel ab und wieder dran. Normalerweise sollte dann etwas auf der Leitung passieren. In der zapata.conf hat das nichts zu suchen. Sorry, dass ich nicht vorher aufgeklärt habe.

 

[kremin]

Bitte auf der Asterisk-CLI:
pri intense debug span 1

Hätte ich ja selbst drauf kommen müssen.

Ok. Hab es eingegeben und die beiden Kabel von den Anlagenanschlüssen zur quadBRI einmal gezogen und wieder eingesteckt. Das kam dabei raus:

Asterisk Ready.
*CLI>   == Primary D-Channel on span 2 up
  == Primary D-Channel on span 1 up
pri intense debug span 1
Enabled EXTENSIVE debugging on span 1
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 01 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter
-- Retrying poll with f-bit
Sending Receiver Ready (0)

> [ 00 01 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 02 01 7f ]

< Unnumbered frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
<   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
< 0 bytes of data
-- Got SABME from network peer.
Sending Unnumbered Acknowledgement

> [ 02 01 73 ]

> Unnumbered frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
>   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter
  == Primary D-Channel on span 1 up
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 01 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

< [ 00 01 01 01 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 000 P/F: 1
< 0 bytes of data
-- ACKing all packets from 0 to (but not including) 0
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter
T203 counter expired, sending RR and scheduling T203 again
Sending Receiver Ready (0)

> [ 00 01 01 01 ]

> Supervisory frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 000 P/F: 1
> 0 bytes of data
-- Restarting T203 counter

Ach ja, noch was zur Info: Ich nutze den Asterisk und den Zaptel-Treiber der bei Debian Sarge dabei ist. Also Asterisk 1.0.7 und Zaptel-Source 1.0.7

kremin

 

[speedy1980]

Welche Lämpchen leuchten an der Karte? Ich hab zumindest ähnliche Meldungen das letzte Mal bei einer E1 Karte gehabt, die den TE/NT Jumper falsch gesetzt hatte. Also noch mal alle Jumper überprüfen und testweise die beiden Anlagenanschlüsse mal an Port 3 und 4 stecken (die sind ja auf NT soweit ich es bei Dir sehe).

 

[kremin]

Welche Lämpchen leuchten an der Karte?

Überhaupt keine. Inwischen habe ich auch noch folgendes probiert:

1. Debian Etch ausprobiert. Da leuchten auch die Lampen, aber die CRC-Fehlermeldungen bleiben.

2. Ich habe nochmal Debian Sarge genommen und mich an diese Anleitung -> http://wiki.ip-phone-forum.de/software:asterisk:bristuff_unter_debian gehalten. Der einzige Unterschied war die Bristuff-Version. Anstelle der bristuff-0.2.0-RC8<b>j</b> habe ich die bristuff-0.2.0-RC8<b>s</b> genommen. Alles lief wie im wiki beschrieben, bis ich beim qozap-Modul das hier bekommen hab:

phone3:~# insmod /lib/modules/2.6.8-2-386/misc/qozap.ko ports=12
insmod: error inserting '/lib/modules/2.6.8-2-386/misc/qozap.ko': -1 Invalid module format

3. Dann habe ich nochmal Debian Sarge genommen und die wiki-Anleitung 1:1 durchgeführt (also auch bristuff-0.2.0-RC8<b>j</b>). Ergebnis wie bei Punkt2:

phone3:~# insmod /lib/modules/2.6.8-2-386/misc/qozap.ko ports=12
insmod: error inserting '/lib/modules/2.6.8-2-386/misc/qozap.ko': -1 Invalid module format

Ich verstehe einfach nicht mehr wo das Problem sein soll? :noidea:

 

[kremin]

Habe gerade nochmal ein frisches Debian aufgesetzt.

- Nach der Anleitung aus dem ip-phone-forum-wiki nochmal bristuff kompiliert.
- Reboot
- modprobe zaptel
- insmod qozap.ko ports=12
- zwei LEDs sind grün und zwei sind rot
- Auszug von 'dmesg':

qozap: no version for "zt_receive" found: kernel tainted.
ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 16 (level, low) -> IRQ 177
DIPS = 0xfe CID= 0x6
qozap: Junghanns.NET quadBRI (Version 2.0) card configured at io port 0xe800 IRQ 177 HZ 1000 CardID 6
qozap: S/T ports: 4 [ TE TE NT NT ]
qozap: Starting hardware watchdog.
qozap: 1 multiBRI card(s) in this box, 4 BRI ports total, bloop 0, pcmslave 0.
Registered tone zone 3 (Netherlands)
qozap: t3 timer expired for span 0
Zaptel: Master changed to ztqoz/2/2
qozap: t3 timer expired for span 1
Zaptel: Master changed to ztqoz/2/3
qozap: not re-activating layer1 span 0
qozap: not re-activating layer1 span 1
qozap: clearing alarms on span 0
Zaptel: Master changed to ztqoz/2/1
qozap: clearing alarms on span 1

Da macht mich jetzt das hier ...

qozap: no version for "zt_receive" found: kernel tainted.

... etwas stutzig.

 

[Overlus]

also ich hatte auch Probleme,aber nachdem du den Bristuff-<Version>-Treiber installiert hast,wechsel in den qozap-Ordner von Bristuff und tippe:
modprobe zaptel
insmod qozap.ko [bei Kernel 2.6(nichts dahinter, das musst du mit den Jumpern regeln)]
ztcfg
nun müssten die LED´s leuchten !!!
siehe auch: http://www.junghanns.net/downloads/users_guide.pdf

 

[bxjy]

Ich habe auch ähnliches Problem, nun meine ist dass die zweite Karte nicht richtig laufen will. In ersten Karte habe ich alle auf TE mode eingetellt und in zweite Karte habe ich drei davon auf TE Mode eingestellt und die letzte auf NT Mode. Die Lampe leuchten ,aber zwei davon rot und anderen Grün obwohl ich noch gar keine Kabel eingesteckt. Wenn ich die ISDN Kabel einsteckt , meldet in CLI immer “red alarm”
gibt es Grossmann hier zu helfen?

 

[Overlus]

Glaub den LED´s nicht, ich weiß auch nicht was die sollen,zeigen wohl nur an ob der Port auf NT(grün) oder TE(rot) ist,aber auch nicht so richtig. :noidea:
ISDN-Telefon hab ich auch noch nicht zum Laufen gebracht.WICHTIG ist wohl nur,kein Cross-Kabel zu benutzen und in nen NT-Port zu stecken.

 

[clan]

@kremin: Funktioniert denn jetzt was? Dein dmesg sieht jedenfalls gut aus, die Zeilen

qozap: clearing alarms on span 0
Zaptel: Master changed to ztqoz/2/1
qozap: clearing alarms on span 1

deuten darauf hin, daß die Leitungen oben sind. Sofern Kabel gesteckt sind sollten die zugehörigen LEDs grün sein. Die LEDs zeigen übrigens WIMRE den L1-Status an.

Gelegentliche CRC-Fehler haben wir auf unserer quadBRI hier auch, hält sich aber mit vielleich einem Dutzend am Tag in Grenzen. Das System ist übrigens ein Ubuntu Dapper.

Da macht mich jetzt das hier ...

qozap: no version for "zt_receive" found: kernel tainted.

... etwas stutzig.

Das hat nichts weiter zu bedeuten, der Kernel merkt, daß das Modul Extra kompiliert wurde.

Weiter oben hast du einen Auschnitt aus dem 'intense debug' gebracht, die sahen gut aus. Beim Ziehen der Leitung ist die Schicht 2 'runtergefallen und wurde nach dem Stecken wieder aufgebaut.

 

[kremin]

@clan: Nein es funktioniert noch immer nicht. Wenn ich asterisk gestartet habe, dann kamen ständig solche Meldungen:

Aug 22 23:42:01 NOTICE[2299]: PRI got event: Alarm (4) on Primary D-channel of span 1
Aug 22 23:42:01 WARNING[2299]: No D-channels available!  Using Primary channel 3 as D-channel anyway!
Aug 22 23:42:01 NOTICE[2299]: PRI got event: Alarm (4) on Primary D-channel of span 2
Aug 22 23:42:01 WARNING[2299]: No D-channels available!  Using Primary channel 6 as D-channel anyway!
Aug 22 23:42:01 WARNING[2299]: Detected alarm on channel 1: Red Alarm
Aug 22 23:42:01 WARNING[2299]: Unable to disable echo cancellation on channel 1
Aug 22 23:42:01 WARNING[2299]: Detected alarm on channel 2: Red Alarm
Aug 22 23:42:01 WARNING[2299]: Unable to disable echo cancellation on channel 2
Aug 22 23:42:01 WARNING[2299]: Detected alarm on channel 4: Red Alarm
Aug 22 23:42:01 WARNING[2299]: Unable to disable echo cancellation on channel 4
Aug 22 23:42:01 WARNING[2299]: Detected alarm on channel 5: Red Alarm
Aug 22 23:42:01 WARNING[2299]: Unable to disable echo cancellation on channel 5
Aug 22 23:42:01 NOTICE[2299]: Alarm cleared on channel 1
Aug 22 23:42:01 NOTICE[2299]: Alarm cleared on channel 2
Aug 22 23:42:01 NOTICE[2299]: Alarm cleared on channel 4
Aug 22 23:42:01 NOTICE[2299]: Alarm cleared on channel 5
Aug 22 23:42:01 NOTICE[2299]: PRI got event: No more alarm (5) on Primary D-channel of span 1
Aug 22 23:42:01 NOTICE[2299]: PRI got event: No more alarm (5) on Primary D-channel of span 2
Aug 22 23:42:01 WARNING[2299]: No D-channels available!  Using Primary channel 6 as D-channel anyway!
Aug 22 23:42:01 WARNING[2299]: No D-channels available!  Using Primary channel 3 as D-channel anyway!

Sofern Kabel gesteckt sind sollten die zugehörigen LEDs grün sein.

Ja das ist auch so ne Sache. Die LEDs waren über kreuz grün und rot. Also 1+3 grün und 2+4 waren rot, obwohl die Kabel auf Port 1 und 2 steckten.

Das hat nichts weiter zu bedeuten, der Kernel merkt, daß das Modul Extra kompiliert wurde.

Ah ... ok. Das zt_receive hatte mich nur irritiert.

Weiter oben hast du einen Auschnitt aus dem 'intense debug' gebracht, die sahen gut aus.

Das war noch mit der Debian Asterisk+zaptel Version. Da hatte ich noch diese CRC Fehler en masse. Das Problem ist ja jetzt, das ich irgendwie nichts auf CLI tippen kann, da nach dem start die ganze Konsole mit dem Alarm-Kram (weiter oben) zugemüllt wird.

Aber mal was anderes:

1. Kann mir mal jemand eine zaptel.conf und eine zapata.conf schicken wie er die für eine quadBRI erstellen würde, wo die ersten beiden Ports für zwei Anlagenanschlüsse sind und die anderen Ports für einen Bosch Integral10 TK-Anlage? Davon sieht man ja überall im Netz auch zig Varianten.

2. Das ich normale Patchkabel von den NTBAs zur quadBRI benutze ist ja Ok, oder?

3. Für die Bosch Integral10 müsste ich Cross-Kabel benutzen. Richtig?

Gruss,
kremin

 

[clan]

Teilt sich die Karte vielleicht Interrupts mit anderen geräten? Hast du dir schon mal /proc/interrupts angesehen?

1. Kann mir mal jemand eine zaptel.conf und eine zapata.conf schicken wie er die für eine quadBRI erstellen würde, wo die ersten beiden Ports für zwei Anlagenanschlüsse sind und die anderen Ports für einen Bosch Integral10 TK-Anlage? Davon sieht man ja überall im Netz auch zig Varianten.

Hier eine funktionierende zaptel.conf, span 1 und 2 gehören zu einem Anlagenanschluß, 3 ist ein Mehrgeräteanschluß, 4 ein interner S0. Die zaptel.conf sollte ohne Änderung auch bei dir funktionieren.

loadzone=nl
defaultzone=nl
# qozap span definitions
# most of the values should be bogus because we are not really zaptel
span=1,1,3,ccs,ami
span=2,2,3,ccs,ami
span=3,0,3,ccs,ami
span=4,0,3,ccs,ami


# channels BRI
bchan=1,2
dchan=3
bchan=4,5
dchan=6
bchan=7,8
dchan=9
bchan=10,11
dchan=12

Die zapata.conf braucht vermutlich ein paar Anpassungen beim dritten und vierten Span. Ich vermute, der Asterisk soll zwischen den bestehenden Anlagenanschluß und die Bosch gesetzt werden? Dann müssten Span 3 und 4 vermutlich 'signalling = bri_net' haben, ausserdem sollten sie in der gleichen Gruppe sein (ähnlich wie 1+2 unten):

[channels]
switchtype = euroisdn
language = de

usecallingpres = yes
usecallerid = yes
hidecallerid = no
echocancel = yes

;----------1+2ter S0----------------------------------

signalling = bri_cpe
nationalprefix = 0
internationalprefix = 00
context=externptp
pridialplan = local
priindication = inband
overlapdial = yes

group = 1

; S/T port 1
channel => 1-2

; S/T port 2
channel => 4-5

;----------3ter S0----------------------------------

signalling = bri_cpe_ptmp
nationalprefix = 0
internationalprefix = 00
context = externpmp
pridialplan = local
prilocaldialplan = local
priindication = inband
overlapdial = yes

group = 2

; S/T port 3
channel => 7-8

;----------4ter S0----------------------------------

signalling = bri_net_ptmp
nationalprefix = 0
internationalprefix = 00
pridialplan = local
prilocaldialplan = local
context = intern
priindication = inband
overlapdial = yes

group = 3

; S/T port 4
channel => 10-11

Damit landen eingehende Gespräche über den Anlagenanschluß im Kontext 'externptp', über den Mehrgeräteanschluß in 'externpmp', über die interne Leitung in 'intern'.

2. Das ich normale Patchkabel von den NTBAs zur quadBRI benutze ist ja Ok, oder?

Ja, sofern alle Adern verbunden sind. ISDN benutzt andere Pins als LAN, falls also nur vier Adern verbunden sind funktioniert das nicht.

3. Für die Bosch Integral10 müsste ich Cross-Kabel benutzen. Richtig?

Nein, ganz normale Patchkabel. Bei der quadBRI wird durch die Jumper auch die Steckerbelegung angepasst.

 

[kremin]

Teilt sich die Karte vielleicht Interrupts mit anderen geräten? Hast du dir schon mal /proc/interrupts angesehen?

Ja, habe ich schon gecheckt. Sieht ok aus:

phone:~# cat /proc/interrupts
           CPU0
  0:   17155475    IO-APIC-edge  timer
  9:          0   IO-APIC-level  acpi
 14:       1964    IO-APIC-edge  ide0
 15:         13    IO-APIC-edge  ide1
169:       5303   IO-APIC-level  eth0
177:          0   IO-APIC-level  qozap
NMI:          0
LOC:   17155146
ERR:          0
MIS:          0

 

[kremin]

Ich sag nur: Schande über mein Haupt!

Folgendes habe ich gerade festgestellt: Wenn man die Kernelmodule lädt, dann fangen die Fehlermeldungen an:

ug 24 20:45:43 phone3 kernel: qozap: not re-activating layer1 span 0
Aug 24 20:45:43 phone3 kernel: qozap: CRC error for HDLC frame on card 1 (cardID 6) S/T port 1
Aug 24 20:45:51 phone3 kernel: qozap: not re-activating layer1 span 1
Aug 24 20:45:51 phone3 kernel: qozap: CRC error for HDLC frame on card 1 (cardID 6) S/T port 2
Aug 24 20:45:54 phone3 kernel: qozap: not re-activating layer1 span 0
Aug 24 20:46:01 phone3 kernel: qozap: not re-activating layer1 span 1
Aug 24 20:46:01 phone3 kernel: qozap: CRC error for HDLC frame on card 1 (cardID 6) S/T port 2
Aug 24 20:46:04 phone3 kernel: qozap: not re-activating layer1 span 0
Aug 24 20:46:04 phone3 kernel: qozap: CRC error for HDLC frame on card 1 (cardID 6) S/T port 1
Aug 24 20:46:12 phone3 kernel: qozap: not re-activating layer1 span 1
Aug 24 20:46:12 phone3 kernel: qozap: CRC error for HDLC frame on card 1 (cardID 6) S/T port 2
Aug 24 20:46:15 phone3 kernel: qozap: CRC error for HDLC frame on card 1 (cardID 6) S/T port 1
Aug 24 20:46:15 phone3 kernel: qozap: not re-activating layer1 span 0
Aug 24 20:46:22 phone3 kernel: qozap: not re-activating layer1 span 1
Aug 24 20:46:22 phone3 kernel: qozap: CRC error for HDLC frame on card 1 (cardID 6) S/T port 2

Und das hat mich ja schon irritiert. Wenn man dann aber Asterisk startet, dann hören die Meldungen auf. Scheint wohl normal zu sein, oder?

Dann habe ich einfach mal ein Snom300 ins Netz gehangen. Snom300 und Asterisk zum raustelefonieren konfiguriert -> klappt!

Glaub den LED´s nicht, ich weiß auch nicht was die sollen,zeigen wohl nur an ob der Port auf NT(grün) oder TE(rot) ist,aber auch nicht so richtig.

@Overlus: Da hast du Recht. Was die anzeigen macht echt nicht so richtig Sinn.

@clan: Ich habe deine Configs jetzt benutzt. Aber ich glaube meine hätten auch funktioniert. Da der Fehler ja jetzt doch wohl eher bei mir lag.

@all: Danke für eure Hilfe!

kremin