* Correctly use the new "location" attribute
* Document the possibility to match against sysfs devpath
(used to be the "location")
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Install them as *.conf.sample -- that's what they are
* Correctly rename spantype.conf to span-types.conf (new name)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If you installed dahdi tools and did not specify DAHDI_PINNED=yes on the
makefile, when you run dahdi_genconf you would get an error like the following:
# dahdi_genconf
sh: span_types: command not found
Command failed (status=32512): 'span_types dumpconfig > /etc/dahdi/span-types.conf' at ...
This change allows the generator for span-types.conf and span-assignements.conf
check for the existence of the utilities before attempting to call them.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* If xpp.dahdi_autoreg parameter is 'Y' -- Skip actuall registration.
* If dahdi.auto_assign_spans is '0' and there's no /etc/dahdi/pinned-spans.conf
Than use 'span_assignments auto ...' to assign device spans.
* Since dahdi_registration iterate in correct xpp_order, the span
assignment logic provides migration path for users who did not
generate their pinned-spans.conf configuration yet.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* New functionality (documented in the script header):
- Alternative "keys" for device matching
- Added new command line options: --help, --dry-run, --verbose, --key
* Clean sysfs attribute contents from special characters in every use-case.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Do the "right thing" (hopefully. At least for a system with a single
device) if there is are no configuration files:
* No span-types.conf: just ignore it as before. It is optional.
* No pinned-spans.conf: use span_assignments auto (same as having
dahdi.auto_assign_spans=1).
* No system.conf: generate a temporary one with dahdi_genconf.
This will hopefully allow having a partially-working system, and help
making ut usable with 'span_assignments dumpconfig'. Or maybe just work
as-is.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
A newer version of the scripts fully adapted to pinned spans:
* handle_device does not run dahdi_cfg.
* A separate UDEV rule script for that: span_config. Should also work
for the non-pinned case.
* span_assignments, span_types: add actions 'auto' (manually enable all)
and 'dumpconfig' (dump current status in the format of configuration
file).
* Fixed name of span_types and span_assignments (no '-').
* spantype.conf renamed span-types.conf: configuration files do have a
dash.
* Those two are useful programs, insstalled to /usr/sbin.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
This copies in the make_version script from DAHDI-Linux to allow the version to
be properly reported from builds in git checkouts.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
In DAHDI-Linux 2.7 the layout of the /dev/dahdi files changes so that they are
grouped by span. When opening channels by number all utilities need to use
DAHDI_SPECIFY now.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If the config file has two spans defined:
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24
echocanceller=mg2,1-23
span=2,2,0,esf,b8zs
bchan=25-47
dchan=48
And you only want to configure span-2, you would need to pass -S 1 to
dahdi_cfg. Now make the -S option take the span number as assigned in the
config file.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
In DAHDI-Linux 2.7 the layout of the /dev/dahdi files changes so that they are
grouped by span. When opening channels by number all utilities need to use
DAHDI_SPECIFY now.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Add installation of the pinned-spans support to the Makefile. For the
moment, however, they are not installed unless you use ./configure
--enable-pinned or build with 'make DAHDI_PINNED=yes'
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* New script: dahdi_cfg_device_args:
- Just like span_assignments, span_types: may be given
one or more sysfs devpath's
- Output the required options for dahdi_cfg. E.g:
"-S 8 -C 15-28"
- This may be passed (with any other wanted options)
to the new dahdi_cfg (which supports '-S' and '-C')
* Use dahdi_cfg_device_args in handle_device so we configure
each span from udev.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
handle_device is the basic script intended to be called from udev.
It will call span_types on the span to apply optional
/etc/dahdi/spantype.conf onfiguration settings that need to be applied
before assignment (currently "pri" port types: E1/T1/J1).
Next it assigns span numbers to spans: if configured in
/etc/dahdi/pinned-spans.conf - use those settings. If not: by the order
of loading.
span_types and span_assignments can also be used to report the settings
they are used to configure.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
No point in loading the modules if nobody built them yet. It is a common
case for one to install the userspace tools package but not (yet?) build
the modules. See, e.g. http://bugs.debian.org/706046 .
With this changeset, we exit gracefully in such a case.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If, via the sysfs attributed introduced in DAHDI-Linux 2.5.0, a user has
configured spans that do not have contiguous channel numbers, dahdi_scan will
not print several of the span attributes in addition to a bad basechan number.
This patch allows dahdi_scan to try and get the basechan for a span from sysfs
as opposed to calculating based on the number of channels in the previous span
scanned.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
One line change to re-include a missing header
Reported-By: Anthony Messina
Internal-Issue-ID: DAHTOOL-60
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
menuselect has not been used in dahdi-tools since r10411 (7 months ago). This
patch removes menuselect from the repository completely.
Reported-by: Sean Bright
Internal-Issue-ID: DAHTOOL-61
Patches: kill-menuselect.patch by Sean Bright (license #5060)
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@10721 17933a7a-c749-41c5-a318-cba88f637d49
After hitting control-C when writing a wav file, dahdi_monitor reports
"Failed to read in a full wav header. Expect bad things."
Also when using the -F output option, the wav header is not written.
Reported-by: Richard Miller
Internal-Issue-ID: DAHTOOL-59
Patch: dahdi_monitor.diff by Richard Miller (license #5685)
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@10717 17933a7a-c749-41c5-a318-cba88f637d49
* This xusb_spec:
- Is a dummy struct used for this xusb instance only.
- Is now passed by reference from caller.
- So caller now manage the life cycle of this struct
* Also, demote one INFO() to DBG() (library should not print
on its own)
* Also minor fix to DBG() output of spec initialization (leading 0)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Origin: Xorcom xtalk (r9303)
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@10711 17933a7a-c749-41c5-a318-cba88f637d49
xtalk: dump_packet() may now be used without debug flags by passing
mask == 0.
Origin: Xorcom xtalk (r9302)
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@10710 17933a7a-c749-41c5-a318-cba88f637d49
Adding the TE820 vendor and device ID into PCI.pm allows dahdi_hardware to
recognize the card.
Reported-by: Xavier Hienne
Internal-Issue-ID: DAHTOOL-58
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@10680 17933a7a-c749-41c5-a318-cba88f637d49
If DAHDI is installed the vast majority of users will most likely not want
hfcmulti, hfcpci, or netjet loaded since they may conflict with DAHDI drivers
for the TDM400, B410P, and TE11XP cards.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.astersk.org/svn/dahdi/tools/trunk@10601 17933a7a-c749-41c5-a318-cba88f637d49
When running the astribank_hook (only on Astribanks, in XPP_HOTPLUG_DAHDI
mode), wait for all other Astribanks to create all the required device
files.
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@10585 17933a7a-c749-41c5-a318-cba88f637d49
* It was replaced long ago by astribank_hexload/astribank_tool/astribank_allow
* It hasn't been used for several releases now, nor updated.
* Time to move into the eternal bit-bucket.
* Left (very) few strings as a tribute...
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@10504 17933a7a-c749-41c5-a318-cba88f637d49
