The TOOLSVERSION was inconsistent in configure.ac and Makefile:
* Rename the second parameter to AC_INIT() into short_version
* Calculate TOOLSVERSION during configure and use it to
generate version.c from version.c.in
* For now, leave duplicate TOOLSVERSION in Makefile (for make dist)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
If we have /etc/dahdi/span-types.conf but it doesn't have any
line, we should avoid using the option -S to astribank_hexload.
Fix the test for this.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Don't run the final astribank_is_starting if asterisk is hotpluggable.
Likewise, if there's no xpp_order file, waiting is pointless as the hook
can't count Astribanks.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* 'time' was added here for debugging and never actually needed.
* It actually causes a minor bashism issue.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* New asynchronous behavior is used only when two conditions are met:
- Finding new $ASTERISK_SUPPORTS_DAHDI_HOTPLUG=yes in /etc/dahdi/init.conf
This should be set only when Asterisk support hotplug and configured
to use it (no_failed_channels==1).
- DAHDI auto_assign_spans==0
* Adapt /usr/share/dahdi/astribank_hook:
- Refactor old twinstar behavior into functions
- Add new behavior in a function (just enable the Asrribank watchdog)
- Call the correct function.
* Adapt init script:
If asynchronous behavior is on, don't wait for all Astribanks to
finish initialization (it's enough that we saw all/some of them)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Do print a message if no semaphore exists. It means that either there
are no Astribanks, or existing Astribanks were already initialized.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Initialize db to 1.0 instead of doing it in a few, but not all, logic contexts.
Reported-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Why:
* Doing "clear_halt" is normally the right thing to do on startup.
* The original observed problem is better fixed via USB bios settings.
* Defaulting to no "clear_halt" cause more problems on other platform
combinations (hardware/kernel).
The change:
* We now reverted to do "clear_halt" by default.
* The XTALK_OPTIONS may now contain either "use-clear-halt" (the default)
or "no-use-clear-halt" to override for debugging/testing.
Original commit: ca7c04e9cb
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
DAHDI 2.9.2 added support for -S (span specs). However if this option
was not specified, it fails to run.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
The variable 'default_law' was the result of a partial renaming of the
original variable 'law'. Let's keep all of them in sync.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
The Congestion tone in Australia must be reduced by 10 to 15 dB
at every other cadence and the frequencies for both at cadences are 425 Hz.
From: Armen Karlozian <armeniki@hotmail.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The default 'us' tone is most likely better than silence when Asterisk tries to
generate the recall tone on a DAHDI channel.
Internal-Issue-ID: DAHTOOL-63
Reported-By: Igor Kravets
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Logic was calling DAHDI_SPECIFY ioctl on all channels up to maximum channel
limit. Added a short circuit to prevent the ioctl on channels that aren't
configured.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Hopefully will save a little time in the future if anyone ever types into
/etc/dahdi/system.conf:
bchan=1-15,17-30:1101
when they meant:
cas=1-15,17-30:1101
in the future.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If dahdi_cfg is terminated while holding the named semaphore, it is possible to
leave it behind and all subsequenct invocations of dahdi_cfg will block waiting
for it.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Added optional '-S <span-spec>' argument to astribank_hexload:
- Allow passing PRI span specification to EC firmware loader.
- The span specifications is whitespace/comma separate list
of items.
- Each item is: <span>:<type> (Example: 3:T1)
- The <span> may use shell-like globbing (e.g: *:E1 or [12]:T1)
- Any span not matched in the span specification will be set
as without the new '-S' option (i.e: depends on the '-A' option).
* Adapted xpp_fxloader:
- Read specification for both device label and wildcard from
/etc/dahdi/span-types.conf
- If the result is non-empty, pass it as '-S <span-spec>' to
the EC firmware loader.
* Read first from modern configuration files
(/etc/dahdi/span-types.conf)
- Support either exact label match or complete '*' match in the
configuration file.
* Fallback to legacy /etc/dahdi/xpp.conf
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Improvements to the xpp tool dahdi_registration:
* Use the new xpp driver with support for dahdi_registration sysfs
attribute in each device.
* Wait for UDEV to finish handling span assignments (via
dahdi_waitfor_span_assignments).
* Still supports legacy drivers without this, by falling back
to old style iterative "registration" on each xpd.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Don't use "usb_clear_halt" by default anymore
- It caused problems with specific devices in the past
- Now it cause problems with specific servers as well (64 bits, USB3)
* Add an "XTALK_OPTIONS" environment variable to pass options:
- Use it to implement a "use-clear-halt" boolean option that
restore original behavior.
- Also use it for "no-lock" option which replace the legacy
environment variable "XUSB_NOLOCK".
* Compile with "-Wall -Werror"
* Better dependency calculation:
- Explicit listing of sources, don't use wildcards.
- Pass various CFLAGS to dependency calculation as well.
- Make sure a failure is propagated
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Single frequency signalling has not been supported in dahdi_cfg since the switch
to DAHDI. Before DAHDI, in the Zaptel days, it was only suported in the
ztcfg_dude utility which wasn't mainlined. So this removes references to those
signalling modes unless support is added back into the driver.
Internal-Issue-ID: DAHLIN-335
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* The "spantypes" generator had E1 default if no 'line-mode' parameter
was passed.
* As a result the new logic in "dahdi_span_types dumpconfig" had no
effect when called from dahdi_genconf, as it was always called
with "--line-mode=" argument.
* Now "dahdi_genconf spantype" behaves just like
"dahdi_span_types dumpconfig":
- The "--line-mode=" forces generation of provided line-mode (E1/J1/T1)
- Without this option, the generated config matches the current spans
state according to new dahd_span_types default logic:
- Wildcard rule if all spans have same line-mode.
- Uncommented specific matches if spans have different line-modes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes a regression since 949ea4ca9f
(2.7.0) - allows using an Astribank with no serial.
* Some of the olderst Astribanks don't have a serial number burned in
them. Thus there is no serial attribute for the sysfs USB device node.
* waitfor_xpds identifies the Astribanks by their serial numbers.
* An lone Astribank without serial number would thus block waitfor_xpds
(until timeout).
* Now we warn about them.
* We also try to handle it gracefully. As long as there's only one
of thease, it would be counted as "NO-SERIAL".
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* The system state causing the bug:
- DAHDI has auto_assign_spans==1
- No /etc/dahdi/assigned-spans.conf
* The bug scenario:
- During initial device detection, they are assigned by
DAHDI driver.
- Later we run "dahdi_span_assignment remove"
- Then, a "dahdi_registration on" would not assign any span.
* The fix:
- Using the '-R' option, force "dahdi_registration on" to also
do "dahdi_span_assignment auto" on relevant devices.
- This is the way it's called by /usr/share/dahdi/dahdi_auto_assign_compat
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
* Better defaults:
- A wildcard match:
- If '--line-mode' option is given, generate a wildcard entry.
(existing behavior).
- Otherwise, if *all spans* are of the same type (E1/T1),
generate a wildcard entry for this type.
This is the most common use-case and now it work without
any command line flags.
- Otherwise (mixed E1/T1 spans), do not generate a wildcard entry.
This isn't common case (except from our labs), but regardless
without '--line-mode' any guess could be wrong.
- Specific device matches:
- If all spans are of the same type, generate commented out
specific entries (for manual overrides).
- If spans have mixed E1/T1 types, generate specific entries
In this case, specific entries MUST NOT be commented out
otherwise, the configuration file is wrong!
* Generated header with better organization:
- Shows what is generated:
- Generating wildcard / Not generating wildcard
- Generating specific lines / Generating *commented-out* specific lines
- For each decision, show *why* it was taken.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Maintains the original registration order as was before span
assignments. Should allow seemless trannsition to
dahdi.auto_assign_spans=0
* The idea:
- We stop handling in udev the case of missing
/etc/dahdi/assigned-spans.conf
- Instead we rely on "registration_time" dahdi_device attribute from
DAHDI-linux
- Then, we can sort the devices and assign their spans in
/etc/init.d/dahdi
* Mechanics:
- From /etc/init.d/dahdi, we run a new 'dahdi_auto_assign_compat'
script (after "waitfor_xpds" etc.)
- In this script we "auto" assign spans of non-Astribank devices
- In the end of the script we run "dahdi_registration" which
does the same for Astribank devices.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Original actions didn't care about remove (10-span-types, 20-span-assignments)
* But others need to know about removals too.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This fixes a confusing error message. When sem_open failed, the system.conf line
number was being printed and the system error code was not.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
auto_assign_spans is an int and may have legal values other than 1. It
is legal (though pointless) to use: modprobe dahdi auto_assign_spans=3.
Any value != 0 is true.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Removes a potentially confusing error message. This is a reapplication of
(4f259cd569 "dahdi_handle_device, dahdi_span_config: Check for
auto_assign_spans only when ACTION is add.") which appears to have been
accidentally removed when moving the hotplug scripts into a subdirectory.
From the original commit:
When dahdi.ko is unloaded, it may be possible for the driver to be removed from
the kernel before the udev scripts are run. When this happens, you'll see
messages like the following which are not accurate:
'dahdi_handle_device'[24567]: Old driver (no auto_assign_spans parameter). Skip /devices/pci0000:00/0000:00:1e.0/0000:11:01.0/pci:0000:11:01.0
Now instead you will see:
'dahdi_handle_device'[28008]: remove: /devices/pci0000:00/0000:00:1e.0/0000:11:01.0/pci:0000:11:01.0
Also, all the udev events will be logged in the system log even when they are
ignored because of legacy auto span assignment. This will help show what is
going on during the transition period to full udev configuration of spans.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>
This reapplies the change made in commit (6ed0adc08 "dahdi_span_config: Do not run auto
span configuration if spans are auto assigned.") which appears to have been
accidentally removed in (7f826a7d35 "hotplug modularization: split logic to
scriptlets").
To rationale from commit 6ed0adc08:
I have seen cases were users run:
# modprobe <driver>; dahdi_cfg -c <custom config file>
and the spans end up misconfigured because dahdi_span_assignments ends up
running, via udev, after the user configured the span the way it wanted.
dahdi_span_assignments now looks at auto_assign_spans module parameter on
dahdi.ko, like dahdi_handle_device already does, to determine if legacy or udev
based configuration is being done.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
