[asterisk-bugs] [Asterisk 0011189]: chan_zap causing reset on E1 and eventually crashed asterisk

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11189 
====================================================================== 
Reported By:                freon1
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11189
Category:                   Channels/chan_zap
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-07-2007 21:03 CST
Last Modified:              12-21-2007 02:38 CST
====================================================================== 
Summary:                    chan_zap causing reset on E1 and eventually crashed
asterisk
Description: 
I have a TE410 and TC400B installed under Fedora 7 kernel 2.6.23.1-10. with
asterisk-1.4.13, zaptel-1.4.6, libpri-1.4.2.  I have two E1 installed on
the TE410 card my calls are all going from IP to PSTN.  When I have above
40-45 calls (if it is less than 40 I havent noticed any problems) after a
while I start getting error similar to:  
[Nov  6 17:32:18] ERROR[32610] chan_zap.c: !! Got reject for frame 30,
retransmitting frame 30 now, updating n_r!
the number of errors increase and all of a sudden one of the E1s resets
and all the calls drop on that E1. The problem repeats and at some point
the other E1 resets which E1 resets is pretty random.  Then after several
of these errors the asterisk core dumps.  I have tested the hardware with
the help of digium support and have eliminated the hardware as an issue.  I
also tested the E1s and they are clean.  I also to the best of my ability
eliminated the problem being caused by conflict of any unrelated modules. 
I have the full debug (crash at 18:29:37) also the core dump both are
tar.gz(ipped).. I am available to provide further testing with live calls
if we need to get more data or test with live calls if there is a patch.
Thanks 
====================================================================== 

---------------------------------------------------------------------- 
 flefoll - 12-21-07 02:38  
---------------------------------------------------------------------- 
Did you try to activate T309 in zapata.conf ("pritimer => t309,6000" for
instance) ? This maintains active calls when loss of layer 2 is shorter
than T309. If you don't enable T309, you get chan_zap default behaviour,
and it hangs up all calls.

I ask this, because I see that ast_hangup() is involved in your backtrace.
This won't fix the Layer 2 reject problem, this won't fix the memory
corruption, but :
- it may allow you to keep your active calls if the layer 2 problem is
transitory,
- it may avoid falling into this memory corruption problem if it is
related to the general calls hangup.
This is just a suggestion. Whether it will be efficient or not, depends on
what problem comes first : memory corruption, layer 2 error, ... ? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-21-07 02:38  flefoll        Note Added: 0075785                          
======================================================================