[Home]

Summary:ASTERISK-13176: [patch] "pri_find_dchan: No D-channels available!" error on console when using wcb4xxp
Reporter:Shaun Ruffell (sruffell)Labels:
Date Opened:2008-12-08 14:55:22.000-0600Date Closed:2012-06-04 17:11:01
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 01-bri_l1_check.patch
( 1) 20080317_chan_dadhi.diff
( 2) bt.txt
( 3) intense-ssabme.txt
( 4) ssabme.txt
( 5) TEIASSIGNMENT.txt
Description:When a wcb4xxp is connected as a BRI span in TE mode, you get errors like:

[Dec 2 22:02:48] WARNING[4759]: chan_dahdi.c:3008 pri_find_dchan: No D-channels available! Using Primary channel 6 as D-channel anyway!
[Dec 2 22:02:49] WARNING[4758]: chan_dahdi.c:3008 pri_find_dchan: No D-channels available! Using Primary channel 3 as D-channel anyway!
[Dec 2 22:03:19] WARNING[4759]: chan_dahdi.c:3008 pri_find_dchan: No D-channels available! Using Primary channel 6 as D-channel anyway!

On your asterisk console and in your asterisk log.
Comments:By: Shaun Ruffell (sruffell) 2008-12-08 14:59:40.000-0600

I've uploaded 01-bri-l1-check.patch which adds an option in chan_dahdi.conf titled pmp_l1_check which is much like the same parameter in the misdn.conf file.

Essentially it is used to control whether the layer 1 link state on point to multi-point BRI links should be used by chan_dahdi when managing the BRI span.

By: Francesco Romano (francesco_r) 2008-12-23 07:27:50.000-0600

I have tried this patch (adapted) with asterisk-1.6.1-beta4 but i still can't make calls when the span is down. In chan_dahdi i have put pmp_l1_check=no.
Am i missing something?

By: Tilghman Lesher (tilghman) 2008-12-23 09:00:12.000-0600

francesco_r: the option name is ell-one, not pipe-one.

By: Francesco Romano (francesco_r) 2008-12-23 09:12:50.000-0600

I have rechecked and i wrote correctly l1 (layer1)

By: Tim King (timking) 2009-01-06 10:13:56.000-0600

This works well with an OpenVox board and the patched wcb4xxp driver mentioned in bug 0013897 (tested with a UK BRI point-to-multipoint line).

By: Francesco Romano (francesco_r) 2009-01-08 05:24:18.000-0600

Which version of asterisk have you applied the patch timking? When i tested in PtMP attached to ISDN Telecom Italia didn't work.

By: Tim King (timking) 2009-01-09 10:50:35.000-0600

I applied it to 1.6.0.3-rc1. Of course you have then to set pmp_l1_check=no and signalling=bri_cpe_ptmp in chan_dahdi.conf. It only stops it reporting the reset that seems to happen every minute or so.

Your problem seems to be something else, as even when it reports this error if you turn on debug you see that the line is reset and then immediately comes back again. It sounds like you have a genuine "No D channel" problem. Are you sure your line is PtMP? You get this sort of error if you mix PtP and PtMP

By: Shaun Ruffell (sruffell) 2009-01-15 10:21:10.000-0600

francesco_r:  There is a module parameter in the wcb4xxp driver, teignorered.  Could you set this to 1 and try again?   It isn't clear if your failures are from d-channel drops, or if your span is going into red alarm.  This could help with the red alarm condition.



By: Francesco Romano (francesco_r) 2009-01-15 13:33:27.000-0600

Ok, i have misinterpreted the pmp_l1_check option. Now if i load the module wcb4xxp with teignorered parameter enabled all works well and all leds are always green. I had to manually edit base.c and recompile the module because if i do "modprobe wc4xxp teignorered=1" i have "wcb4xxp: Unknown parameter `teignorered'".
So to resume: pmp_l1_check works correctly (i have no more layer up/down) and with teignorered if i disconnect the cable from one port to another i can call immediately after the TEI is assigned. But i have still stability problem, asterisk crash often when i connect/reconnect the cable, see PRI-48, and the span remains always up, even if the cable is not connected. So if i try to dial in this span, asterisk try to call-out endlessly.

For example this is the output of "pri show spans":
PRI span 1/0: Provisioned, Up, Active
PRI span 2/0: Provisioned, Down, Active
PRI span 3/0: Provisioned, Down, Active
PRI span 4/0: Provisioned, Up, Active

but in this case the cable is only connected in the port 4.

So if in extensions.conf i have:
exten => _XX.,1,Dial(DAHDI/g0/${EXTEN}) ; bri 1-2
exten => _XX.,1,Dial(DAHDI/g1/${EXTEN}) ; bri 4-5
exten => _XX.,1,Dial(DAHDI/g2/${EXTEN}) ; bri 7-8
exten => _XX.,1,Dial(DAHDI/g3/${EXTEN}) ; bri 10-11

and i dial the number 190, in the console asterisk stay forever in this state:
-- Requested transfer capability: 0x00 - SPEECH
-- Called g0/190
and do not continue to g1 or g2 or g3.

However i think you can close the old ASTERISK-12111 issue i have open sometimes ago.
Thank you

By: Shaun Ruffell (sruffell) 2009-01-15 13:45:15.000-0600

Thanks for testing this.  But just for my own education, what happens if you do not use the teignorered parameter?  Is it that you're board goes into red alarm repeatedly when connected to your telco, or if you unplug a cable and reconnect it, it never comes out of the alarm state?

By: Tim King (timking) 2009-01-22 08:49:24.000-0600

I am now getting some errors which I don't understand.

Firstly DAHDI is reporting that all lines are busy when they are not.
Secondly I sometimes get XXX Message longer than it should be?? XXX from libpri.
Thirdly I get PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1, mostly (but not always) in the middle of the night when the system should be idle.

None of these are reproducible sadly.



By: Francesco Romano (francesco_r) 2009-01-26 11:12:20.000-0600

I have tested the latest libpri release and now problems of PRI-48 are gone but i have other problems with this patch. The biggest problem is that if disconnect the cable the channel stay open forever and in the console i must "soft hangup" the channel. Sometimes, only with this patch, asterisk crash. I have attached a full bt of asterisk-1.6.1 r169082. In all my tests, i loaded the wcb4xxp module without the teignorered option.

By: Digium Subversion (svnbot) 2009-01-27 22:41:03.000-0600

Repository: dahdi
Revision: 5870

U   linux/trunk/drivers/dahdi/wcb4xxp/base.c

------------------------------------------------------------------------
r5870 | sruffell | 2009-01-27 22:41:02 -0600 (Tue, 27 Jan 2009) | 3 lines

Ensure the teignorered parameter is exposed as a module parameter.
Related to issue ASTERISK-13176 .

------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=5870

By: Olivier Krief (okrief) 2009-03-10 06:02:39

I couldn't apply the enclosed patch to asterisk 1.6.0.6 :
cd /usr/src/asterisk-1.6.0.6
wget 'http://bugs.digium.com/file_download.php?file_id=20910&type=bug' -O - | patch -p0

patching file channels/chan_dahdi.c
Hunk #1 succeeded at 428 with fuzz 1 (offset -35 lines).
Hunk #2 succeeded at 1096 (offset 268 lines).
Hunk #3 FAILED at 8971.
Hunk #4 succeeded at 10841 (offset 16 lines).
Hunk ASTERISK-1 FAILED at 14139.
2 out of 5 hunks FAILED -- saving rejects to file channels/chan_dahdi.c.rej

By: snuffy (snuffy) 2009-03-17 06:42:27

I've updated the patch so it should apply correctly..
Let me know how it goes

By: Olivier Krief (okrief) 2009-03-17 07:56:52

I'll do my best to install your patch on a new 1.6.0.6 system.

By: Frederic Van Espen (freh) 2009-03-26 05:35:08

I can confirm this. I have noticed that this warning does not occur when I use "dchan=3" in stead of "hardhdlc=3" in the config file. But then the installation does not work. I also noticed that the warning does not occur while I am making a phonecall. The warning happens every 15 seconds. The call doesn't get interrupted when the warning "should" occur.

snuffy: I have successfully applied the patch. I then added pmp_l1_check=no in chan_dahdi.conf and the warning does not occur anymore

By: Leif Madsen (lmadsen) 2009-06-10 12:37:08

Assigned to snuffy in the hopes we can move this issue forward again. Thanks!

By: Shaun Ruffell (sruffell) 2009-06-10 12:49:02

I hadn't applied this patch because creslin expressed some concern that this isn't the "right" way to go here.

By: Leif Madsen (lmadsen) 2009-06-10 13:33:09

OK, thanks for the update!

By: nenadr (nenadr) 2009-06-17 00:50:28

IMHO, this patch just suppreses console output "D-Channel on span X down" but when span really is in alarm (down) and that happens sometimes, one cannot make outgoing calls. We should try to see what is causing span to go down.

Interesting thing is that if I have incoming call while span is down, it gets up and call makes through to the asterisk and sip phone asterisk directs it to, and after that I can call over that span.

Usualy, span goes down after hangup of either incoming or outgoing call, and goes up again instantly, but I have seen it to go down without apperent reason, or not to come up on asterisk start (but it comes up on incoming call). Hardly reproducable :( (if reproducable at all).

This issue might have something to do with Telco is shuting down PMTP BRI L2 and DC power, afer certain idle period, and a way hows that handled in wcb4xxp/libpri/chan_dahdi.

Tested with dahdi-linux 2.2.0-rc5 (wcb4xxp patched to work with with OpenVoxB400m 4x bri card with patches from 0013897), dahdi-tools-2.2.0-rc3, libpri 1.4.10 and asterisk 1.6.1.1.



By: nenadr (nenadr) 2009-06-17 02:50:33

OK, I've just had a situation when I start asterisk and connected BRI port doesn't go up immediatly, but after a while (this time it was after apx. 40 to 50 seconds, but sometimes it is much longer). Tested on same setup mentioned in note 0106533, telco is Telekom Srbija and NT box asterisk is connected to in PtMP, is Intracom NetMod+. I've started asterisk and same moment I've got prompt I started pri debug span 1, and got this:

*CLI> pri debug span 1
Enabled debugging on span 1
*CLI>
*CLI>
*CLI> Sending TEI management message 1, TEI=127
Sending TEI management message 1, TEI=127
Sending TEI management message 1, TEI=127
Sending TEI management message 1, TEI=127
[Jun 17 09:34:10] NOTICE[11761]: chan_dahdi.c:11077 pri_dchannel: PRI got event: No more alarm (5) on Primary D-channel of span 1
q921.c:852 q921_reset: q921_sate now is Q921_LINK_CONNECTION_RELEASED
Sending TEI management message 1, TEI=127
[Jun 17 09:34:10] NOTICE[11765]: chan_dahdi.c:8227 handle_init_event: Alarm cleared on channel 1
[Jun 17 09:34:10] NOTICE[11765]: chan_dahdi.c:8227 handle_init_event: Alarm cleared on channel 2
Received MDL message
TEI assiged to 113
q921.c:852 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
Sending Set Asynchronous Balanced Mode Extended
q921.c:211 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH
-- Got UA from network peer  Link up.
q921.c:801 q921_dchannel_up: q921_state now is Q921_LINK_CONNECTION_ESTABLISHED
 == Primary D-Channel on span 1 up
Received MDL message
Sending TEI management message 5, TEI=113
Received MDL message
Sending TEI management message 5, TEI=113

Hope this might help.

By: Tim King (timking) 2009-06-17 03:39:08

NT box? If you are connected to the telco surely you need to be in TE mode? You should be getting TEI messages not sending them.

By: nenadr (nenadr) 2009-06-17 04:16:38

@ timking: Yes NT1 box - box where I connect asterisk bri-card ports. Typical setup is like: Telco ->(U-bus/2 wire) NT1Box -> (S/T bus 4 wire, usualy there are 2 ports on it, also provides termination to S/T bus) multiply ISDN TA devices (ISDN phones / ISDN cards in asterisk in TE mode).

This is typical setup here in Serbia, and I saw it also in Austria, Switzerland and in some cases in Germany.

And yes card in asterisk is in bri_cpe_ptmp mode (which is TE mode), and most of the time everything is working OK.

relevant part of my /etc/dahdi/system.conf:
span=1,1,0,ccs,ami
span=2,2,0,ccs,ami
span=3,3,0,ccs,ami
span=4,4,0,ccs,ami
bchan=1,2,4,5,7,8,10,11
hardhdlc=3,6,9,12
alaw=1,2,4,5,7,8,10,11
echocanceller=oslec,1,2,4,5,7,8,10,11

and from /etc/asterisk/chan_dahdi.conf:

context=from-pstn
switchtype=euroisdn
pridialplan=unknown
prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0
localprefix = 011
;privateprefix = 011
unknownprefix =
priindication = outofband
facilityenable = yes
usecallerid=yes
hidecalleridname=yes
usecallingpres=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=no
callgroup=1
callerid=asreceived
mohinterpret=default
mohsuggest=default
group=1
signalling=bri_cpe_ptmp
channel =>1-2
group=2
signalling=bri_cpe_ptmp
channel =>4-5
group=3
signalling=bri_cpe_ptmp
channel =>7-8
group=4
signalling=bri_cpe_ptmp
channel =>10-11

By: nenadr (nenadr) 2009-06-18 12:41:41

Just to report another situation when driver DAHDI goes to red alarm and doesn't know how to recover:

Sometimes (one time in dozen of calls), after succesfull call bri-span goes to RED (pri_find_dchan: No D-channels available!") and doesn't recover from that, but instead console is filled with (it is seen on console with pri debug span 1):

Sending Set Asynchronous Balanced Mode Extended

This can happen for hours or until I either:

1. give "dahdi restart" CLI command, after what console is filled with: "Sending TEI management message 1, TEI=127" in a way I reported in note ASTERISK-1024339.

2. make incoming call to the number on bri-span from some external phone and span gets fixed instatly and connects that same call.

Either way, until 1. or 2. are met I cannot make outbound calls over that bri-span !!!



By: nenadr (nenadr) 2009-06-21 03:49:02

I have uploaded console output (verbose/debug 99, pri debug span 1) for case when dahdi goes to "No D-Chan availible" and recovers from "Sending Set Asynchronous Balanced Mode Extended" ON ITS OWN in relatively short period of time (very rare - usualy it can stay for hours in "Sending SABME", or until incoming call).

Notice, that one cannot make outgooing call until "-- Got UA from network peer  Link up." is diplayed, after that everything is working again.

I have also played with "teignorered" wcb4xxp module param, and when i start dahdi with that param set, I always have all 4 spans of card in status OK (on "dadhi show status"), but when i see "Sending Set Asynchronous Balanced Mode Extended" or "Sending TEI management message 1, TEI=127" repeating on console I still cannot make outgoing calls, and always with a same message:

WARNING[1692]: app_dial.c:1518 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)



By: nenadr (nenadr) 2009-06-22 07:50:40

Uploaded "pri debug intense span 1" when I get bunch of "Sending Set Asynchronous Balanced Mode Extended", after succesfull call.

This time "Sending Set Asynchronous Balanced Mode Extended" was "stopped" only by next incoming call (debug included).

Meybe someone familiar with libPRI should take a look at this because, longer I look at this debugs, more I think that there is a some kind of libPRI misbehaviour regarding re-establishing q921 link and getting TEI from Telco (network).

By: nenadr (nenadr) 2009-06-27 00:36:59

Uploaded "pri debug intense span 1" when I get bunch of "Sending TEI management message 1, TEI=127" on a start of dahdi or after "dahdi restart".

This message can repeat sometimes shotly like in this log, sometimes for a very long time (usualy until i make incoming call to a span)

I think that cause for this is same as for the repeating "Sending Set Asynchronous Balanced Mode Extended", but I cannot pin-point exact cause of problem (mishandling of TEI assingnment procedure in PtMP mode of LibPRI or problem in wcb4xxp driver or chan_dahdi).

Interesting thing is, that in both cases Telco switch is not responding to our unnumbered frames with ("TEI Identity Request" or "SSABME"), for a while or until "it has something to say to us" (in case of incoming call for that BRI, to indicate call).

pri intensive logs of this situations are intense-ssabme.txt and TEIASSIGNMENT.txt



By: nenadr (nenadr) 2009-06-29 04:45:02

I have browsed sources of zaphfc and qozap from bristuff (they are handling same HFC chip), this weekend, and I have noticed something interesting in both drivers in "same piece of code" (handling of HFC chip states), which points me to a thought that there might NOT be a problem with LibPRI in this case, but in fact that telco goes out into IDLE mode and shuts down L1 and power on BRI after a while, and that sends RED alarm to DAHDI. That would explain why BRI span gets in order when new incoming call is generated for that BRI (telco goes "out of IDLE mode" and resumes talking to us). In any case this what I'll explain below, I believe it is worth trying :).

In qozap.c in function ZAP_IRQ_HANDLER(qoz_interrupt) around line 983 there is piece of code that handles TE mode HFC chip states:

                   // TE state machine
                   if (l1state == 3) {
                       qoztmp->st[st].l1up = 0;
                       if (qoztmp->st[st].t3 > -1)  {
                           /* keep layer1 up, if the span is started. */
                           if (qoztmp->spans[st].flags & ZT_FLAG_RUNNING) {
                               if (debug > 2)
                                   printk("qozap: re-activating layer1 span %d\n", st);
                               qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60);
                           }
                       } else {
                               if (debug > 2)
                                   printk("qozap: not re-activating layer1 span %d\n", st);
                               qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x40);
                           /* if we tried to activate layer 1 and it failed make this an alarm */
//                          qoztmp->spans[st].alarms = ZT_ALARM_RED;
//                          zt_alarm_notify(&qoztmp->spans[st]);
                           /* if the network shuts us down in idle mode dont make this an alarm */
                       }


As you can see this code is trying to bring L1 UP if it see that SPAN is configured and running and T3 timer is > -1 (with command qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60); ), and if T3 timer is -1 it doesn't (command qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x40); ),


but in any case it DOESN'T put SPAN in RED alarm (commented part of code).


Now, I believe that equivalent piece of code in wcb4xxp driver is this part of base.c :

In function hfc_handle_state(struct b4xxp_span *s) around line 1392 (in  https://issues.asterisk.org/view.php?id=13897 patched version of base.c)



               switch(sta) {
               default:                        /* Invalid TE state */
               case 0x0:                       /* TE state F0: Reset */
               case 0x2:                       /* TE state F2: Sensing */
               case 0x3:                       /* TE state F3: Deactivated */
               case 0x4:                       /* TE state F4: Awaiting Signal */
               case 0x8:                       /* TE state F8: Lost Framing */
                       s->newalarm = DAHDI_ALARM_RED;
                       break;
               case 0x5:                       /* TE state F5: Identifying Input */
               case 0x6:                       /* TE state F6: Synchronized */
                       s->newalarm = DAHDI_ALARM_YELLOW;
                       break;
               case 0x7:                       /* TE state F7: Activated */
                       s->hfc_timer_on[HFC_T3] = 0;
                       s->newalarm = 0;
                       break;
               }
       }

       s->alarmtimer = b4->ticks + alarmdebounce;
       s->oldstate = state;

       if (DBG_ALARM) {
               dev_info(b4->dev, "span %d: old alarm %d expires %ld, new alarm %d expires %ld\n",
                       s->port + 1, oldalarm, oldtimer, s->newalarm, s->alarmtimer);
       }

/* we only care about T2 expiry in G4. */
       if (nt && (sta == 4) && (state & V_T2_EXP)) {
               if (s->hfc_timer_on[HFC_T2])
                       hfc_timer_expire(s, HFC_T2);    /* handle T2 expiry */
       }

/* If we're in F3 and receiving INFO0, start T3 and jump to F4 */
       if (!nt && (sta == 3) && (state & V_INFO0)) {
               s->hfc_timers[HFC_T3] = b4->ticks + timer_3_ms;
               s->hfc_timer_on[HFC_T3] = 1;
               if (DBG_ST) {
                       dev_info(b4->dev, "port %d: receiving INFO0 in state 3, setting T3 and jumping to F4\n", s->port + 1);
               }
               hfc_force_st_state(b4, s->port, 4, 1);
       }




As you can see for all HFC states in (0,2,3,4 and 8) s->newalarm = DAHDI_ALARM_RED is set, and there is no try to keep L1 UP like in qozap.c with qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60);


Incorporating something like:  qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60);  to a wcb4xxp driver is beyond my programming knowladge, but I think that it could be a good approach to this issue, and if anyone there is willing to make a patch to a wcb4xxp driver with this changes, I'm willing to test it and post results right away.



By: puzzled (puzzled) 2009-07-29 08:05:31

I can confirm nenadr's assumption. In the Netherlands on a BRI connection the telco drops power to the D-channel after a while to save on energy cost. When a new call comes in the telco kickstarts the D-channel again. When you dial out from TE -> telco and the D-channel is down the TE somehow signals the telco to reactivate the D-channel (not sure how). Hope this helps.

By: nenadr (nenadr) 2009-07-30 16:04:05

I have found interesting explanation of ISDN BRI PtMP mode "idle state" on following URL:

http://www.isdn-test.de/ihhe12.htm#Heading37

in section (heading): Activation/Deactivation.

Meybe it can prove usefull for checking wcb4xxp and/or LibPRI regarding this issue.

By: Tim King (timking) 2009-08-07 12:35:58

OK try this. It doesn't seem to break anything on my test rig.
Move case 03 out from where it was.
                       case 0x3:                       /* TE state F3: Deactivated */
                       /* If we're in F3 receiving INFO0, start T3 and jump to F4 */
                       if (state & V_INFO0) {  /* Activate and start timer */
                               b4xxp_setreg_ra(b4, R_ST_SEL, s->port, A_ST_WR_STA, V_ST_ACT_ACTIVATE);
                               s->hfc_timers[HFC_T3] = b4->ticks + timer_3_ms;
                               s->hfc_timer_on[HFC_T3] = 1;
                               if (DBG_ST)
                                       dev_info(b4->dev, "port %d: receiving INFO0 in state 3, setting T3 and jumping to F4\n", s->port + 1);
                               hfc_force_st_state(b4, s->port, 4, 1);
                       }
                       /* Otherwise the network has shut us down */
                       else {
                               b4xxp_setreg_ra(b4, R_ST_SEL, s->port, A_ST_WR_STA, V_ST_ACT_DEACTIVATE);
                               s->hfc_timer_on[HFC_T3] = 0;
                               hfc_force_st_state(b4, s->port, 3, 1);

                       }
                       s->newalarm = 0;
                       break;

and then remove the code in the test for !nt and sta=3 and INFO0 lower down as we have already done it.
V_ST_ACT_(DE)ACTIVATE are the 40 and 60 you see.

By: nenadr (nenadr) 2009-08-07 16:17:18

@timking: Could you please try to make a patch out of what you have said in note 0108778, and upload it here or send it to nenadr@snr.rs ?
I would realy much like to test it but I'm not sure I understand what you suggest in note above.

By: Tim King (timking) 2009-08-10 12:12:21

I just don't think this whole approach is correct. Essentially the network is saying "Disconnect and save power" and we are saying immediately "no go back up again" and this gets repeated every minute. The original patch simply disguises the reporting. Surely we should be staying disconnected? Then reconnect when we need to transmit something, and follow whatever the network will do to start reconnection on an incoming call?

I have tried tinkering in libpri Q921 but I don't really understand how it works. Should I re-file a bug under LibPri?

By: nenadr (nenadr) 2009-08-10 14:28:35

I can confirm that timking patch from note 0108778 is woking for me, for last 16 hours, without a problem !!! :-)

On the other hand, I have to agree with timking that this is a workaround and not a solution for a problem, and that the problem is in a libpri not in driver itself (although this workaround is present in qozap driver from a start ;) ).

Meybe we can make this workaround usable as module parameter, until real solution is found in libpri ?

By: odicha (odicha) 2009-08-18 05:30:40

Hi!
We have using since some months ago a patched 1.4.x ver of chan_dahdi with backport of 1.6 bri functions and a full bri_check patch. Note it's necessary that method you will use cover also TE (ptp) modes because same behaviour is related to non ptmp lines. If you want I can rewrite it for 1.6.x branch. It's not too much code anyway. It's at asterisk-es-rsp svn.

By: Leif Madsen (lmadsen) 2009-09-08 13:47:54

Changing status to Confirmed as we have a working patch to play with, even if it is not necessarily the "solution".

By: Aurelien Guillaume (footplus) 2010-05-25 05:31:44

From what I gather, the proposed patches until now just ask for reactivation of the line whenever the telco deactivates the line. But the real solution would be to keep the line deactivated until we have a call to make. The telco will activate again the line if it has a call to pass.

Is that feature difficult to add ? Does someone has pointers as to what code should be modified (dahdi, chan_dahdi or libpri) ?

By: Terence (mrfreeze) 2010-06-05 18:44:52

We just started having this problem after the server was fine for a few months.  A recent software upgrade was done on it, so it could be related.  It happened a week ago on one server, so I just moved the T1 cables over to an identical server (spare) in case it was a hardware issue.

It happened again last night at 03:44:55 (see log file).

I have attached a full debug of the latest occurence.

We are using a te411p without the echo cancellation module.

The versions of software I am running are:

asterisk version: 1.4.30
dahdi version:    2.3.0
libpri version:   1.4.11
Debian:           2.6.26-2-686

Oh, restarting asterisk didnt not solve the problem.  I had to stop asterisk, restart dahdi, start asterisk.



By: Tim King (timking) 2010-06-06 03:28:40

Terence which country are you in? In the UK the Telco takes the line down after a minute or so, and as others have reported this patch simply raises it again which isn't clever. It sounds like your telco has (recently) taken to dropping the line in the middle of the night. Of course very unlikely you can find anyone in telco who will actually tell you what they are doing. This patch would fix it for you, but as footplus mentions this isn't the correct way forward.

By: Joel Vandal (jvandal) 2010-06-06 07:45:13

Also have this issue since I update libpri from 1.4.4 (very old) to 1.4.11. Each span that aren't connected but configured display a warning message on CLI every few seconds.

asterisk version : 1.4.32
zaptel version : 1.4.12.1
libpri: 1.4.11
CentOS: 5.4

I'm using Xorcom Astribank (XPP) and some ports have no T1/E1 connected. The only way I've found to remove the "unused" ports from Zaptel configuration.

By: Terence (mrfreeze) 2010-06-07 11:28:24

timking: I am from Canada.  It happened again today, but at a much later time of 07:29:32.  I did not set the intense debugging since I restarted but I did notice a few other errors which might be related so I'll see what I can dig up here.

[Jun  7 07:29:05] NOTICE[18611] chan_dahdi.c: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
[Jun  7 07:29:32] ERROR[18611] chan_dahdi.c: PTP MDL can't handle error of type I
[Jun  7 07:29:32] ERROR[18611] chan_dahdi.c: MDL-ERROR (I): T200 = N200 in timer recovery state 8
[Jun  7 07:29:36] VERBOSE[18611] logger.c:   == Primary D-Channel on span 1 down
[Jun  7 07:29:36] WARNING[18611] chan_dahdi.c: No D-channels available!  Using Primary channel 24 as D-channel anyway!
[Jun  7 07:29:40] WARNING[18611] chan_dahdi.c: No D-channels available!  Using Primary channel 24 as D-channel anyway!
[Jun  7 07:29:42] VERBOSE[18611] logger.c:   == Primary D-Channel on span 1 up
[Jun  7 07:29:42] VERBOSE[18611] logger.c:     -- Channel 0/1, span 1 got hangup, cause 27
[Jun  7 07:29:42] VERBOSE[18611] logger.c:     -- Channel 0/2, span 1 got hangup, cause 27
[Jun  7 07:29:42] DEBUG[19900] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/2-1
[Jun  7 07:29:42] DEBUG[19900] chan_dahdi.c: Already hungup...  Calling hangup once, and clearing call
[Jun  7 07:29:42] DEBUG[19900] chan_dahdi.c: Set option AUDIO MODE, value: OFF(0) on DAHDI/2-1
[Jun  7 07:29:42] DEBUG[19899] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/1-1
[Jun  7 07:29:42] DEBUG[19899] chan_dahdi.c: Already hungup...  Calling hangup once, and clearing call
[Jun  7 07:29:42] DEBUG[19899] chan_dahdi.c: Set option AUDIO MODE, value: OFF(0) on DAHDI/1-1
[Jun  7 07:29:42] VERBOSE[19899] logger.c:     -- Hungup 'DAHDI/1-1'
[Jun  7 07:29:44] VERBOSE[18611] logger.c:   == Primary D-Channel on span 1 down
[Jun  7 07:29:44] WARNING[18611] chan_dahdi.c: No D-channels available!  Using Primary channel 24 as D-channel anyway!

By: nongmin (nongmin) 2010-06-11 02:39:11

I have tried this patch with Asterisk-1.6.1.18. But i got the same result.
=====================================================================
[Jun 11 23:37:20] WARNING[8108]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
[Jun 11 23:37:20] WARNING[8108]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
[Jun 11 23:37:20] WARNING[8109]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 6 as D-channel anyway!
[Jun 11 23:37:20] WARNING[8109]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 6 as D-channel anyway!
[Jun 11 23:37:20] WARNING[8110]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 9 as D-channel anyway!
[Jun 11 23:37:20] WARNING[8110]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 9 as D-channel anyway!
[Jun 11 23:37:20] WARNING[8111]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 12 as D-channel anyway!
[Jun 11 23:37:20] WARNING[8111]: chan_dahdi.c:3371 pri_find_dchan: No D-channels available!  Using Primary channel 12 as D-channel anyway!
===============================================================
can anybody help me?
thank you!!

By: Gennady G. Marchenko (zgen) 2010-08-03 07:38:40

I have got same on TE210/TE410 with E1/PRI  two servers

first:
kernel 2.6.26-1
libpri 1.4.7
dahdi 2.1.0.4
asterisk 1.4.30

second
kernel 2.6.26-2
libpri 1.4.11.2
dahdi 2.3.0.1
astrerisk 1.4.33.1

on both cases I have an error "No D-channels available! Using Primary channel NUM as D-channel anyway!"

in different port after correct reboot. Restart Asterisk/dahdi/server doesn't help at all. dahdi_scan reports that all OK, led is green.


Is there any fix for it?

By: Terence (mrfreeze) 2010-08-10 11:54:20

I changed from a te410 to a te412 and was still getting the "No D-channels available!" errors ocassionally.

When I changed from libpri 1.4.11.x to libpri 1.4.10.2, it fixed the problem of "No D-channels available!".

If anyone is still stuck, try version 1.4.10.2 if you can.

Also, mods feel free to remove my terence_debug.txt above.



By: Alec Davis (alecdavis) 2010-08-11 04:55:56

deleted terence_debug.txt as requested

By: Anthony H (ahave) 2010-08-27 10:51:22

I have the same issue with B410P card.
I downgrade the libpri version to 1.4.9.

These messages don't appear since I installed libpri 1.4.9

By: Anthony H (ahave) 2010-09-13 12:13:21

I try the patch note (0108778)from timking. It's works fine with libpri < 1.4.11

So, in Europe, telco use power safe. When a call is finished, the D-channel shut down...
With Dahdi or libpri, how is possible to use power saving?
Which paramters I must change for that?
It's the same think than puzzled note: (0108344)

By: antonio (antonio) 2011-01-01 05:31:49.000-0600

I am experiencing the same problems. Am forced to use libpri 1.4.11.5 due to other bugs. Did someone make any progress on this issue? Can someone post timking patch from note 0108778 as a patch please?

By: Anthony H (ahave) 2011-01-23 13:35:19.000-0600

The same results with asterisk 1.8.2.2

By: Jegor (jpvis) 2011-05-18 07:56:56

Hello,

I have installed libpri 1.4.11.5 DAHDI Complete 2.4.1.2+2.4.1 and Asterisk 1.8.3.2
And I have the same problem.

But I have tried to downgrade it to libpri 1.4.10.2 and after all compilations chan_dahdi cannot suport BRI at all. In verbose I can see error than signaling bri_cpe is unknown.

Maybe somebody knows how to recompile all modules for asterisk correctly ?

By: Nickilo ( ThinkroSystem) (nickilo) 2011-05-25 17:24:54

Hello,

I have the same problem.

As jpvis said, it's impossible to build asterisk 1.8 with libpri 1.4.10.2.

I'm gonna try with libpri svn 1177, which is the first building with asterisk 1.8.

I think it's a major issue, because we cannot use asterisk 1.8.

By: puzzled (puzzled) 2012-05-10 18:40:19.245-0500

FYI: today (May 11, 2012) Digium's Kevin P. Fleming reported the following on the Asterisk mailing list: "There are patches in the works already (being tested by users in Europe) to deal with this layer 1 issue. Upcoming releases of DAHDI and Asterisk should have support for it.".


By: Richard Mudgett (rmudgett) 2012-05-10 19:04:52.980-0500

See commits for chan_dahdi layer1_presence option:
-r362430 Asterisk trunk
-r362429 Asterisk v10
-r362428 Asterisk v1.8
-r10661 and -r10662 DAHDI linux/trunk

By: Richard Mudgett (rmudgett) 2012-06-04 17:11:01.210-0500

The chan_dahdi layer1_presence option is the fix for Asterisk.  The DAHDI commits mentioned above help with starting layer 1 as needed.