[Home]

Summary:DAHLIN-00121: After the system reboot calls do not go out on TDM410P FXO channels until an incoming call comes in
Reporter:Vladimir Mikhelson (vmikhelson)Labels:
Date Opened:2009-07-01 01:35:52Date Closed:2009-08-13 19:46:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:wctdm24xxp
Versions:2.1.0.4 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:After the system reboot any attempt to dial out on DAHDI FXO line fails. The normal functionality is restored after the first call comes in that FXO line.


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

Asterisk 1.6.0.10
DAHDI 2.1.0.4

dahdi show status output:
Description                              Alarms  IRQ    bpviol CRC4   Fra Codi Options  LBO
Wildcard TDM410P Board 1                 OK      1      0      0      CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)
Wildcard TDM400P REV I Board 5           OK      0      0      0      CAS Unk  YEL      0 db (CSU)/0-133 feet (DSX-1)

Initially dahdi_tool shows the right number of Total (4) and Configured (3) channels, but shows 0 Active channels. After the first call comes in it shows 1 Active. This is correct since I have 3 FXO cards and just one PSTN line connected.

Outbound Route Trunk Sequence: DAHDI/1, then DAHDI/2.

Unsuccessful call flow log segment:

[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- <DAHDI/8-1>AGI Script fixlocalprefix completed, returning 0
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk:13]  Set (" DAHDI/8-1 ", " OUTNUM=18475551212 ") in new stack
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk:14]  Set (" DAHDI/8-1 ", " custom=DAHDI/2 ") in new stack
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk:15]  ExecIf (" DAHDI/8-1 ", " 0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^)) ") in new stack
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk:16]  Macro (" DAHDI/8-1 ", " dialout-trunk-predial-hook, ") in new stack
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk-predial-hook:1]  MacroExit (" DAHDI/8-1 ", "  ") in new stack
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk:17]  GotoIf (" DAHDI/8-1 ", " 0?bypass,1 ") in new stack
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk:18]  GotoIf (" DAHDI/8-1 ", " 0?customtrunk ") in new stack
[Jul 1 00:41:35] VERBOSE[3962] logger.c: -- Executing [s@macro-dialout-trunk:19]  Dial (" DAHDI/8-1 ", " DAHDI/2/18475551212,300, ") in new stack
[Jul 1 00:41:35] WARNING[3962] app_dial.c: Unable to create channel of type 'DAHDI' (cause 0 - Unknown)
[Jul 1 00:41:35] VERBOSE[3962] logger.c: == Everyone is busy/congested at this time (1:0/0/1)


Successful call flow log segment:

Jul 1 01:05:45] VERBOSE[4141] logger.c: -- <DAHDI/8-1>AGI Script fixlocalprefix completed, returning 0
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk:13]  Set (" DAHDI/8-1 ", " OUTNUM=18475551212 ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk:14]  Set (" DAHDI/8-1 ", " custom=DAHDI/1 ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk:15]  ExecIf (" DAHDI/8-1 ", " 0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^)) ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk:16]  Macro (" DAHDI/8-1 ", " dialout-trunk-predial-hook, ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk-predial-hook:1]  MacroExit (" DAHDI/8-1 ", "  ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk:17]  GotoIf (" DAHDI/8-1 ", " 0?bypass,1 ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk:18]  GotoIf (" DAHDI/8-1 ", " 0?customtrunk ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Executing [s@macro-dialout-trunk:19]  Dial (" DAHDI/8-1 ", " DAHDI/1/18475551212,300, ") in new stack
[Jul 1 01:05:45] VERBOSE[4141] logger.c: -- Called 1/18475551212
[Jul 1 01:05:48] VERBOSE[4141] logger.c: -- DAHDI/1-1 answered DAHDI/8-1
[Jul 1 01:05:48] VERBOSE[4141] logger.c: -- Native bridging DAHDI/8-1 and DAHDI/1-1
Comments:By: Shaun Ruffell (sruffell) 2009-07-02 09:31:18

Closing this as a duplicate of 14577.
By: Vladimir Mikhelson (vmikhelson) 2009-07-02 12:38:19

sruffell: Thank you for identifying this one as a duplicate.

Unfortunately, ASTERISK-13673 does not specify the product version.

Can you please advise whether the "[PATCH] wctdm24xxp: Detect if our hookstate has been set back to the initial state" can be applied to DAHDI 2.1.0.4?

Please confirm that other two (2) patches are not applicable to my case.

Thank you,
Vladimir

By: Shaun Ruffell (sruffell) 2009-07-02 15:00:51

Yes... 0001-wctdm24xxp-Detect-if-our-hookstate-has-been-set-bac.patch will apply to 2.1.0.4.

wget 'https://issues.asterisk.org/file_download.php?file_id=22725&type=bug' -O - | patch -p1

And no, you do not need the other two patches.
By: Vladimir Mikhelson (vmikhelson) 2009-07-02 21:14:52

Tried applying the patch. Ran into two problems.

1. Link in comment ASTERISK-1031264 produces "Access Denied." and asks for authentication. Clicking on "Click here to login" or on "Click here to proceed" brings a user to the issues tracking Home Page. It makes impossible reviewing the patch prior to installing.

2. Attempt to apply the patch to the released version 2.0.1.4 produced the following:

can't find file to patch at input line 20
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|From 788d21e9724516bab68d62d1567b7ab06c060561 Mon Sep 17 00:00:00 2001
|From: Shaun Ruffell <sruffell@digium.com>
|Date: Wed, 20 May 2009 15:10:12 -0500
|Subject: [PATCH] wctdm24xxp: Detect if our hookstate has been set back to the i                nitial state.
|
|Check if our hookstate has been set back to the initial state, typically the
|result of a chanconfig, and if so, if we're an FXO port, forget our current
|battery state.  This allows the driver to determine and report again what the
|hook state of the port is.
|
|(related to issue ASTERISK-13673)
|---
| drivers/dahdi/wctdm24xxp/base.c |    7 +++++++
| 1 files changed, 7 insertions(+), 0 deletions(-)
|
|diff --git a/drivers/dahdi/wctdm24xxp/base.c b/drivers/dahdi/wctdm24xxp/base.c
|index c4d6b12..eb39d18 100644
|--- a/drivers/dahdi/wctdm24xxp/base.c
|+++ b/drivers/dahdi/wctdm24xxp/base.c
--------------------------
File to patch:

Please advise.  I thought about applying the patch manually, but discovered a different code around line 1403.

Thank you,
Vladimir
By: Shaun Ruffell (sruffell) 2009-07-05 13:23:24

I think it was a Mantis formatting issue.  Here is the output of my session where I applied the path:

<pre>
[sruffell@ragdoll dahdi-linux-2.1.0.4]$ wget 'https://issues.asterisk.org/file_download.php?file_id=22725&type=bug' -O - | patch -p1
--2009-07-05 13:21:41--  https://issues.asterisk.org/file_download.php?file_id=22725&type=bug
Resolving issues.asterisk.org... 76.164.171.231
Connecting to issues.asterisk.org|76.164.171.231|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1323 (1.3K) [text/plain]
Saving to: `STDOUT'

100%[======================================================================>] 1,323       --.-K/s   in 0.002s

2009-07-05 13:21:41 (542 KB/s) - `-' saved [1323/1323]

patching file drivers/dahdi/wctdm24xxp/base.c
Hunk #1 succeeded at 1240 (offset -163 lines).
[sruffell@ragdoll dahdi-linux-2.1.0.4]$
</pre>


By: Vladimir Mikhelson (vmikhelson) 2009-07-05 16:41:12

It worked. Thank you. Formatting was off in the original patch.

The patch fixed the FXO channel outbound unavailability issue after reboot.

You can close the case now.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2009-07-31 00:04:31

Tested the same patch on DAHDI 2.2 branch.

DAHDI Version: SVN-branch-2.2-r6864M.

Before the patch was applied experienced the same problem as with DAHDI 2.1.0.4,

After the patch application everything worked as it should.

Interestingly enough, tried to use the wget code from issue ASTERISK-1442577, and ran into the same problem as described in note ASTERISK-1031379, i.e. failed to apply the patch. Compared with the code in note ASTERISK-1031608, discovered "....patch -p1" vs. "....patch -p0"  Used "-p1" and everything worked.

Thank you,
Vladimir
By: TOC Jason (toc) 2009-08-11 06:44:32

I was also a victim of this very issue, in 2.2.0.2.

The errors during make and make install are below:
Make:
WARNING: could not find /home/dahdi-linux-2.2.0.2/drivers/dahdi/vpmadt032_loader/.vpmadt032_x86_32.o.cmd for /home/dahdi-linux-2.2.0.2/drivers/dahdi/vpmadt032_loader/vpmadt032_x86_32.o

Make Install:
Building modules, stage 2.
 MODPOST
WARNING: could not find /home/dahdi-linux-2.2.0.2/drivers/dahdi/vpmadt032_loader/.vpmadt032_x86_32.o.cmd for /home/dahdi-linux-2.2.0.2/drivers/dahdi/vpmadt032_loader/vpmadt032_x86_32.o

(The above errors still appeared after the patch was applied).

Once patched, the inability to make calls after a reboot was resolved however.
By: Digium Subversion (svnbot) 2009-08-13 19:46:54

Repository: dahdi
Revision: 7003

U   linux/trunk/drivers/dahdi/wctdm.c
U   linux/trunk/drivers/dahdi/wctdm24xxp/base.c

------------------------------------------------------------------------
r7003 | sruffell | 2009-08-13 19:46:51 -0500 (Thu, 13 Aug 2009) | 9 lines

wctdm24xxp, wctdm: Detect if our hookstate has been set back to the initial state.

Check if our hookstate has been set back to the initial state, typically the
result of a chanconfig, and if so, if we're an FXO port, forget our current
battery state.  This allows the driver to determine and report again what the
hook state of the port is.

(related to issue ASTERISK-13673)
(closes issue DAHLIN-121)
------------------------------------------------------------------------

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