[asterisk-users] Dahdi interface flapping

[Andre Goree]

On Fri, Aug 2, 2013 at 12:29 PM, Shaun Ruffell <sruffell at digium.com> wrote:
> On Fri, Aug 02, 2013 at 10:12:54AM -0400, Andre Goree wrote:
>>
>> Ran through a loopback test with Digium which seemingly proved that
>> there was no issue with their card.  I've contacted my telco for
>> assistance but so far have been unable to come up with
>> anything...though there may be a timing slip issue.  In any case, the
>> D-channel will indeed come up, but then after a while (at non-regular
>> intervals), the D-channel goes down after this message in the logs:
>> [2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1
>> [2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC Bad FCS (8) on D-channel of span 1
>> ...
>> [2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (F): SABME in state 7(Multi-frame established)
>> [2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (F): SABME in state 7(Multi-frame established)
>> [2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer recovery)
>> [2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer recovery)
>>
>> In the meantime I've been trying to adjust smp_affinity for the te133
>> IRQ (just for the hell of it and the fact that I'm running out of
>> things to try)  but it apparently it's being reset automatically by
>> something.  I.e., I'll run this:
>> [root at asterisk-master ~]# echo 8 > /proc/irq/31/smp_affinity
>> [root at asterisk-master ~]# cat /proc/irq/31/smp_affinity
>> 08
>>
>> but then, 5-10 secs later:
>> [root at asterisk-master ~]# cat /proc/irq/31/smp_affinity
>> 01
>>
>> Have you ever seen something like that?
>
> irqbalance will adjust the smp_affinity of interrupts. If you shut
> it down you should be able to run your test.

OMG I remember disabling that before when testing, must've slipped my
mind this time...doh!

>> I'm using brand-newish hardware w/both the server and the card, so
>> I wouldn't be surprised if I've run into some sort of new issue.
>> I'm about to shut the server down now and give the BIOS settings a
>> once-over just to make sure I'm not actually running into
>> something weird hardware-wise.
>
> Although, patlooptest ran clean. It's most likely either a)
> misconfiguration between the card settings and the provider b)
> cabling between the card and the smart jack or c) Just something bad
> on the provider's end. The probability of it being system / hardware
> related is low IMO.
>
> I take it though your old install still works fine? What was the
> reason you're replacing the old install anyway?

Asterisk 1.0.11.x  on a CentOS 4 box -> Asterisk 11.4.x on CentOS6 was
the reason...just old archaic unsupported system that needed to be
upgraded to a supported LTS version and OS + GUI (FreePBX in my case).
 And I thought the hardest part would be the complete rebuild of the
dialplan!  :/

>The last two companies I have worked for have both had this problem with a BT ISDN30 line at some point.
>I also manage SS7 interconnects and its not >unusual for there to be issues with them either. So dont assume its probably at your end :P

Thanks, this happens to be an Adtran MX2800 -- that no one knows to
whom or where it's connected on the far end.  I've gotten as far as I
can with the Telco who actually owns the equipment DS1...unfortunately
I'm at a loss as to wtf owns the other end and can thus assist in
testing (as is the co. who owns the T1), which doesn't make a lot of
sense.  But alas, here I am -___-

Thanks all for your input.