This was provided for interop with analog lines provided by Etisilat.
DAHDI-796.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9920 17933a7a-c749-41c5-a318-cba88f637d49
The new buffer events code introduced in revision 9905 gives userspace
processes an interface to activate detection of buffer over and underflows.
This change allows patlooptest to take advantage of that feature to better
inform users of the cause of pattern errors.
Acked-by: Shaun Ruffell <sruffell@digium.com>
(original patch by Matt Fredrickson)
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9909 17933a7a-c749-41c5-a318-cba88f637d49
* Move most of the USB access code from xpp/ to xpp/xtalk/ .
* astribank_tool and such tools can now use a shorter -D mmm/nnn rather
than a full path.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9825 17933a7a-c749-41c5-a318-cba88f637d49
Don't require 'dahdi_hardware -v' to show the driver for a USB device.
Only works when the usbfs is not used (when /proc/bus/usb is not mounted).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9699 17933a7a-c749-41c5-a318-cba88f637d49
Update documentation to the effect that HWEC is not enabled by default
and must be enabled manually if desired via "echocanceller" in system.conf.
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9528 17933a7a-c749-41c5-a318-cba88f637d49
Put back in the loopup and loopdown functionality which had been removed
from dahdi_tool
According to the spec AT&T TR 54016 we should keep the loopback
actuate and release signals on the line for 5 seconds.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9517 17933a7a-c749-41c5-a318-cba88f637d49
Attempting to use channel 16 on E1 CAS is disallowed since that channel is
reserved for RBS signaling. Configurations should not be generated that
attempt to use it.
Closes DAHDI-763.
Patch by dmartinez.
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9485 17933a7a-c749-41c5-a318-cba88f637d49
When called from udev to load the FPGA firmware, make sure that this is
not the event generated for the first end-point of the existing two, as
we need to talk with the second one.
This is probably better done in the udev rules, but will be slightly
more complicated to apply only to the FPGA loading and not to USB
firmware loading.
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9482 17933a7a-c749-41c5-a318-cba88f637d49
Make the error counters a little more readable, removed the prbs
counters since they are not currently functioning
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9477 17933a7a-c749-41c5-a318-cba88f637d49
Also, always append "/CRC4" on any span where that was specified as an
option.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9473 17933a7a-c749-41c5-a318-cba88f637d49
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>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9458 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
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9426 17933a7a-c749-41c5-a318-cba88f637d49
While slightly less efficient, this is only used when configuring the
channels initially (not the hot path) and allows dahdi-base.c to assume
that the open "file" pointer always refers to the channel on which to
perform the operation.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9352 17933a7a-c749-41c5-a318-cba88f637d49
Module 'dahdi_dummy.ko' is no longer needed for DAHDI to provide timing,
therefore we can remove the explicit load of dahdi_dummy, which by
default is aliased to dahdi.ko anyway. If you've edited the DAHDI
Kbuild file in order to build dahdi_dummy explicitly, then you should
add dahdi_dummy to /etc/dahdi/modules in order to load it, but this is
not needed for normal operation.
(issue #17959)
Reported by: glen201
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@9309 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>
Tzafrir Cohen
Shaun Ruffell
Kinsey Moore
Oron Peled
Russ Meyerriecks
Jason Parker
Asterisk Development Team