B[248]00X cards,wcb4xxp driver and dahdi/libpri

Hello !

I'm trying to make my B400M card work correctly with asterisk 1.6.1.1, DADHI-linux-2.2.0-rc5, DADHI-tools-2.2.0-rc3 and libpri-1.4.10 in PtMP mode.

I have patched wc4xxb driver with a patch from https://issues.asterisk.org/view.php?id=13897 , and most of the time everything is working OK, but this setup has two big issues:

1. afer a successfull inbound or outbound call over BRI span sometimes I get "pri_find_dchan: No D-channels available!" and I cannot dial over that span until I receive new inbound call on that span, when situatiuon "auto-fixes" (even if I don't answer that call).
If I set "pri debug span x" for that span in problem I see bunch of repeating "Sending Set Asynchronous Balanced Mode Extended" messages.

Note that patch for chan_dahdi in https://issues.asterisk.org/view.php?id=14031 doesn't fix that issue, but just don't display outputs for "pri_find_dchan: No D-channels available!" and D-Channle UP/DOWN events if span is configured as BRI PtMP mode.

2. Sometimes after start of DAHDI module in asterisk span doesn't get UP and if "pri debug span X" is on I get bunch of "Sending TEI management message 1, TEI=127", and BRI is unusable - I cannot dial over it. That can last for:
a) a long time but eventualy it fixes itself (sometimes hours pass)
b) until new incoming call is indicated by telco
Issue 2. happens more frequently if dahdi is started/restarted when Telco BRI line is in IDLE mode (no incoming/outgoing calls for a long time).

I think that problems are related, and that there is a problem somewere in LibPRI, in TEI assignment routines for BRI PtMP mode, judging by PRI INTENSIVE DEBUG SPAN 1 logs I have posted in https://issues.asterisk.org/view.php?id=14031 (files intense-ssabme.txt ( https://issues.asterisk.org/file_download.php?file_id=23072&type=bug ) for issue 1, and file TEIASSIGNMENT.txt ( https://issues.asterisk.org/file_download.php?file_id=23130&type=bug ) for issue 2).

Feel free to check my thoughts on subject in https://issues.asterisk.org/view.php?id=14031 .

Interesting thing is, that in both cases Telco switch is not responding to our unnumbered frames with aither "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).

Is there any solution/help for this ?

Kind regards,
Nenad Radosavljevic

hello:
I am not sure the code you download is completed or not? please refer this:
http://bbs.openvox.cn/viewthread.php?tid=781&extra=page%3D1
regards!
James.zhu

Yes ! I have saw and analyzed those patches and there is nothing in those patches different from my described setup, and I'm pretty sure that this problem will arise with those patches sooner or later (and it will be masked and harder to figure out since there is no_l1_check option wich disables Chan D Up/Down messages on console).

I have browsed sources of zaphfc and qozap from bristuff and I have noticed something interesting 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 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 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 issues I explained, 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.

Kind regards,
Nenad Radosavljevic