Age | Commit message (Collapse) | Author |
|
Due to a typo the option for not using a timeout was always used.
Regression since r9426.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9831 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9830 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
* 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.asterisk.org/svn/dahdi/tools/trunk@9825 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Replace the remaining $span->xpd with xpd_of_span().
Following up on r9648.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9731 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9699 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Replace one remaining $span->{XPD} with xpd_of_span().
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9648 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9528 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9517 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9499 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9485 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9482 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Make the error counters a little more readable, removed the prbs
counters since they are not currently functioning
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9477 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9473 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9458 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Add extra PCI IDs to support "beroNet BN4S0e PCI Express 4x S0 Karte".
Origin: http://bugs.debian.org/600839
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9452 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9426 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9352 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Adding Macao tone zone data according to
http://www.itu.int/ITU-T/inr/forms/files/tones-0203.pdf
(closes issue #17744)
Reported by: alfredtang
Patches:
zonedata.patch uploaded by alfredtang (license 1094)
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9313 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
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.asterisk.org/svn/dahdi/tools/trunk@9309 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9220 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Generate some sort of configuration for dynamic channels. Usable enough for
testing.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9159 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
This fixes the case where the BRI spans on the Hx8 cards were displayed as
analog spans.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9133 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
(closes issue #17783)
Reported by: frawd
Patches:
dahdi-tools_aligera.patch uploaded by frawd (license 610)
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9079 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
New functionality that was added in r8992 and r8993 uses new items
defined only in dahdi-linux trunk (and eventually: 2.4).
As in both cases it's a single place to check, we'll just ifdef it away.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9076 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
is chosen along with suggestions on how to fix the problem.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9067 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
channels and fix a bug preventing E&M-E1 from being detected properly
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9066 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@9031 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8994 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8993 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8992 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8991 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Hmm... how badly congested can the startup of Centos be?
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8964 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8954 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
For newer kernels there's no need to sleep at all. For Centos5 systems
there seems to be a need for a large sleep for firmware load at boot time.
So let's make it a loop.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8951 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8948 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8924 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Allow using CONNECTOR/LABEL in addition to SPAN and NUM for pri_termtype
in genconf_parameters
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8923 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8854 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
If your window was larger than 80X25, you got a main "window" in the
center and the span one in the corner. This puts the span one in the
center as well.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8827 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Various values in system.conf were parsed using %i. This means that a
value with a leading 0x was considered hexadecimal and a value with a
leading 0 would be considered octal ('030' == '24' == '0x1E').
This was never documented and seems a potential cause for confusion in
case a leading zero sneaks in. It is thus removed.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8777 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
flagged and
what is displayed.
Still runs with the old usage: patlooptest <dahdi device> [<timeout>]
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8746 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8741 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8670 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8638 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8630 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
rad_apply_channels() was the same as apply_channels()
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8615 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
When the DAHDI configuration file does not configure every single span in the system,
but leaves spans unconfigured, the verbose output from dahdi_cfg would show incorrect
span numbers when reporting the line configuration, as it printed the index into the
array of configured spans, instead of their actual span numbers.
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8606 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8589 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
Move loading the the xpp firmwares (when called from udev) to a background
sub-process. This helps with:
* Don't block udev
* It seems that with older systems (e.g. CentOS 5) we need to wait a bit
for the device file to appear (in one of the upcoming udev events). If we
keep blocking udev, we won't have the device file.
The 'sleep' does not seem to be required for newer systems (e.g. Debian Lenny).
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8580 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|
|
git-svn-id: http://svn.asterisk.org/svn/dahdi/tools/trunk@8547 a0bf4364-ded3-4de4-8d8a-66a801d63aff
|