DAHDI_REGISTRATION(8)

📦
version 3.4.0 · 8 versions
, in ubuntu stonking

💖 DAHDI_REGISTRATION(8) 💖

okay bestie so this is dahdi_registration — a Perl script, part of the User Contributed Perl Documentation crew, and it handles the registration of Xorcom XPD modules in dahdi. yes it's a mouthful, no I'm not sorry, let's go ✨

🌸 SYNOPSIS 🌸

dahdi_registration [-v] [-s sortorder] [-R] [on|off]

that's it. that's the whole vibe. 🫶

✨ DESCRIPTION ✨

So, if you run this with no parameters at all, it just shows you every connected XPD, sorted by physical connector order. For each one it tells you whether it's unregistered (off) or registered to a specific dahdi span — and yeah, it shows you the span number. 👑

All registrations and deregistrations get sorted by physical connector string, which is exactly as tidy as it sounds.

Span registration should generally always succeed. Span unregistration though? That one can fail if channels from that span are currently in use by, like, asterisk or whatever. And in that case you'll also see those channels marked as '(In use)' over in the output of lsdahdi(8). rude of them honestly.

dahdi_registration is meant to be used when the kernel module parameter xpp.dahdi_autoreg is false — and implicitly, when the module parameter dahdi.auto_assign_span is true. Also peep the NOTES section about "dahdi_span_assignments".

And if dahdi_autoreg is true? The program will normally just do nothing. it's giving unemployed. 💀

🎀 Parameters

  • off — deregisters all XPD's from dahdi.
  • on — registers all XPD's to dahdi.

💅 Options

  • -v — verbose output. she's chatty now.
  • -R — Force operations (on/off) even if the module parameter dahdi_autoreg for xpp is enabled (which makes this program unneeded). like, overriding the "you don't need me" energy.
  • -s sort_order — the sort order to use.

If -s isn't used, the sort order comes from the environment variable XBUS_SORT, and if that's not there either, it falls back to the hard-coded default of SORT_XPPORDER. ✨

All the available sorting orders are documented in the Dahdi::Xpp manual. go read it, iykyk.

🌈 Sample Output

Here's what dahdi_registration spits out for some registered Astribanks, as a lil treat:

$ dahdi_registration -s type
XBUS-01         usb:0000153     usb-0000:00:10.4-2
        XBUS-01/XPD-00: on Span 1
        XBUS-01/XPD-01: on Span 2
XBUS-00         usb:0000157     usb-0000:00:10.4-4
        XBUS-00/XPD-00: on Span 3
        XBUS-00/XPD-01: on Span 4
        XBUS-00/XPD-02: on Span 5
        XBUS-00/XPD-03: on Span 6
        XBUS-00/XPD-04: on Span 7
        XBUS-00/XPD-05: on Span 8
        XBUS-00/XPD-06: on Span 9
        XBUS-00/XPD-07: on Span 10
XBUS-02                 usb-0000:00:10.4-1
        XBUS-02/XPD-00: on Span 11
        XBUS-02/XPD-10: on Span 12
# Sorted: type

look at them. all registered. main character energy fr fr. 🔥

🦋 FILES 🦋

  • **/proc/xpp/XBUS-nn/XPD-mm/dahdi_registration** — reading from this file shows you if the specific XPD is registered. Writing to it 0 or 1 registers / unregisters the device.

this should let you register / unregister a specific XPD rather than all of them. so you can be picky about it. we love a selective queen. 💅

👑 NOTES 👑

dahdi_registration is intended to be used when the kernel module parameter xpp.dahdi_autoreg is false (and implicitly: when the module parameter dahdi.auto_assign_span is true). Meaning: Astribank devices as detected by XPP (xbus / xpd) do not register automatically with the DAHDI core. This tool is what you use to register them in an explicit order. It works well — but only if you can arrange for all of the Astribanks of the system to be available (and not already registered) at a specific point in time. no pressure or anything. 😭

Newer versions of DAHDI added support for registering a span to a specific span/channels numbers specification. This allows registering them out of order — chaotic, honestly kind of iconic. To use this capability, the module parameter dahdi.auto_assign_span should be unset (set to 0), and thus spans of detected DAHDI devices could be registered using "dahdi_span_assignments" (which may also be run automatically from a udev hook).

In this case there is no point in delaying XPP device registration with dahdi, and the parameter xpp.dahdi_autoreg should be set. dahdi_registration will simply become a no-op. she's off duty. periodt.

🌟 SEE ALSO 🌟

dahdi_cfg(8), dahdi_span_assignments(8).

and that's the whole page bestie!! this was written by the Perl crew — perl v5.40.1 — and dated 2026-06-15. go register something responsibly. mwah 💖🎀🦋

📦 where this page comes from