Loss of crc4-multiframe alignment on an E1 link is not a condition which
brings the span down. The span will continue to run as long as it can
maintain double frame alignment. Because of this, we cannot place the
LMFA alarm in the usual spaninfo.alarms member, due to userspace
programs using this as a catch-all for a span being up or down.
We can detect the alarm by watching the frame error counter (fecount).
If it continuously increments, the span is configured for crc4, and the
span remains OK (alarms = 0), then we are in loss of crc4-multiframe
state.
In order to test this alarm, you'll need to synthesize a loss of crc4
alignment on the span. You can usually do this by configuring the local
span to use crc4 and the remote end to not use crc4. I used the Fireberd
6000 in my lab to do this.
dahdi-743 & dahdi-420
Acked-by: Shaun Ruffell <sruffell@digium.com>
Merged revisions 9458 via svnmerge from
http://svn.digium.com/svn/dahdi/tools/trunk
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/branches/2.4@9738 17933a7a-c749-41c5-a318-cba88f637d49
astribank_is_starting should use a timeout for the semaphore, but if the
GNU-specific semtimedop() is not available, we'll just fall back to using
semop with no time out. Not as good, but better than nothing.
(closes issue #16783)
Reported by: abelbeck
Merged revisions 9426 via svnmerge from
http://svn.digium.com/svn/dahdi/tools/trunk
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/branches/2.4@9736 17933a7a-c749-41c5-a318-cba88f637d49
Menuselect was originally included in the DAHDI-Tools repository with an svn
external. Since git does not handle externals so well, menuselect is being
brought into the tree directly. This allows menuselect to be present for all the
commits on the 2.4, 2.5, and 2.6 releases.
The command is:
$ svn export http://svn.asterisk.org/svn/menuselect/trunk menuselect
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
