[asterisk-bugs] [Zaptel 0011661]: ztcfg default behavior + races in zaptel drivers + unsuspecting admins cause kernel crashes

noreply at bugs.digium.com noreply at bugs.digium.com
Wed Jan 23 02:05:47 CST 2008


The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=11661 
====================================================================== 
Reported By:                sim
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   11661
Category:                   Core-General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Zaptel Version:             1.4.7.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             12-31-2007 18:29 CST
Last Modified:              01-23-2008 02:05 CST
====================================================================== 
Summary:                    ztcfg default behavior  + races in zaptel drivers +
unsuspecting admins cause kernel crashes
Description: 
I have witnessed more than 5 different people accidentally run "ztcfg" on
production systems in an attempt to try to poke at zaptel to find the
source of an issue.  One runs through "zttool", "ztdiag", "zttest", etc.,
and usually "ztcfg" if they do not know better, expecting it to behave
similar to "ifconfig".  This _should_ just reset the PRIs (in a perfect
world), but instead it tends to cause a kernel Oops in zt_init_tone_state
due to races in zaptel when channels are active.

I bet this has been causing people to kill their Asterisk servers around
the globe for many years now, and I think this is serious enough to warrant
an interface change.  I propose we either change "ztcfg" to require an
argument before applying any changes, or we make it do something similar to
checking for Asterisk running first, and not apply configuration if so
unless an override argument is specified.

If agreed, I can easily write and submit a patch -- just let me know.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010593 Zaptel crashes kernel - zt_init_tone_state
====================================================================== 

---------------------------------------------------------------------- 
 tzafrir - 01-23-08 02:05  
---------------------------------------------------------------------- 
This report contains no useful information. I indeed suspect the tone zones
initializations to do some dodgy things, but sadly this report provides me
with no extra data points.

Please reopen it when you can provide more useful details. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-23-08 02:05  tzafrir        Status                   new => closed       
01-23-08 02:05  tzafrir        Note Added: 0081061                          
======================================================================




More information about the asterisk-bugs mailing list