[asterisk-bugs] [DAHDI-linux 0013205]: [patch] bad master selection

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Dec 4 10:03:40 CST 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13205 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                kpfleming
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   13205
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             2008-07-31 00:11 CDT
Last Modified:              2008-12-04 10:03 CST
====================================================================== 
Summary:                    [patch] bad master selection
Description: 
Current dahdi master handling work in the following way:
The first SPAN become a master
If a new registered !!! SPAN is preferred , it is the new master
If a span is unregistered - the new master is the first available span
If master SPAN is in alarm state - the new master is the first non in
alarm state SPAN

So
1. dahdi-dummy once loaded will be the master forever.
2. even not-running SPAN can be a master
3. master implementation is ugly...
====================================================================== 

---------------------------------------------------------------------- 
 (0095770) madrouter (reporter) - 2008-12-04 10:03
 http://bugs.digium.com/view.php?id=13205#c95770 
---------------------------------------------------------------------- 
These patches seem to only half fix the problem.  There's still no
definitive order in which spans will be used as the master.  This is a
problem if the prefmaster (which is a silly concept) goes down.  DAHDI will
then simply use the first non-zero channel span as it's master which might
be something you definitely don't want.

Please see attached patches (that I happened to be working on at the same
time) for something that works better (IMHO).  With these patches applied
the "timing" field in the span definitions in system.conf actually does
what the documentation says.

If you have a span with timing set to 0 it will NEVER become the master
(implies you can have a situation with no master - and hence no DAHDI ticks
- but this is a misconfiguration rather than a bug).  If you have a span
with timing set to 1 it will be master in preference to a span with timing
of 2 etc.  If a span is in alarm it will not be considered when deciding
who is master.

If the current master goes into alarm DAHDI simply picks the non-alarmed
span with the next highest priority and makes it master.  Importantly - if
a "better" master span comes OUT of alarm (or gets registered if it's a
dynamic span) DAHDI will change to using the better span as master.

dahdi_dummy is hard configured with a sync priority of 100 (arbitrary
value), so it can be loaded and will not become master unless ALL other
spans configured as possible masters are in alarm. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-04 10:03 madrouter      Note Added: 0095770                          
======================================================================




More information about the asterisk-bugs mailing list