[Home]

Summary:DAHLIN-00150: [patch] wcbxxp fails reading signalling
Reporter:odicha (odicha)Labels:
Date Opened:2009-10-08 20:39:27Date Closed:2010-03-16 10:46:29
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:wcb4xxp
Versions:2.2.0.2 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Error.txt
( 1) wcb4xxp-bad-frames.patch
Description:The problem is detected in the calls that the package CONNECT includes an information element type number connected "(in calls to the bedside of a call center can inform the caller of the number that really has heeded the call).
The error is not due to the ease, but the size of the package.
By placing an analyzer monitoring basic access, we see that  the operator sends the package (correct) and that the receiver asterisk (namely dahdi) has invented a character.
We get at log something like this chan_dahdi.c:10710 dahdi_pri_error: XXX Message longer than it should be?? XXX
-- Processing IE 41 (cs0, Date/Time)
-- Processing IE 76 (cs0, Connected Number)
chan_dahdi.c:10710 dahdi_pri_error: XXX Message longer than it should be?? XXX

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

The driver (wcb4xxp) is inventing a character in certain situations (when the package has exactly 31 characters). It is also possible to optimize the event that the package has exactly 32 characters. The latest improvement proposal is in give "stat" on a routine point less likely to potential problems in subsequent modifications
Patch attached (and tested)
Same issue using 2.1.0.4 (function remains unchanged)
Comments:By: odicha (odicha) 2009-10-08 20:45:38

Usually, when we get this error we "lose" the outgoing call...
By: Leif Madsen (lmadsen) 2009-10-26 08:37:57

Marked as Confirmed as there is a patch the solves the issue for the reporter. If the reporter could gather someone else who has the same issue (perhaps post to the asterisk-dev mailing list) and can have them test, that would be useful.

Thanks for the submission!
By: Alec Davis (alecdavis) 2009-10-30 05:09:44

I'm having problems (see DAHLIN-158) with DIGITAL calls connected to a NT port on B410P and with this patch my success rate changes from none, to once, then a dahdi restart is required.

before patch I see both as below, call appears to setup, but no data transfer.

3 !! Unknown IE 207 (cs0, Unknown Information Element)
   -- Executing [8200@phones:1] Dial("DAHDI/ISDN-3-1", "DAHDI/G3/8200") in new stack
   -- Accepting call from '8100' to '8200' on channel 0/2, span 3
   -- Requested transfer capability: 0x08 - DIGITAL
   -- Called G3/8200
   -- DAHDI/ISDN-3-2 is ringing
   -- DAHDI/ISDN-3-2 answered DAHDI/ISDN-3-1
   -- Native bridging DAHDI/ISDN-3-1 and DAHDI/ISDN-3-2
   -- Channel 0/1, span 3 got hangup request, cause 16
   -- Hungup 'DAHDI/ISDN-3-2'

or
   -- Hungup 'DAHDI/ISDN-3-1'
   -- Accepting call from '8100' to '8200' on channel 0/2, span 3
   -- Executing [8200@phones:1] Dial("DAHDI/ISDN-3-3", "DAHDI/G3/8200") in new stack
   -- Requested transfer capability: 0x08 - DIGITAL
   -- Called G3/8200
   -- DAHDI/ISDN-3-4 is ringing
   -- DAHDI/ISDN-3-4 answered DAHDI/ISDN-3-3
   -- Native bridging DAHDI/ISDN-3-3 and DAHDI/ISDN-3-4
   -- Channel 0/2, span 3 got hangup request, cause 16
   -- Hungup 'DAHDI/ISDN-3-4'
 == Spawn extension (phones, 8200, 1) exited non-zero on 'DAHDI/ISDN-3-3'
   -- Hungup 'DAHDI/ISDN-3-3'
[Oct 30 22:43:47] ERROR[17372]: chan_dahdi.c:13178 dahdi_pri_error: 3 XXX Message longer than it should be?? XXX
By: John Todd (jtodd) 2009-11-12 14:17:41.000-0600

So Alec, if I read your note correctly, the included patch solves the problem BUT it causes DAHDI to lock up and require a restart after one call?
By: Alec Davis (alecdavis) 2009-11-12 14:28:22.000-0600

It stops the "XXX Message longer than it should be?? XXX "

But I'd need to reconfirm, whether I actually had data transfer. Going from what I've found at DAHLIN-158 I'm not sure now.
By: Alec Davis (alecdavis) 2009-11-13 03:48:09.000-0600

Used latest dahdi/libpri/asterisk trunk tonight, and got this error, without the patch.
Then as luck would have it, the router making the outbound call died, after using another router (same model NETGEAR RT328), never had it again.
Maybe firmware issue on dead router - never going to know.

Moved on to DAHLIN-158
By: Panos Gkikakis (roeften) 2009-11-22 16:44:52.000-0600

I am also getting this error and can verify that we "lose" the call (SPEECH, I have described it in PRI-52)

After a few hours of using it there seems to be no problem or locking issue.

I have applied the patch and will report back with results.


By: Alec Davis (alecdavis) 2009-11-23 13:38:43.000-0600

Although I haven't got a router that causes this anymore :(
The patch while the router was alive did fix the problem, for a number of test calls.

Regarding the success rate reported in ~112929 of 'once' after a console 'dahdi restart', I'm not so sure now, as the configuration I had, was to echocancelwhenbridged=yes, which would never have worked as reported in DAHLIN-158

Speculation: I guess it's possible the chan_dahdi variable p->digital was uninitialised for the first call and worked.
By: Matthew Fredrickson (mattf) 2009-11-23 13:52:11.000-0600

Patch was merged into dahdi-trunk in revision 7640.
By: Leif Madsen (lmadsen) 2009-11-23 20:18:11.000-0600

If that's the case, does that mean this issue should be closed? If the patch was merged, then the commit message should have contained a note at least referencing this issue (presuming this issue is related to the commit), or closing the issue if that is the case. Thanks!
By: Panos Gkikakis (roeften) 2009-11-25 01:26:49.000-0600

Just to say that this patch works great so far, the message does not show in my logs any more, and no calls are not lost so far.
By: Michael Spiceland (mspiceland) 2010-03-16 10:46:27

Closed by commit ASTERISK-7442