[gelöst] empty_chan_in_stack/ L1_DEACTIVATED

[debitux]

Hi,

nachdem Asterisk im Testbetrieb im März (über ISDN per Colt Telecom [=über Colt-eigenen-Router dann per Breitband]) lief, war nun der Produktiveinsatz an einem ISDN-Anschluß der DTAG geplant.

Nun funktioniert ISDN nicht mehr.

mISDN und mISDNuser, sowie Asterisk sind nach einem Etch-Imageupdate neu kompiliert.

Meldungen im CLI (bei misdn.conf debug-level 4):

    -- Executing [012345@2000:1] Set("SIP/2000-085d94b8", "CHANNEL(language)=de") in new stack
    -- Executing [012345@2000:2] misdn_check_l2l1("SIP/2000-085d94b8", "g:ext1|2") in new stack
P[ 0] Checking Ports in group: ext1
P[ 0] trying port 1
P[ 1] Port down PMP
P[ 0]  --> port '1'
P[ 0] trying port 2
P[ 0] Waiting for '2' seconds
P[ 0] MGMT: SSTATUS: L1_DEACTIVATED
    -- Executing [012345@2000:3] Set("SIP/2000-085d94b8", "CALLERID(name)=debitux") in new stack
    -- Executing [012345@2000:4] Set("SIP/2000-085d94b8", "CALLERID(number)=567890") in new stack
    -- Executing [012345@2000:5] Dial("SIP/2000-085d94b8", "mISDN/1/12345|60|TWr") in new stack
P[ 0]  --> * NEW CHANNEL dad:12345 oad:(null)
P[ 1] * Queuing chan 0x85ad5d8
P[ 1] read_config: Getting Config
P[ 1]  --> TON: Unknown
P[ 1]  --> LTON: Unknown
P[ 1]  --> CTON: Unknown
P[ 1] * CALL: 1/12345
P[ 1]  --> * dad:012345 tech:mISDN/0-u3 ctx:incomingISDN_1
P[ 1]  --> * adding2newbc ext 012345
P[ 1]  --> * adding2newbc callerid 024196109710
P[ 1]  --> pres: -1 screen: -1
P[ 1]  --> pres: 0
P[ 1]  --> PRES: Allowed (0x0)
P[ 1]  --> SCREEN: Unscreened (0x0)
P[ 1] NO OPTS GIVEN
P[ 1] I SEND:SETUP oad:024196109710 dad:12345 pid:5
P[ 1]  --> bc_state:BCHAN_CLEANED
P[ 1]  --> channel:0 mode:TE cause:16 ocause:16 rad: cad:
P[ 1]  --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1]  --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1]  --> screen:0 --> pres:0
P[ 1]  --> addr:0 l3id:50001 b_stid:0 layer_id:0
P[ 1]  --> facility:Fac_None out_facility:Fac_None
P[ 1] --> new_l3id 50004
P[ 1]  --> * SEND: State Dialing pid:5
    -- Called 1/12345
P[ 1] Sending msg, prim:30580 addr:41000104 dinfo:50004
P[ 1] handle_frm: frm->addr:42000103 frm->prim:3ff82
P[ 1] I IND :TIMEOUT oad:024196109710 dad:12345 pid:5 state:CALLING
P[ 1]  --> channel:255 mode:TE cause:16 ocause:16 rad: cad:
P[ 1]  --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1]  --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1]  --> screen:0 --> pres:0
P[ 1]  --> addr:0 l3id:50004 b_stid:0 layer_id:0
P[ 1]  --> facility:Fac_None out_facility:Fac_None
P[ 1]  --> bc_state:BCHAN_CLEANED
P[ 1] --> state: CALLING
P[ 1] I SEND:DISCONNECT oad:024196109710 dad:12345 pid:5
P[ 1]  --> bc_state:BCHAN_CLEANED
P[ 1]  --> channel:255 mode:TE cause:16 ocause:1 rad: cad:
P[ 1]  --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
P[ 1]  --> caps:Speech pi:0 keypad: sending_complete:0
P[ 1]  --> screen:0 --> pres:0
P[ 1]  --> addr:0 l3id:50004 b_stid:0 layer_id:0
P[ 1]  --> facility:Fac_None out_facility:Fac_None
P[ 1] Sending msg, prim:34580 addr:41000104 dinfo:50004
P[ 1] handle_frm: frm->addr:42000103 frm->prim:3f182
P[ 1]  --> lib: RELEASE_CR Ind with l3id:50004
P[ 1]  --> lib: CLEANING UP l3id: 50004
P[ 1]  --> queue_hangup
P[ 1] * RELEASING CHANNEL pid:5 ctx:incomingISDN_1 dad:12345 oad:012345 state: CALLING
P[ 1]  --> * State Down
P[ 1]  --> Setting AST State to down
P[ 1] $$$ CLEANUP CALLED pid:5
P[ 1] empty_chan_in_stack: cannot empty channel 255
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [012345@2000:6] Congestion("SIP/2000-085d94b8", "") in new stack
  == Spawn extension (2000, 012345, 6) exited non-zero on 'SIP/2000-085d94b8'
P[ 0] MGMT: SSTATUS: L1_DEACTIVATED

[Rufnummern pp. anonymisiert]

Auszug dialplan:

exten => _0X.,1,Set(CHANNEL(language)=de)
exten => _0X.,2,misdn_check_l2l1(g:ext1|2)
exten => _0X.,3,Set(CALLERID(name)=debitux)
exten => _0X.,4,Set(CALLERID(number)=567890)
exten => _0X.,5,Dial(mISDN/1/${EXTEN:1},60,TWr)
exten => _0X.,6,Congestion
exten => _0X.,106,Busy
exten => _0X.,n,Hangup

misdn.conf:

[general]
misdn_init=/etc/misdn-init.conf
bridging=no
debug=4
l1watcher_timeout=2
ntkeepcalls=no

[default]
echocancel=yes
txgain=-1
senddtmf=yes
hold_allowed=yes
method=standard
language=de
nationalprefix=0
internationalprefix=00
dialplan=0
pmp_l1_check=no

[ext1]
ports=1
context=incomingISDN_1
msns=567890

[ext2]
ports=2
context=isdn_2
msns=*

misdn-init.conf:

card=1,avmfritz
card=2,avmfritz
te_ptmp=1,2
option=1,master_clock
poll=128
dsp_poll=128
dsp_options=0
dtmfthreshold=100
debug=0

Die Anweisung "misdn_check_l2l1" im dialplan habe ich nach entsprechender Suche eingefügt, mit und ohne ist das Ergebnis gleich.

Ebenso ist das Ergebnis mit und ohne die Eintragungen in der misdn.conf unter [general] und [default] gleich.
Auch die Einträge dort "l1watcher_timeout=2" (egal ob mit Wert "0", "2" oder "4" --> ändert nichts) , sowie "pmp_l1_check=no" (oder "yes" oder ganz ohne) stammen aus umfangreicher Suche.

Nach Vertauschen/Umstecken der ISDN-Karten war genau *ein* Mal ein Verbindungsaufbau abgehend möglich, wobei die Verbindung zum internen snom360 nach der Anwahl abgebrochen wurde und der Anrufbeantworter am angerufenen Ende fleißig aufzeichnete... (--> also ist die Karte, Verbindung zum NTBA usw. o.k.)

Seither weder gehende noch kommende Anrufe möglich.

Ach ja: Das Ergebnis ist gleich, egal ob Verbindung zum NTBA mit Karte 1, oder Karte 2, oder ob Ruf per Gruppe (g:ext1), oder direkt per Port...

Danke für's mitdenken,

Gruß,

debitux

 

[Burmann]

Stoppe dein Asterisk und Poste den Output von
"/etc/init.d/misdn-init scan",
"misdnportinfo" und
"lspci"

Starte dann asterisk und Poste den Log bei diesen Befehlen in der CLI

• misdn show stacks
• misdn port up 1
• misdn port up 2
• misdn show stacks
• misdn show config

 

[debitux]

Hallo Burmann,


danke für die Antwort. Hier die Ausgaben:

I. Asterisk: stop now
1.

/etc/init.d/misdn-init scan
[OK] found the following devices:
card=1,avmfritz
card=2,avmfritz
[ii] run "/usr/sbin/misdn-init config" to store this information to /etc/misdn-init.conf

2.

misdnportinfo

Port  1: TE-mode BRI S/T interface line (for phone lines)
 -> Protocol: DSS1 (Euro ISDN)
 -> childcnt: 2
--------
Port  2: TE-mode BRI S/T interface line (for phone lines)
 -> Protocol: DSS1 (Euro ISDN)
 -> childcnt: 2
--------

mISDN_close: fid(3) isize(131072) inbuf(0x804c060) irp(0x804c060) iend(0x804c060)

lspci
00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01)
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (LOM) Ethernet Controller (rev 81)
02:0a.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH A1 ISDN [Fritz] (rev 02)
02:0c.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN (rev 01)

II. CLI

* misdn show stacks

BEGIN STACK_LIST:
  * Port 1 Type TE Prot. PMP L2Link DOWN L1Link:DOWN Blocked:0  Debug:4
  * Port 2 Type TE Prot. PMP L2Link DOWN L1Link:DOWN Blocked:0  Debug:4

(das variiert. Manchmal ist bei (Ab-)Wahlversuchen L1 UP, manchmal L2 UP (Port 1, natürlich). Eine Gesetzmäßigkeit habe ich noch nicht feststellen können...)

* misdn port up 1
keine Ausgabe

* misdn port up 2
keine Ausgabe

* misdn show stacks

BEGIN STACK_LIST:
  * Port 1 Type TE Prot. PMP L2Link DOWN L1Link:DOWN Blocked:0  Debug:4
  * Port 2 Type TE Prot. PMP L2Link DOWN L1Link:DOWN Blocked:0  Debug:4

* misdn show config

misdn show config
Misdn General-Config:
 -> misdn_init: /etc/misdn-init.conf -> debug: 4
 -> tracefile: /var/log/asterisk/misdn.log -> bridging: no
 -> stop_tone_after_first_digit: yes -> append_digits2exten: yes
 -> dynamic_crypt: no                -> crypt_prefix:
 -> crypt_keys:                      -> ntkeepcalls: no
 -> ntdebugflags: 0                  -> ntdebugfile: /var/log/misdn-nt.log


[PORT 1]
 -> name: ext1                        -> allowed_bearers: all
 -> far_alerting: no                 -> rxgain: 0
 -> txgain: -1                           -> te_choose_channel: no
 -> pmp_l1_check: no             -> reject_cause: 21
 -> block_on_alarm: no          -> hdlc: no
 -> context: incomingISDN_1 -> language: de
 -> musicclass: default            -> callerid:
 -> method: standard              -> dialplan: 0
 -> localdialplan: 0                  -> cpndialplan: 0
 -> nationalprefix: 0               -> internationalprefix: 00
 -> presentation: -1                 -> screen: -1
 -> always_immediate: no      -> nodialtone: no
 -> immediate: no                   -> senddtmf: yes
 -> astdtmf: no                        -> hold_allowed: yes
 -> early_bconnect: yes          -> incoming_early_audio: no
 -> echocancel: 128                -> need_more_infos: no
 -> noautorespond_on_setup: no       -> nttimeout: no
 -> bridging: yes                     -> jitterbuffer: 4000
 -> jitterbuffer_upper_threshold: 0  -> callgroup:
 -> pickupgroup:                     -> max_incoming: -1
 -> max_outgoing: -1             -> l1watcher_timeout: 0
 -> overlapdial: 0                    -> msns: 567890, 567891
 -> faxdetect: no                     -> faxdetect_context:
 -> faxdetect_timeout: 5         -> ptp: no


[PORT 2]
 -> name: ext2                        -> allowed_bearers: all
 -> far_alerting: no                 -> rxgain: 0
 -> txgain: -1                           -> te_choose_channel: no
 -> pmp_l1_check: no             -> reject_cause: 21
 -> block_on_alarm: no          -> hdlc: no
 -> context: isdn_2                 -> language: de
 -> musicclass: default            -> callerid:
 -> method: standard              -> dialplan: 0
 -> localdialplan: 0                  -> cpndialplan: 0
 -> nationalprefix: 0                -> internationalprefix: 00
 -> presentation: -1                 -> screen: -1
 -> always_immediate: no       -> nodialtone: no
 -> immediate: no                    -> senddtmf: yes
 -> astdtmf: no                          -> hold_allowed: yes
 -> early_bconnect: yes            -> incoming_early_audio: no
 -> echocancel: 128                  -> need_more_infos: no
 -> noautorespond_on_setup: no       -> nttimeout: no
 -> bridging: yes                    -> jitterbuffer: 4000
 -> jitterbuffer_upper_threshold: 0  -> callgroup:
 -> pickupgroup:                     -> max_incoming: -1
 -> max_outgoing: -1                -> l1watcher_timeout: 0
 -> overlapdial: 0                       -> msns: *
 -> faxdetect: no                       -> faxdetect_context:
 -> faxdetect_timeout: 5           -> ptp: no

Hmm...
Allerdings war es mir eben - nach einer Auszeit von fast vier Stunden - möglich, zwei abgehende Rufe nacheinander abzusetzen. Dann war wieder Ende - das beschriebene Szenario...

Ich habe das log mit den relevanten Daten dieser zwei Anrufe mal beigefügt...

Danke für's Mitdenken,

Gruß,

debitux

 

[Burmann]

Sorry hatte gestern abend nicht mehr die Zeit zu antworten und jetzt juft grad 'n Kunde An wo die EDV ausgefallen ist..

Deshalb nur Kurz was ich bis jetzt habe:

• Ich dachte bisher 2x passive AVM-Karte geht nicht in einem System. Aber vielleicht betrifft das aber nur den Treiber von AVM nicht mISDN
• Die Einbindung des Treibers (Meldung misdnportinfo &misdn show config) sieht in ordnung aus
• Bei misdn_check_l2l1 "g:ext1" würd ich auch über diese Gruppe 'rauswählen nicht über Kanal 1
• Wenn das 2 Anrufe waren, frage ich mich warum 3 SETUP's kommen (insbesondere der mit pid:4)
• Was "cpnnumplan:2" bedeutet müsste ich nochmal nachschauen
• Über context "[incomingISDN_1]" 'raus zu wählen ist nicht falsch - irritiert aber etwas
• evtl mal in "/etc/misdn-init.conf" die 2. Karte rausnehmen (Rechner neustart!)und schauen ob es dann mit einer Karte alles geht

 

[debitux]

Hi Burmann,

Sorry hatte gestern abend nicht mehr die Zeit zu antworten und jetzt juft grad 'n Kunde An wo die EDV ausgefallen ist..

aber, aber... keine Hetze. Ich bin froh und dankbar, daß Du Dich meines Problems annimmst, daher: no Prob

Außerdem: Job geht vor, ganz klar!

• Ich dachte bisher 2x passive AVM-Karte geht nicht in einem System. Aber vielleicht betrifft das aber nur den Treiber von AVM nicht mISDN
• Die Einbindung des Treibers (Meldung misdnportinfo &misdn show config) sieht in ordnung aus
• Bei misdn_check_l2l1 "g:ext1" würd ich auch über diese Gruppe 'rauswählen nicht über Kanal 1

• am Colt Telecom-Anschluß gingen 2x AVM-Karten. Ich meine sogar, beide..
• das Ergebnis ist gleich, egal, ob über "g:ext1", oder direkt über Kanal "1" gewählt wird (zwei Kontexte zum Probieren angelegt, einmal über Gruppe, einmal über Kanal)

• Wenn das 2 Anrufe waren, frage ich mich warum 3 SETUP's kommen (insbesondere der mit pid:4)
• Was "cpnnumplan:2" bedeutet müsste ich nochmal nachschauen
• Über context "[incomingISDN_1]" 'raus zu wählen ist nicht falsch - irritiert aber etwas
• evtl mal in "/etc/misdn-init.conf" die 2. Karte rausnehmen (Rechner neustart!)und schauen ob es dann mit einer Karte alles geht

• mit den debug-Infos kann ich nur ganz rudimentär was anfangen, insbesondere "3 SETUUP's" (oder nochmehr "pid:4")
• "cpnumplan:2" werde ich gleich mal gurgeln
• der context "incomingISDN_1" bei ausgehenden Gesprächen ist mir aufgefallen. Ehrlich gesagt, verstehe ich das nicht, wo das im debug herkommt.
  Dachte, die DIAL-Anweisung wählt über den Channel mISDN, dort die Gruppe 1 ("g:ext1" --> der "Kontext" für die erste Karte in der misdn.conf) und der Kontext "incomingISDN_1" in der misdn.conf ist nur für eingehende Gespräche relevant... ???
• 2. Karte rausnehmen mache ich gleich. Muß aber auch kurz weg, daher ggfs. Bericht hierzu erst gegen ca. 13:45...

Danke einstweilen und Gruß,

debitux

 

[debitux]

Sorry, hat bei mir etwas gedauert. Habe aber auch noch einmal einiges getestet und gegurgelt...

• "cpnumplan:2" werde ich gleich mal gurgeln

hmm... was erhellendes habe ich dazu nicht finden können.

• 2. Karte rausnehmen:

hat leider nix geändert...

es grüßt

debitux

 

[Burmann]

Ich nehme an, dass "cpnumplan:2" was mit "Type Of Number in ISDN Terms" zu tun hat (siehe /etc/asterisk/misdn.conf: dialplan, localdialplan, cpndialplan)

Das mit context "incomingISDN_1" in der Debugausgabe meint, das der Dial-Befehl für ein ausgehenden Ruf in der Sektion [incomingISDN_1] von der extension.conf steht. Dies bedeutet das du 'rein und 'rausgehende Gespräche nicht in unterschiedlichen Contexten abhandelst. Damit haben externe und interne Teilnehmer die gleichen Rechte. Wenn in dem Context incomming (in dem alle extenen Rufe 'reinkommen) nur interne Telefone gerufen werden können, wird ein Externer nie ein abgehendes Amtsgespräch führen kann und damit auch nie eine 0900-Rufnummer wählen wird...

Die ProzessID (pid: x) ist (afaik) die einzige Möglichkeit die ISDN-Meldungen eines Calls zusammenzufinden, da der "channel name" sich ggf mehrfach ändert.

Ich habe festgestellt, das bei vielen Testen sich mit der Zeit Fehler einschleichen, was die Stabilität des Systems betrifft. Ich würde in diesem Fall das System neu aufestzen und komplett neu konfigurieren. Die Installation mache ich immer mit einem Script, um Reproduzierbarkeit zu erhalten:

Installation Asterisk+mISDN

 

[debitux]

Hallo Burmann,

Ich nehme an, dass "cpnumplan:2" was mit "Type Of Number in ISDN Terms" zu tun hat (siehe /etc/asterisk/misdn.conf: dialplan, localdialplan, cpndialplan)

Ah ja. Danke. Obwohl ich mir nicht sicher bin, ob mich das jetzt weiter bringt...

Das mit context "incomingISDN_1" in der Debugausgabe meint, das der Dial-Befehl für ein ausgehenden Ruf in der Sektion [incomingISDN_1] von der extension.conf steht.

öhm - der Dial-Befehl steht definitiv nicht im Kontext "incomingISDN_1". Dort stehen Anweisungen, wie eingehende Rufe zu behandeln sind, namentlich, an den (internen) SIP-Telefonen klingeln...

Folglich ist auch der Kontext in der misdn.conf für eingehende Rufe eingetragen (s. auch erstes Posting):

[ext1]
ports=1
context=incomingISDN_1
msns=567890

Aber eingehende Rufe werden ja auch nicht signalisiert. Da tut sich im CLI gar nichts...

Ich habe festgestellt, das bei vielen Testen sich mit der Zeit Fehler einschleichen, was die Stabilität des Systems betrifft. Ich würde in diesem Fall das System neu aufestzen und komplett neu konfigurieren. Die Installation mache ich immer mit einem Script, um Reproduzierbarkeit zu erhalten:

Hmm... eigentlich habe ich ja nach der letzten funktionierenden Konfiguration nichts anderes gemacht, als den Rechner an den DTAG-Anschluß umzuziehen und die midsn.conf hinsichtlich der MSN angepaßt. :noidea:

Irritierenderweise können nach langer Pause zwei Anrufe abgesetzt werden, wobei diese nach zweimaliger Anrufsignalisierung (am internen Telefon) abbrechen. Dann ist wieder Schluß. Gibt es denn Besonderheiten am DTAG-ISDN(-DSL)-Anschluß?

Gruß,

debitux

 

[debitux]

Hi,

nachdem ich noch mal alles überprüft und auch mit der DTAG/Störungsstelle telefoniert habe, weiß ich nicht weiter.

Mal gehts, dann auch zwei, drei Male hintereinander, dann wieder gar nicht.

Bleibt wohl keine andere Möglichkeit, als Neuinstallation.

Ich dachte, dann auch gleich den letzten mISDN-Release installieren (Vielleicht hat ja irgendein debian-Etch-Update was verhagelt). Von mISDN.org habe ich das letzte Release herunterladen wollen und bin dabei auf
New mISDN V2 API gestoßen. Ich dachte, vielleicht neu=besser...?

Von der angegebenen Stelle habe ich die neueste mISDN_20080827.tar.gzheruntergeladen.

Allerdings bleibt ein "make" hängen:

debitux:/usr/src/mISDN# make
echo 1_2_0 > VERSION ; \

export LINUX=/lib/modules/2.6.18-6-686/build; ./makelib.sh test_old_misdn
VERSION is 5
cp /usr/src/mISDN/drivers/isdn/hardware/mISDN/Makefile.v2.6 /usr/src/mISDN/drivers/isdn/hardware/mISDN/Makefile
cp /usr/src/mISDN/drivers/isdn/mISDN/Makefile.v2.6 /usr/src/mISDN/drivers/isdn/mISDN/Makefile
export MINCLUDES=/usr/src/mISDN/include ; export MISDNVERSION=1_2_0; make -C /lib/modules/2.6.18-6-686/build SUBDIRS=/usr/src/mISDN/drivers/isdn/mISDN modules CONFIG_MISDN_DSP=m  CONFIG_MISDN_MEMDEBUG=y  CONFIG_MISDN_HFCMULTI=m  CONFIG_MISDN_HFCPCI=m CONFIG_MISDN_L1OIP=m  CONFIG_MISDN=m
make[1]: Entering directory `/usr/src/linux-headers-2.6.18-6-686'
  CC [M]  /usr/src/mISDN/drivers/isdn/mISDN/l1oip_core.o
/usr/src/mISDN/drivers/isdn/mISDN/l1oip_core.c:1502:46: error: macro "INIT_WORK" requires 3 arguments, but only 2 given
/usr/src/mISDN/drivers/isdn/mISDN/l1oip_core.c: In function      ‘l1oip_initttttt’:
/usr/src/mISDN/drivers/isdn/mISDN/l1oip_core.c:1502: error:      ‘INIT_WORKKKKKK’ undeclared (first use in this function)
/usr/src/mISDN/drivers/isdn/mISDN/l1oip_core.c:1502: error: (Each undeclared identifier is reported only once
/usr/src/mISDN/drivers/isdn/mISDN/l1oip_core.c:1502: error: for each function it appears in.)
make[2]: *** [/usr/src/mISDN/drivers/isdn/mISDN/l1oip_core.o] Fehler 1
make[1]: *** [_module_/usr/src/mISDN/drivers/isdn/mISDN] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.18-6-686'
make: *** [all] Fehler 2

Im HOWTO meine ich, die Ursache gefunden zu haben:

3 Compile:

<snip>

Note: If you have already some version of mISDN, the installed modules will have lower priority than the kernel modules. In this case you must remove mISDN directory from your kernel modules tree, if you like to upgrade to a newer mISDN version.

Die installierte Version mISDN-1.7.2 muß also erst entfernt werden.

Aber wie?

Es grüßt

debitux

 

[debitux]

Kann mir denn keiner helfen? Dann versuche ich, die Fragen zu präzisieren.

Zum Einen habe ich die Frage, wie ich denn mISDN V2 installiere, da die Installation über die bestehende mISDN-1.7.2 wohl nicht drüberzubügeln ist.

Zum Anderen:
Nach Rückumzug zeigt der Rechner an einem anderen Anschluß, als DTAG, nämlich nunmehr am örtlichen Provider die selben Symptome: Es geht ca. 5 bis 20 Minuten, dann ist Ende.

Könnte das Problem an der/den Fritz-Card liegen?

Habe noch zwei Longshine LCS 8051 ISDN (hfc-Chipsatz) herumliegen, die ich beispielsweise an Stelle der Fritz!-Karten einbauen könnte. Muß ich hierzu irgendwelche Treiber installieren (bzw. Treiber der Fritz!-Karte deinstallieren)?

Danke einstweilen

Gruß,

debitux

 

[Burmann]

Ich denke in /etc/misdn-init.conf "card=1,avmfritz" in "card=1,hfcpci" ändern tut's.
Aber ich würd dir empfehlen mit einem 2. Rechner/(oder anderer HD) und einer ISDN-Karte zu testen nach der Anleitung http://www.ip-phone-forum.de/showpost.php?p=1151754&postcount=27

 

[debitux]

Hallo Burmann,

Danke einstweilen.

Hatte erst gestern wieder Zugriff auf den Rechner mit ISDN-Anschluß.
Habe einen zweiten Rechner konfiguriert - der läuft mit der HFC-Karte.
Werde die Karte dann heute abend mal umbauen, da der zweite/Test-Rechner etwas anders konfiguriert ist (Sidux statt Etch) und dann berichten...

Nochmals danke.

Gruß,

debitux

 

[debitux]

Hatte erst gestern wieder Zugriff auf den Rechner mit ISDN-Anschluß.
<snip>
Werde die Karte dann heute abend mal umbauen, da der zweite/Test-Rechner etwas anders konfiguriert ist (Sidux statt Etch) und dann berichten...

Etwas später als geplant (andere Baustellen):
Karte umgebaut,

in /etc/misdn-init.conf "card=1,avmfritz" in "card=1,hfcpci" ändern

und die Kiste läuft anstandslos. Prima. Danke, Burmann

Gruß,

debitux