Tzafrir Cohen
2014-Jan-20 21:10 UTC
[asterisk-users] What is dahdi.auto_assigned_spans and why should you care?
What is dahdi.auto_assign_spans and why should you care?
In later versions the kernel module dahdi[Q] includes a new parameter:
auto_assign_spans. It defaults to 1, and if you set it to 0, DAHDI can
start behaving in strange and completely expected ways. Chances are the
default will be set to 1 in a future version. Here is why you'll want to
set it yourself.
Up until DAHDI 2.5, hardware drivers for DAHDI presented DAHDI with
spans[W]. The device would initialize the hardware, identify the spans
in it, and register them with the dahdi core. The dahdi core assigns
each span the first available span number and the first available series
of channel numbers.
If you have a single device, what you get here is expected. If you have
more than one device, you should make sure that they get detected in
the same order on each boot. One missing: your configuration is
completely botched. As a result, chan_dahdi has adapted to assume that
if any channel has the wrong signalling, it may be because a device is
missing (or got added) and we cannot trust other parts of the
configuration.
Much work has been done to fix this fundemental problem. Dahdi 2.6 added
the basic building blocks: When the hardware drivers register with DAHDI
they expose information about the complete device. This information is
available to userspace through sysfs[E]. If the module parameter
auto_assign_spans has the value 1 (the default), it all happens as
before (except now we call the operation "assignment" - spans are
assigned. And they can be unassigned and reassgined later).
But if auto_assign_spans is set to 0, the spans of the device will just
sit there and wait for the user to do something: you can ask dahdi to
either assign spans "automatically" (to the first available numbers,
just as before). But you can also ask DAHDI to give each span a specific
span number and a specific initial channel number. See [R] for the exact
details.
While doing that we noticed that setting a span to be either E1 or T1
has to be done before it is assigned (you can't change the number of
channels after a span is assigned). Thus a similar interface was added
to change the "span type".
Another important component are "udev events" - when a kernel object
is
created (or destroyed), the kernel emits an event. udevd listens on
those events. With the proper udev rules, you can react to addition of
dahdi devices, spans or channels.
With those low-level tools in place, all we need are a few shell
scripts. You can find the full specification in [T]. You should note the
two new tools. Those tools provide a simple and clean interface to the
sysfs interface.
dahdi_span_assignments: can unassign spans (remove) assign spans
automatically (auto), or assign them according to the specifications in
/etc/dahdi/assigned-spans.conf (add). It also has the option
'dumpconfig' to print the current state in the same format used by its
configuration file assigned-spans.conf .
dahdi_span_types: similar for the span types attribute with
/etc/dahdi/span-types.conf .
HOWTO
-----
Set Up a New System
~~~~~~~~~~~~~~~~~~~
1. connect all the devices.
2. Run: dahdi_genconf
The configurations files are now ready (except, maybe, Asterisk's
chan_dahdi.conf and other configurations. This is beyond the scope of
this message[Y]). So basically just follow with the standard steps from
here:
The configuration was not ready when the spans were assigned. Thus we
cannot rely on the hooks to auto-configure them, and must do that
manually this time:
3. dahdi_cfg # or maybe the full /etc/init.d/dahdi start
4. asterisk -rx 'dahdi restart'
Remove a DAHDI device
~~~~~~~~~~~~~~~~~~~~~
[No need to change anything. The system will just work. dahdi_cfg run in
'/etc/init.d/dahdi start' will fail but we don't care as spans will
be
configured in the udev hook. Channels will be missing in Asterisk but it
won't care as you set 'ignore_failed_channels']
Add Another DAHDI device
~~~~~~~~~~~~~~~~~~~~~~~~
1. Connect the device
2. dahdi_span_assignments auto
3. Run dahdi_genconf
or, if you want to avoid complete regeration:
3.1 Run dahdi_genconf assignedspans
# same as: dahdi_assigned_spans dumpconfig >/etc/dahdi/assigned-spans.conf
3.2 edit system.conf to match the new hardware .
Now your configuration is ready. See (3) and (4) above.
Reconnect a Device
~~~~~~~~~~~~~~~~~~
Quite common with USB devices. The equivalent is to rmmod the driver for
the device and re-modprobe it.
Again: just sit and wait for the device to re-appear in Asterisk.
nothing to do.
Replace a Broken Device
~~~~~~~~~~~~~~~~~~~~~~~
Ideally this would be the same as the above. However,
assigned-spans.conf may have a different hardware ID. You may choose to
have the devices specified by their location identifier (their
connector), but this may have unexpected result if the device is
reconnected on a different port.
So ideally you just edit the configuration file:
sed -i -e 's/old-identifier/new-identifier/'
/etc/dahdi/assigned-spans.conf
and then connect the new device. But maybe you did not remember to do
this in advance, or you're not sure what the ID is without connecting
the new device.
In that case:
1. connect the new device.
2. either:
dahdi_span_assignments auto
dahdi_genconf span
or, if you have anything special thereand want keep it:
sed -i -e 's/old-identifier/new-identifier/'
/etc/dahdi/assigned-spans.conf
dahdi_span_assignments add
The configuration is already in place, so everything should work from
here.
Change Span and Channel Numbers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Naturally you're not limited to the above scenarios. What if you just
feel like using different channel and span numbers? All you need is:
dahdi_assigned_spans remove
vi /etc/dahdi/assigned-spans.conf
dahdi_assigned_spans add
dahdi_genconf # likely to get run here, as you changed span and channel
# numbers.
But you do need a proper text editor. And see (3) and (4) above.
Example: if you have two devices. you want to reverse the order in which
they show.
The configuration file I have is:
####################################
# Device: [usb:000156] @
# /sys/devices/pci0000:00/0000:00:10.4/usb1/1-1/xbus-00/astribanks:xbus-00
usb:000156 1:1:1
usb:000156 2:2:32
usb:000156 3:3:63
usb:000156 4:4:94
usb:000156 5:5:125
usb:000156 6:6:133
usb:000156 7:7:141
# Device: [usb:INT05668] @
# /sys/devices/pci0000:00/0000:00:10.4/usb1/1-3/xbus-01/astribanks:xbus-01
usb:INT05668 1:8:149
usb:INT05668 2:9:152
usb:INT05668 3:10:155
usb:INT05668 4:11:158
usb:INT05668 5:12:161
usb:INT05668 6:13:164
usb:INT05668 7:14:167
usb:INT05668 8:15:170
######################################
As you can see here, this system has two devices, each with several
spans. The device usb:000156 has 7 spans, of which 4 are E1 ports (a
range of 31 numbers[U]) and the other three have only 8 ports. The other
device, identified as usb:INT05668, has eight spans of its own. Their
numbers start from 8, and the channel numbers start from 149. Spans are
are BRIs (3 channels per span).
The long list of channels of the E1 spans is annoying, and I'd like it
to appear after the BRI ports.
Here's the first shot: move the span numbers:
vi () { perl -pi -e 'if (/^usb:000156/)
{s/:([0-9]+):/":".($1+30).":"/e}' "$@"; }
This adds 30 to the span number of the first device. Thus they appear
first on lsdahdi. But the listing is Asterisk is by channel numbers.
Let's add 300 to its channel numbers:
vi () { perl -pi -e 'if (/^usb:000156/)
{s/:([0-9]+)$/":".($1+300)/e}' "$@"; }
And now let's have both:
vi () { perl -pi -e 'if (/^usb:000156/)
{s/:([0-9]+)$/":".($1+300)/e;
s/:([0-9]+):/":".($1+30).":"/e}' "$@"; }
Note that it's easy to change the span numberes, changing channel
numbers is slightly trickier: each span has to have the required number
of channels.
Get vi Back
^^^^^^^^^^^
1. run the above in a subshell. Or:
1.1. unset vi
[Q] Reminder: there is a kernel-level module called DAHDI, and Asterisk
module called chan_dahdi.
[W] A span is logical groups of channels: a single digital port, all the
analog ports on a card, or whatever. Spans and channels are identified
by their numbers.
[E] http://docs.tzafrir.org.il/dahdi-linux/#_devices_bus
[R] http://docs.tzafrir.org.il/dahdi-linux/#_span_assignments
[T] http://docs.tzafrir.org.il/dahdi-tools/#_implicit
[Y] There are interesting things you could do if it were possible to
configure Asterisk more dynamically.
[U] Note, however, The fact that a port has a range of 31 channels does
not necessarily mean it has to be E1. Maybe a smaller span uses that
range.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com
Tzafrir Cohen
2014-Jan-21 17:31 UTC
[asterisk-users] What is dahdi.auto_assigned_spans and why should you care? (II)
Hi again,
Some other things missing from the previous message: setting E1/T1/[J1?]
and upgrading.
E1/T1
-----
an E1/T1/J1 should be configured to be either E1 or T1.There are a
number of ways to set this. Specifically: quite a few different ways.
With the new DAHDI initialization scheme we also provide a new standard
method[X] for setting the "type" (E1/T1/J1) of the span.
If you set dahdi.auto_assign_spans=0, the spans are not assigned
automatically. Before assigning them, the user may set the "spantype"
attribute[K]. This "user" is normally the udev hook script
/usr/share/dahdi/dahdi_handle_device which will run 'dahdi_span_types
set' for the span before assigning the spans of the device[C].
There are several sensible values to put in that file:
1. Just not have it. In this case you fall back to the previous settings
of your drivers.
2. All spans are E1: Just include the following line:
* *:E1
(If you want T1 or J1. put that type instead)
3. Anything more complex: it's easy to do that. you can start with:
dahdi_span_types dumpconfig
and set the specific spans there to be E1 or T1. Note that the
configuration lines are read in order[D] and hence if you have a default
("* *:T1") line and some more specific lines ("id1234
[13]:E1"), the
default must come first.
See the sample span-types.conf[4]
In 2.8 dahdi_genconf generates span-types.conf by default with lines for
each existing Astribank. This has turned out to be a bad idea. In 2.9
merely running 'dahdi_genconf' will not generate span-types.conf .
You'll need to explicitly use 'dahdi_genconf spantypes' . And the
option
you'll normally use is:
dahdi_genconf --tdm-type=J1
Upgrades
--------
You have on your system a version of DAHDI in which
dahdi.auto_assign_spans is set to 1. Now you upgrade it to a version
in which auto_assign_spans is set to 0. What happens?
Workaround
~~~~~~~~~~
There is the workaround of setting 'options dahdi auto_assign_spans=1'
in a file in /etc/modprobe.d . It will work, but we're trying to avoid
that.
Planning Ahead
~~~~~~~~~~~~~~
If you plan ahead, you can run before the upgrade:
dahdi_genconf assignedspans
which is a glorified way of running:
dahdi_span_assignments dumpconfig >/etc/dahdi/assigend-spans.conf
However this will not work for some older versions of DAHDI (as the
interface may not be there, is is not complete). And besides, why plan
ahead?
Just Upgrade
~~~~~~~~~~~~
So, what happens if If you just load the system (make sure that there's
no existing /etc/dahdi/assigned-spans.conf), spans get registered in the
same order as they appear. So basically you should see once that the
system started properly, and then run:
dahdi_genconf assignedspans
This will be used for the next time the module is loaded, so there is no
need to run anything afterwards to "apply" the changes.
I wonder if this fits in a postinst script of a package of dahdi kernel
modules.
Astribanks
~~~~~~~~~~
For Astribanks the upgrade is trickier: Astribanks have their own
mechanism that was intended to provide stable channel and span numbers
in DAHDI: just before registering all the Astribanks with DAHDI they
would wait and registration was done by a specific order (so it worked
well s long as noon was added or removed).
The configuration is a list of Astribanks in /etc/dahdi/xpp_order .
With the upgrade the Astribanks will no longer wait. Thus the "Just
Upgrade" method will not work[2]. This problem, like any other problem
in DAHDI, can be fixed by adding another layer of shell scripts.
Specifically in case the startup scripts notice that:
* The system has Astribanks
* There is an xpp_order file and is not completely remmed-out
* There is no assigned-spans.conf
we run a script that unassigns all devices, and re-assigns them by the
order written in the xpp_order file.
And write a notice to the console that asks the user to kindly run
'dahdi_genconf assignedspans'.
So all's well here as well.
Temporarily Set auto_assign_spans=1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following script unloads dahdi and loads it temporarily with
auto_assign_spans set to 1 to generate configuration:
#!/bin/sh
set -e
# Make it the last, in case we have those setting elsewhere:
modprobe_conf="/etc/modprobe.d/zz_xpp_order_upgrade.conf"
echo "options dahdi auto_assign_spans=1"
>"$modprobe_conf"
/etc/init.d/dahdi restart
dahdi_genconf assignedspans
rm "$modprobe_conf"
/etc/init.d/dahdi restart
I suspect it won't be needed, but just in case.
Conclusion
~~~~~~~~~~
Upgrading should work. No need to set auto_assign_spans=1 . But please
help us test it.
[X] XKCD-927 compatible
[K] Again, see http://docs.tzafrir.org.il/dahdi-linux/#_devices_bus
[C] Again, see http://docs.tzafrir.org.il/dahdi-tools/#_new_devices
[D] Still not the case in 2.8.0, will be the case in 2.9.0
[4] http://docs.tzafrir.org.il/dahdi-tools/#_new_devices
[2] That is: it will work with probability 1/n!, where n is the number
of the Astribanks on the system.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com