[Home]

Summary:ASTERISK-13293: [patch] UK (BT) lines produce uncleared red alarm on TDM400P during line tests
Reporter:Jeremy Burton (jedi98)Labels:
Date Opened:2009-01-02 10:29:55.000-0600Date Closed:2010-03-11 09:33:07.000-0600
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.6.1.6-bt-line-test.patch
( 1) asterisk-1.6.2.0-bt-line-test.patch
( 2) chan_dahdi-1.4-inalarm.diff
Description:Asterisk: 1.4.22, dahdi-linux: 2.1.0.3

The automatic overnight line tests (or manual ones) used on UK (BT) lines causes a red alarm on a dahdi / TDM400P connected channel. This is because the line uses voltage tests (battery loss) and polarity reversal. The polarity reversal causes chan_dahdi to initiate v23 CallerID processing but during this the event DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.

All this means that the channel is unusable until a "dahdi restart" occurs.

I have a patch for chan_dahdi which works well for me but it's not the nicest solution an it needs more people to test / refine. I will attach the patch.

Syslog: -
Dec 29 22:09:56 39net-server2 kernel: NO BATTERY on 1/3!
Dec 29 22:09:58 39net-server2 kernel: 436822404 Polarity reversed (-1 -> 1)
Dec 29 22:09:58 39net-server2 kernel: BATTERY on 1/3 (+)!
Dec 29 22:10:00 39net-server2 kernel: NO BATTERY on 1/3!
Dec 29 22:10:02 39net-server2 kernel: 436823620 Polarity reversed (1 -> -1)
Dec 29 22:10:03 39net-server2 kernel: BATTERY on 1/3 (-)!
Dec 29 22:10:05 39net-server2 kernel: NO BATTERY on 1/3!
Dec 29 22:10:05 39net-server2 kernel: 436824308 Polarity reversed (-1 -> 1)
Dec 29 22:10:07 39net-server2 kernel: BATTERY on 1/3 (-)!
Dec 29 22:10:07 39net-server2 kernel: 436824688 Polarity reversed (1 -> -1)

Asterisk log: -
[Dec 29 22:09:57] WARNING[10309]: chan_dahdi.c:3784 handle_alarms: Detected alarm on channel 3: Red Alarm
 == Starting post polarity CID detection on channel 3
   -- Starting simple switch on 'DAHDI/3-1'
[Dec 29 22:09:59] NOTICE[10332]: chan_dahdi.c:6319 ss_thread: Got event 5 (No more alarm)...
[Dec 29 22:10:01] WARNING[10332]: chan_dahdi.c:6380 ss_thread: CID timed out waiting for ring. Exiting simple switch
   -- Hungup 'DAHDI/3-1'
[Dec 29 22:10:01] WARNING[10309]: chan_dahdi.c:3784 handle_alarms: Detected alarm on channel 3: Red Alarm
 == Starting post polarity CID detection on channel 3
   -- Starting simple switch on 'DAHDI/3-1'
[Dec 29 22:10:03] NOTICE[10333]: chan_dahdi.c:6319 ss_thread: Got event 5 (No more alarm)...
[Dec 29 22:10:06] WARNING[10333]: chan_dahdi.c:6380 ss_thread: CID timed out waiting for ring. Exiting simple switch
   -- Hungup 'DAHDI/3-1'
[Dec 29 22:10:06] WARNING[10309]: chan_dahdi.c:3784 handle_alarms: Detected alarm on channel 3: Red Alarm
 == Starting post polarity CID detection on channel 3
   -- Starting simple switch on 'DAHDI/3-1'
[Dec 29 22:10:08] NOTICE[10334]: chan_dahdi.c:6319 ss_thread: Got event 5 (No more alarm)...
[Dec 29 22:10:10] WARNING[10334]: chan_dahdi.c:6380 ss_thread: CID timed out waiting for ring. Exiting simple switch


****** ADDITIONAL INFORMATION ******

Fault can be triggered on BT lines by initiating a line check from their web site. Though I imagine that they may get mad if this is over used.

This issue did not exist before channel alarms were added to chan_dahdi at about 1.4.22 simply because asterisk never 'saw' the alarms before.
Comments:By: Jeremy Burton (jedi98) 2009-01-02 10:41:56.000-0600

The patch is a bit over zealous, it fixes 4 potential places in chan_dahdi where this problem can occur, however, only one REALLY causes this issue as reported.
By: Leif Madsen (lmadsen) 2009-01-06 08:53:26.000-0600

Assigning this issue to sruffell to keep him in the loop about this issue. Also changed the status to confirmed as the reporter has attached an initial version of the patch that possibly solves the issue.
By: Matt Brown (mattbrown) 2009-04-06 04:13:47

I can confirm I am also seeing this issue on a TDM400P using dahdi-linux: 2.1.0.3 and Asterisk 1.4.24.

asterisk/messages:[Apr  3 04:28:42] NOTICE[26935] chan_dahdi.c: Got event 4 (Alarm)...
asterisk/messages:[Apr  3 04:28:44] WARNING[26935] chan_dahdi.c: Detected alarm on channel 1: Red Alarm
asterisk/messages:[Apr  3 04:28:50] NOTICE[26936] chan_dahdi.c: Got event 5 (No more alarm)...
asterisk/messages:[Apr  4 04:06:08] NOTICE[10082] chan_dahdi.c: Got event 4 (Alarm)...
asterisk/messages:[Apr  4 04:06:10] WARNING[10082] chan_dahdi.c: Detected alarm on channel 1: Red Alarm
asterisk/messages:[Apr  4 04:06:20] NOTICE[10084] chan_dahdi.c: Got event 5 (No more alarm)...
By: Matt Brown (mattbrown) 2009-04-08 13:06:10

I have applied the patch above and this has resolved the issue for me. I have not had to restart DAHDI for the last 2 days. Thanks Jedi98
By: Leif Madsen (lmadsen) 2009-04-09 12:35:27

Marking Ready for Review as we have a report of this patch resolving the issue for someone!
By: Tim King (timking) 2009-04-13 12:21:48

Thanks for this I was tripping over this with 1.6.0.n.

Fellow Brits - I have used a patch around this bit of the code for some time that lets me get the CLI reliably from BT - can you get CLI reliably with the standard code? If not I could include it here....
By: Jeremy Burton (jedi98) 2009-04-13 13:10:16

There's a bug report (12531) for "UK CallerID on TDM400P not reliable".

By the way, if you have a patch for UK CID that has this comment in it "/* Ignore ring before end of cid 'slot' (955ms = 7640 @ 8K samples/sec) */", then it's probably the one I wrote back in mid 2006 and have used ever since.
By: Matt Brown (mattbrown) 2009-04-13 13:26:29

I raised that bug a while back, but I must admit since changing to Zaptel 1.4.12.1and using opermode=UK fwringdetect=1 in modprobe.d/options it seems to work very reliably now.

I will update the other ticket with my findings.
By: Tim King (timking) 2009-04-13 16:58:19

the one if found (and thanks if it was you) was
if (res==2 && samples<7640)  { log something } else { ignore stuff }
Still good idea to try and nail this once and for all.
I haven't tried fwringdetect=1 what about you jedi98?
By: Ben Brown (benbrown) 2009-07-22 14:51:39

I recently updated to asterisk 1.6.1.1 and dahdi 2.2.0.

Needed to apply this patch (needed modifying to apply cleanly to 1.6.1) to avoid the issue of the daily BT line test putting the channel in alarm.

BT CID working OK for last year with unpatch Asterisk/DAHDI configured as:

modprobe.conf:
opermode=uk fwringdetect=1 batthresh=4

chan_dahdi.conf:
usecallerid=yes
cidsignalling=v23
cidstart=polarity
hanguponpolarityswitch=yes

battthresh and hanguponpolarityswitch required otherwise phone continues to ring if the caller hangs up.
By: Tony Vroon (chainsaw) 2009-10-26 08:26:23

Still an issue on Asterisk 1.6.1.6 with DAHDI 2.2.0.2; log entries during line test:
[Oct 25 22:25:28] NOTICE[23965] chan_dahdi.c: Got event 4 (Alarm)...
[Oct 25 22:25:29] NOTICE[23965] chan_dahdi.c: Alarm cleared on channel 1
[Oct 25 22:25:30] WARNING[23965] chan_dahdi.c: Detected alarm on channel 1: Red Alarm
[Oct 25 22:25:30] WARNING[23965] chan_dahdi.c: Hangup received waiting for ring. Exiting simple switch
[Oct 25 22:25:32] NOTICE[24073] chan_dahdi.c: Got event 17 (Polarity Reversal)...
[Oct 25 22:25:34] WARNING[24073] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch
[Oct 25 22:25:35] NOTICE[24128] chan_dahdi.c: Got event 5 (No more alarm)...
[Oct 25 22:25:37] WARNING[24128] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch

Any call afterwards:
[Oct 26 10:30:44] NOTICE[19973] chan_dahdi.c: Got event 2 (Ring/Answered)...
[Oct 26 10:30:46] WARNING[19973] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch
[Oct 26 10:31:10] WARNING[20263] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch

The channel remains wedged until a DAHDI restart. I have forward-ported the attached patch so it applies cleanly. Please consider applying it as it is still required for production running in the United Kingdom.
By: Ben Brown (benbrown) 2009-11-03 13:36:57.000-0600

Supplied patch works great on 1.6.1.6

[Nov  3 01:24:10] NOTICE[31214] chan_dahdi.c: Got event 4 (Alarm)...
[Nov  3 01:24:11] NOTICE[31214] chan_dahdi.c: Alarm cleared on channel 3
[Nov  3 01:24:12] WARNING[31214] chan_dahdi.c: Detected alarm on channel 3: Red Alarm
[Nov  3 01:24:12] WARNING[31214] chan_dahdi.c: Hangup received waiting for ring. Exiting simple switch
[Nov  3 01:24:13] NOTICE[31216] chan_dahdi.c: Got event 17 (Polarity Reversal)...
[Nov  3 01:24:15] WARNING[31216] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch
[Nov  3 01:24:17] NOTICE[31217] chan_dahdi.c: Got event 5 (No more alarm)...
[Nov  3 01:24:19] WARNING[31217] chan_dahdi.c: CID timed out waiting for ring. Exiting simple switch
By: Tony Vroon (chainsaw) 2009-12-01 05:13:29.000-0600

Patch still required on 1.6.1.11; no rebase necessary.
By: mikeeccleston (mikeeccleston) 2009-12-11 04:12:22.000-0600

We have had a problem with a TDM400 card with 3 POT BT lines.
The CID was detected correctly but randomly the call was then not passed on to the call plan. Asterisk had to be restarted to solve the problem.
I have applied the patch for Asterisk 1.4 chan_dahdi to version 1.4.27.1 which patched, compiled and installed correctly.
The patch seems to have resolved the problem as the asterisk server has been running for a week without problem on the TDM400 card with the 3 POT lines.

The same card was running OK in Asterisk 1.2.

This problem also occurred on a TDM410 as well but have not tested it yet with the patch.

Thanks for the patch.


By: Tony Vroon (chainsaw) 2009-12-19 11:43:06.000-0600

Still required on 1.6.1.12; no rebase required.
By: Tony Vroon (chainsaw) 2010-01-04 08:15:30.000-0600

Still required on 1.6.2.0; rebase required and done. Will attach.
By: Tony Vroon (chainsaw) 2010-01-19 18:22:26.000-0600

Still required on 1.6.2.1; rebase not required.
By: Shaun Ruffell (sruffell) 2010-01-19 19:13:54.000-0600

Chainsaw pinged me on IRC and I looked at the patches.  Functionally, they are pretty straightforward, but I would just like to simulate the "line-test" condition in the lab here and test it out before applying (if I can simulate the line-test, but I believe I'll be able to ).
By: Matt Brown (mattbrown) 2010-01-20 08:18:11.000-0600

I can confirm the patch is still required and resolved the line-test alarm issue. (Has done for some time now)
By: Tzafrir Cohen (tzafrir) 2010-01-21 08:35:24.000-0600

I'm not completely happy with duplicating functionality from dahdi_handle_event . For example, what happens if we happen to get a DAHDI_EVENT_ALARM at exactly that point?
By: Tony Vroon (chainsaw) 2010-02-03 05:46:26.000-0600

Still required on 1.6.2.2; rebase not required.
By: Leif Madsen (lmadsen) 2010-02-10 14:49:29.000-0600

I'm marking this as a Blocker for the next set of releases because we really need to do something with this.
By: Tony Vroon (chainsaw) 2010-02-22 11:30:23.000-0600

Still required on 1.6.2.4; rebase not required.
By: Digium Subversion (svnbot) 2010-03-03 13:04:12.000-0600

Repository: asterisk
Revision: 250480

U   branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines

Make sure to clear red alarm after polarity reversal.

From the issue:
The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
a red alarm on a dahdi / TDM400P connected channel. This is because the line
uses voltage tests (battery loss) and polarity reversal. The polarity reversal
causes chan_dahdi to initiate v23 CallerID processing but during this the event
DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.

(closes issue ASTERISK-13293)
Reported by: jedi98
Patches:
     chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
Tested by: mattbrown, Chainsaw, mikeeccleston

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

http://svn.digium.com/view/asterisk?view=rev&revision=250480
By: Digium Subversion (svnbot) 2010-03-03 13:06:07.000-0600

Repository: asterisk
Revision: 250481

_U  trunk/
U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_analog.c

------------------------------------------------------------------------
r250481 | jpeeler | 2010-03-03 13:06:07 -0600 (Wed, 03 Mar 2010) | 22 lines

Merged revisions 250480 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
 
 Make sure to clear red alarm after polarity reversal.
 
 From the issue:
 The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
 a red alarm on a dahdi / TDM400P connected channel. This is because the line
 uses voltage tests (battery loss) and polarity reversal. The polarity reversal
 causes chan_dahdi to initiate v23 CallerID processing but during this the event
 DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
 
 (closes issue ASTERISK-13293)
 Reported by: jedi98
 Patches:
       chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
 Tested by: mattbrown, Chainsaw, mikeeccleston
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=250481
By: Digium Subversion (svnbot) 2010-03-03 13:07:50.000-0600

Repository: asterisk
Revision: 250482

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_dahdi.c

------------------------------------------------------------------------
r250482 | jpeeler | 2010-03-03 13:07:49 -0600 (Wed, 03 Mar 2010) | 29 lines

Merged revisions 250481 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r250481 | jpeeler | 2010-03-03 13:06:06 -0600 (Wed, 03 Mar 2010) | 22 lines
 
 Merged revisions 250480 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
   
   Make sure to clear red alarm after polarity reversal.
   
   From the issue:
   The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
   a red alarm on a dahdi / TDM400P connected channel. This is because the line
   uses voltage tests (battery loss) and polarity reversal. The polarity reversal
   causes chan_dahdi to initiate v23 CallerID processing but during this the event
   DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
   
   (closes issue ASTERISK-13293)
   Reported by: jedi98
   Patches:
         chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
   Tested by: mattbrown, Chainsaw, mikeeccleston
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=250482
By: Digium Subversion (svnbot) 2010-03-03 13:09:22.000-0600

Repository: asterisk
Revision: 250483

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_dahdi.c

------------------------------------------------------------------------
r250483 | jpeeler | 2010-03-03 13:09:22 -0600 (Wed, 03 Mar 2010) | 29 lines

Merged revisions 250481 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r250481 | jpeeler | 2010-03-03 13:06:06 -0600 (Wed, 03 Mar 2010) | 22 lines
 
 Merged revisions 250480 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
   
   Make sure to clear red alarm after polarity reversal.
   
   From the issue:
   The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
   a red alarm on a dahdi / TDM400P connected channel. This is because the line
   uses voltage tests (battery loss) and polarity reversal. The polarity reversal
   causes chan_dahdi to initiate v23 CallerID processing but during this the event
   DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
   
   (closes issue ASTERISK-13293)
   Reported by: jedi98
   Patches:
         chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
   Tested by: mattbrown, Chainsaw, mikeeccleston
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=250483
By: Digium Subversion (svnbot) 2010-03-03 13:13:36.000-0600

Repository: asterisk
Revision: 250484

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r250484 | jpeeler | 2010-03-03 13:13:36 -0600 (Wed, 03 Mar 2010) | 29 lines

Merged revisions 250481 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r250481 | jpeeler | 2010-03-03 13:06:06 -0600 (Wed, 03 Mar 2010) | 22 lines
 
 Merged revisions 250480 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
   
   Make sure to clear red alarm after polarity reversal.
   
   From the issue:
   The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
   a red alarm on a dahdi / TDM400P connected channel. This is because the line
   uses voltage tests (battery loss) and polarity reversal. The polarity reversal
   causes chan_dahdi to initiate v23 CallerID processing but during this the event
   DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
   
   (closes issue ASTERISK-13293)
   Reported by: jedi98
   Patches:
         chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
   Tested by: mattbrown, Chainsaw, mikeeccleston
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=250484