Capi / mISDN und PTP Mode

[sabersoft]

Hallo,

ich habe hier einen Rechner mit einer AVM Fritz PCI 2.0 mit den aktuellsten mISDN Treibern welche über das mISDN_Capi und capi Modul dem Asterisk PBX das ISDN (P2P = Anlagenanschluss) zur Verfügung stellt.

Den mISDN Treiber für den Asterisk wollte ich zuerst benutzen, nur leider bekomme ich es damit nicht zum laufen... er bleibt nach "INIT Stack: success" hängen und beendet sich. Da findet man leider auch nicht wirklich viele Information dazu.

Über das Chan_capi funktioniert es, nur habe ich da nicht nachvollziehbar einen KernelOps (Speicher habe ich schon getauscht , Timing geändert etc.. das steht aber alles in der mISDN Mailinglist) aber ein Problem bleibt.

Ich habe einen Rufnr. Block von 0-49 wobei die 1-9 nicht genutzt werden. Das Problem ist wenn jemand langsam eine Nummer nacheinander eingibt dann nimmt * die 1. Zahl (Beispiel jemand will die Durchwahl 11 wählen) diese ist natürlich nicht im Dialplan und so klingelt es sehr kurz (0,5sek) und dann kommt ein Besetztzeichen. Kann mir da jemand einen Tip zu geben.
Ich wäre auch Froh ober ein Link oder eine Erläuterung bezüglich dem mISDN * Treiber (chan_mISDN) damit könnte man den KernelOops wegbekommen deshalb suche ich leute die das in Benutzung haben ...

Ronny

Asterisk 1.0.0. stable
chan_capi 0.3.5
mIsdn latest 24.09.04 (kernelmod.)
chan_mISDN 0.0.2-rc3 (führe gerade einen Versuch mit der 0.0.3 durch vom 1.11...
AVM Fritz PCI 2.0

 

[rajo]

Ich wäre auch Froh ober ein Link oder eine Erläuterung bezüglich dem mISDN * Treiber (chan_mISDN) damit könnte man den KernelOops wegbekommen deshalb suche ich leute die das in Benutzung haben ...

was für ein linux mit was für einem kernel läuft da auf was für einem rechner?

kommt der oops nachweisbar vom capi? oder fliegt da vorher was anderes schon weg?

 

[sabersoft]

Hallo,

Anbei der Text der ISDN4Linux- mISDN Maillingliste (http://listserv.isdn4linux.de/pipermail/isdn4linux/2004-November/000985.html)

Falls noch Fragen offen sind nur raus ich beantworte die Gerne sowie es geht ... heute ist der Server mal den ganzen Tag produktiv ohne Oops gelaufen (früh 8:22 Uhr einer) danach noch keiner wieder mal schauen.. ich werde das Gefühl nich los das es am 2.6.5er Kernel liegen kann ...

Ronny

=============
Hallo Liste,

erstmal die Systemumgebung:
Linux: Suse 9.1 Kernel 2.6.5-7.108-default
RAM: (256MB DDR / 512 MB DDR)
CPU: AMD Duron 1300MHz
ISDN: AVM FritzCard PCI 2.0
Anschluss: P2P Anlagenanschluss Nummernblock 0-49 (1-9 wird nicht genutzt)

TelefonieServer: Asterisk 1.0.0 (stable)
Chan_Capi: 0.3.5
mISDN 0.0.2-rc3

Die Fritzcard wird per mISDN in das System eingebunden und dann per mISDN_capi
und capi verfügbar gemacht. Asterisk setzt dann auf die Capi auf.
(mit dem mISDN Treiber für Asterisk bekam ich es total nicht zum laufen )

Das System läuft ansich ganz gut. Nur Folgende Probleme stören (die sich laut
den Logs auf mISDN beziehen daher der Post:


1. Kernel Oops nicht nachvollziehbar:

====/var/log/messages================================
Nov 1 09:13:47 nema kernel: Unable to handle kernel NULL pointer dereference
at virtual address 000000b0
Nov 1 09:13:47 nema kernel: printing eip:
Nov 1 09:13:47 nema kernel: ccbc5839
Nov 1 09:13:47 nema kernel: *pde = 00000000
Nov 1 09:13:47 nema kernel: Oops: 0000 [#3]
Nov 1 09:13:47 nema kernel: CPU: 0
Nov 1 09:13:47 nema kernel: EIP: 0060:[__crc_fb_get_buffer_offset
+8469116/9376737] Tainted: GF U
Nov 1 09:13:47 nema kernel: EIP: 0060:[<ccbc5839>] Tainted: GF U
Nov 1 09:13:47 nema kernel: EFLAGS: 00010202 (2.6.5-7.108-default)
Nov 1 09:13:47 nema kernel: EIP is at ncciL4L3+0x149/0x1c0 [mISDN_capi]
Nov 1 09:13:47 nema kernel: eax: 000000b0 ebx: c6ee1480 ecx: 00000000
edx: c6ee1480
Nov 1 09:13:47 nema kernel: esi: fffffffa edi: 000000b0 ebp: 00020180
esp: c63f9e60
Nov 1 09:13:47 nema kernel: ds: 007b es: 007b ss: 0068
Nov 1 09:13:47 nema kernel: Process asterisk (pid: 7003, threadinfo=c63f8000
task=c641d3e0)
Nov 1 09:13:47 nema kernel: Stack: 000000b0 00000000 c80dfe5c c8463bf0
00000001 ccbc7180 ccbc71dc 00000000
Nov 1 09:13:47 nema kernel: 00000000 00000000 c8463bf0 00000001
cc9fb00f c80dfe5c c8463bd4 c80dfe5c
Nov 1 09:13:47 nema kernel: c8463bf0 ccbc6740 ccbc67d2 c8463bf0
ccbcd408 00010101 00000000 c8463bf0
Nov 1 09:13:47 nema kernel: Call Trace:
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8475587/9376737]
ncci_connect_b3_conf+0x0/0x70 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc7180>] ncci_connect_b3_conf+0x0/0x70
[mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8475679/9376737]
ncci_connect_b3_conf+0x5c/0x70 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc71dc>] ncci_connect_b3_conf+0x5c/0x70
[mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+6591058/9376737]
mISDN_FsmEvent+0x5f/0xb0 [mISDN_core]
Nov 1 09:13:47 nema kernel: [<cc9fb00f>] mISDN_FsmEvent+0x5f/0xb0
[mISDN_core]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8472963/9376737]
ncci_connect_b3_req+0x0/0xe0 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc6740>] ncci_connect_b3_req+0x0/0xe0
[mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8473109/9376737]
ncci_connect_b3_req+0x92/0xe0 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc67d2>] ncci_connect_b3_req+0x92/0xe0
[mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+6591058/9376737]
mISDN_FsmEvent+0x5f/0xb0 [mISDN_core]
Nov 1 09:13:47 nema kernel: [<cc9fb00f>] mISDN_FsmEvent+0x5f/0xb0
[mISDN_core]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8471102/9376737]
ncciGetCmsg+0xfb/0x150 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc5ffb>] ncciGetCmsg+0xfb/0x150 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8477938/9376737]
ncciSendMessage+0x6f/0x140 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc7aaf>] ncciSendMessage+0x6f/0x140
[mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8462278/9376737]
ConnectB3Request+0x13/0x40 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc3d83>] ConnectB3Request+0x13/0x40
[mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8453887/9376737]
ApplicationSendMessage+0x39c/0x460 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbc1cbc>] ApplicationSendMessage+0x39c/0x460
[mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+8446114/9376737]
SendMessage+0x2f/0x60 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [<ccbbfe5f>] SendMessage+0x2f/0x60 [mISDN_capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+6696985/9376737]
capi20_put_message+0x1b6/0x220 [kernelcapi]
Nov 1 09:13:47 nema kernel: [<cca14dd6>] capi20_put_message+0x1b6/0x220
[kernelcapi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+6485556/9376737]
capi_write+0x131/0x280 [capi]
Nov 1 09:13:47 nema kernel: [<cc9e13f1>] capi_write+0x131/0x280 [capi]
Nov 1 09:13:47 nema kernel: [__crc_fb_get_buffer_offset+6485251/9376737]
capi_write+0x0/0x280 [capi]
Nov 1 09:13:47 nema kernel: [<cc9e12c0>] capi_write+0x0/0x280 [capi]
Nov 1 09:13:47 nema kernel: [vfs_write+159/256] vfs_write+0x9f/0x100
Nov 1 09:13:47 nema kernel: [<c0158a4f>] vfs_write+0x9f/0x100
Nov 1 09:13:47 nema kernel: [sys_write+129/208] sys_write+0x81/0xd0
Nov 1 09:13:47 nema k fritz_manager: prim f1880 not handledernel:
[<c0158c81>] sys_write+0x81/0xd0
Nov 1 09:13:47 nema kernel: [sysenter_past_esp+82/121] sysenter_past_esp
+0x52/0x79
Nov 1 09:13:47 nema kernel: [<c0107dc9>] sysenter_past_esp+0x52/0x79
Nov 1 09:13:47 nema kernel:
Nov 1 09:13:47 nema kernel: Code: ff 10 89 c6 85 c0 74 1d 8b 83 a0 00 00 00
48 74 0d ff 8b a0
==============end of cut=========================================

Zuerst führten wir das auf den Speicher bzw das Timing und tauscht Speicher
und änderten auch das Speichertiming auf sehr moderate Werte. Der Server lief
danach etwas besser bzw. länger aber nach ca 4h Betrieb kam der Kernel Oops
nochmal.

Any Hints ? Beziehungsweise ist da irgendwas bekannt. Ich habe den ganze nTag
gegoogelt aber wirklich nützliches Leider nicht gefunden.


2. Meldungen in der /var/log/messages bei jedem Anruf / nach jedem Auflegen:

Folgende Meldungen mein ich:

=================/var/log/messages============================
Nov 1 09:14:13 nema kernel: fritz_manager: prim f1880 not handled
Nov 1 09:14:13 nema kernel: mISDN: INTERNAL ERROR in drivers/isdn/hardware/
mISDN/stack.c:464 register duplicate 50300104 c433c8c0 c433c8c0
Nov 1 09:14:13 nema kernel: AppPlciLinkUp MGR_REGLAYER | INDICATION ret(-16)
==============end of cut======================================

Für die "fritz_manager: prim f1880 not handled" Meldung findet man den
Hinweis, das sei nur ein Hinweis , worüber man sich keine Gedanken machen
muss (Entwicklerdebug Zeugs ) aber für die restlichen 2 Messages findet
man leider nichts sinnvolles ...

Hat jemand dafür einen Tip / Rat / Link ?

Bin für jeden Hinweis dankbar und entschuldige mich falls der Post etwas lang
geworden ist.

Ronny

 

[rajo]

hmmm.... :gruebel: funzt der chan_capi überhaupt mit dem mISDN-Capi zusammen?

schonmal mit den Capi-Treibern von AVM + chan_capi probiert?

 

[sabersoft]

Jo das funzt ganz gut .. cappinfo zeigt einen Controller an (mISDN1) das funzt auch alles ... ausser dem Kernel Oops .. der aber nun seltener auftritt ich werde das morgen nochmal genauer beobachten.

Da ich nen Anlagenanschluss habe ist das mit der Normalen AVM Capi und ner Passiven Fritz nich möglich jedenfalls fand ich keine Andere Lösung ...

wäre ja auch froh wenn jemand mir ne Conf für das chan_misdn zeigen würde für anlagenanschluss die funzt .. da habe ich schon stunden probiert aber nie ging es damit obwohl der mISDN treiber ja perfekto läuft.

Ronny

 

[Tucca]

Hallo!

Das gleiche Problem habe ich auch.
In meinem PC steckt eine Eicon Diva 4BRI und Chan Capi...

Ich habe das Problem das bei langsamer Wahl nur die erste Ziffer übernommen wird und seit neusten auch nur noch einige Bereiche (z.B. 1046789 geht nicht mehr).

Kann mir jemand sagen ob ich für Chan Capi oder so ein Config-Datei bearbeiten kann.
Asterisk ist so programmiert, dass er die MSNs annimmt.


Vielen Dank für Eure Hilfe,
Tucca

 

[chtephan]

Jo das funzt ganz gut .. cappinfo zeigt einen Controller an (mISDN1) das funzt auch alles ... ausser dem Kernel Oops .. der aber nun seltener auftritt ich werde das morgen nochmal genauer beobachten.

Ich kann ihn 100% akkurat reproduzieren. Auf meinem abgeschalteten Handy anrufen, dann passiert's. Habe zwei HFC-Karten und mISDN ist die einzige Art, die eine von beiden (die zweite läuft im NT-Modus) mit CAPI zu betreiben (so daß man die Karte auch außerhalb von Asterisk parallel mit anderer Software nutzen kann).

Was mich etwas stört ist, daß der Bug so aussieht, als wäre er nicht schwer zu beheben, leider kenne ich mich in den Internas von mISDN nicht gut genug aus.

Vielleicht wenn man den Entwickler mal ganz freundlich tritt, wer weiß.

 

[sabersoft]

Hmm, also ich habe an dem * Server ja einen Grandstream ATA286 dran der Rest Softphones (SJLabs Phone) und wenn der Grandstream nicht am Netz ist passiert es nicht (jedenfalls seit 2 Tagen kein Kernel OOps mehr ...) werde das beobachten.

Was mich mehr interessiert ist die geschichte mit den Durchwahlnummern...

Laut meiner Telcogesellschaft soll die Telefonanlage warten bis die Nr. Komplett ist ... also 0 = Zentrale geht ja auch ...
aber wenn man die 11 anrufen will , und normal nummer für nummer wählt dann nimmt asterisk die 1 (die nich im dialplan ist es klingelt kurz , und dann besetzt) und wartet nich auf die letzte Ziffer ...

ich habe wie gesagt mISDN und die chan_capi am laufen wo auch p2p eingestellt ist ... habe ich da nen kleine Denkfehler ?! :.Hat sowas zufällig jemand laufen und gibt mir den entscheidenden Hinweis... ?!

Wenn man nach dem Wahlversuch, wiederwahl drückt dann paßt es und der Anruf komtm wie er soll auf der 11 an ....

Wie gesagt an Tips bin ich brennend Interessiert ... da es zur P2P Konfig ja leider wenig Infos gibt ...

Bzw wenn jemand das mISDN Modul für Asterisk am laufen hat an der Config wäre ich auch interessiert .. wenn ich es so versuche lädt asterisk normal aber als er dann mISDN initialisieren will kommt nur Init Stackt etc Success und dann bricht er ohne Fehler ab (asterisk -vvvvvvvvvvvv) ... obwohl ich laut der spärlichen conf alles richtig eingerichtet hatte ...

Ronny

 

[chtephan]

Meine mISND-Config

[general]
context=default
debug=0

[intern]
ports=2
context=default
immediate=yes

Ist eigentlich ganz einfach, man muß bei ports= die Nummer der Karte angeben, so wie sie im mISDN konfiguriert wurde, bei mir ist die erste, die, die normal betrieben wird (TE-Modus), über mISDN_capi. Die zweite im NT-Modus.

Damit das geht, muß man beim Laden des Treibers die zu verwendenden Protokolle angeben.

options hfcpci protocol=0x2,0x12 layermask=0x1f,0x3

Also wie man sieht, die erste Karte Protokoll 2 (Euro-DSS1), Layermask 0x1f (bis Protokoll 4, damit man den CAPI/I4l verwenden kann). Die zweite Karte auch Protokoll 2, allerdings im NT-Modus, und nur die grundlegensten Layer, damit chan_misdn die Vermittlungsstelle simulieren kann. Wenn man chan_misdn im TE-Modus verwenden will, muß man layermask=0xf verwenden. Ob NT- oder TE-Modus verwendet wird, findet chan_misdn selbst raus.

Praktisch ist in der Hinsicht auch pbx4linux, da kann man sich die laufende Konfiguration ansehen.

server:/root # pbx query
** PBX4Linux ** Version 2.5 (August 2004)

Bei mir:

Port 1: TE-mode BRI S/T interface line (for phone lines)
-> Protocol: DSS1 (Euro ISDN)
-> Layer 4 protocol 0x04000001 is detected, but not allowed for TE lib.
* Port NOT useable for PBX
--------
Port 2: NT-mode BRI S/T interface port (for phones)
--------

Ich habe übrigens chan_misdn etwas modifiziert, damit er ohne DISA/Answer einen Wählton generiert, der beim ersten Drücken einer Taste verstimmt. Grund ist, daß dann DTMF vom ISDN-Geräte gemacht wird, nicht von Asterisk (weil letzteres unzuverlässig funktioniert).

Der Bug im mISDN_capi-Kernelmodul ist übrigens nicht lustig, weil er immer genau unter den gleichen Bedingungen auftritt. Nicht irgendwie zufällig oder so. Er geht auch nicht von alleine weg.

 

[Tucca]

Auf meinem * ist kein mISDN installiert.

Wie bekomme ich das nur mit chan_capi hin, dass er auf Durchwahlen wartet?

Die 0 ist die Zentrale
1X - 9X sind Durchwahlen

Als ISDN-Karte verwende ich eine EICON Diva 4BRI (8 Kanäle)

capi.conf

[general]
mode=immediate
isdnmode=ptp
nationalprefix=0
internationalprefix=00
rxgain=0.8
txgain=0.8

[interfaces]
msn = 10467810,10467811,10467813,10467833,10467830,1046780
incomingmsn = 10467810,10467811,10467813,10467833,10467830,1046780
context = pstn
controller = 1,2,3,4
devices = 8

Danke,
Tucca

 

[sabersoft]

@tucca: Bei dir sollte das aber stimmen so wie ich das sehe .. vielleicht das IMMEDIATE mal rausnehmen und mal schauen ob er es so tut ?! ... sorry mehr kann ich da leider nich zu sagen

Hmmm, also ich habe nun mit der capi.conf rumexperimentiert .. .aber ich bekomme es nich hin das er auf die Nummer wartet (1x da nimmt er die 1 was ja keine Nummer ist (noch nicht) => Dienst oder Dienstmerkmal nicht möglich )

Hat nich zufällig jemand mISDN + mISDN Capi und chan Capi mit dem * am laufen mit P2P bei dem das mit der Blockwahl hinhaut ... das kann doch nur ein kleiner Fehler sein ...

das mISDN Modul "avmfritz" lade ich mit folgenden Parametern.

modprobe avmfritz protocol=0x22 debug=0x0

ist da eventuell mein Fehler drin ?!

Ronny

 

[Tucca]

... habe im pstn-Context nun folgende Zeilen integriert:

exten => 123456[1-9],1,Answer
exten => 123456[1-9],2,WaitExten(10)

exten => _[1-9],1,Goto(duo,${DND:6}${EXTEN},1)

so läuft es bei mir.

Gruß!

 

[sabersoft]

Hmm bei mir ist das etwas anders ... die CAPI signalisiert nur die MSN direkt (also 0,10,11 etc)

Habe da etwas rumgespielt mit deinen 3 Dialplan Rules. . aber noch haut es nich hin wenn man manuell wählt dann muss man kurz warten dann die EXT eingeben auf die er wartet und es klingelt ... aber die Pause ist zu lang also man kann nich normal tippen dann kommt das altbekannte besetzt ...

Ich habe es so probiert; (für die MSN 3x)

exten => 3,1,Answer
exten => 3,2,WaitExten(10)
exten => _3,1 Goto(kontext,dialplanprefix,1)

Stell ich mich heute nur zu blöd an ?!

Ronny

 

[Tucca]

wichtig ist noch folgende Erweiterung im eingehenden Kontext:

exten => _[1-9].,1,Goto (...)

Durch diese wird nach der Eingabe der ersten Zahl (1-9) automatisch Goto ausgelöst.

Ausserdem musst du die MSN ausschreiben (Bsp: 1234-3, nur _3 reicht nicht)


Komplett:

exten => _[1-9],1,Goto (...)

exten => 12343,1,Answer()
exten => 12343,2,WaitExten(3)

 

[sabersoft]

Jo aber durch die mISDN Treiber kommen die eingehenden Rufnr nich als Nummer-XX an sondern nur als XX (also NUR die MSN bzw die Durchwahl ... Wäre mir auch lieber wenn nicht nur die Durchwahl koimmen würde aber besser als nix .... schau gerade und liebäugel mit ner ISA Eicon Diva 2Bri Karte .. sollte ja erstmal ausreichen ... mit der scheiss AVM Fritz hat man nur Probleme

Ronny

 

[chtephan]

Hallo, hier ein "Fix", der das Auftreten des Oopses verhindert und den Asterisk normal und funktionierend weiterlaufen läßt. Eigentlich scheint der Fehler in der Client-Software zu liegen, der scheint den CAPI etwas wüst anzusprechen.

--- linux.orig/drivers/isdn/hardware/mISDN/helper.h    2004-06-17 14:31:12.000000000 +0200
+++ linux/drivers/isdn/hardware/mISDN/helper.h 2004-12-13 01:57:38.000000000 +0100
@@ -152,7 +152,7 @@
        if (!(skb = create_link_skb(prim, dinfo, len, arg, reserve)))
 #endif
                return(-ENOMEM);
-       if (!i)
+       if (!i || !i->func)
                err = -ENXIO;
        else
                err = i->func(i, skb);