asterisk / dahdi-linux Goto Github PK
View Code? Open in Web Editor NEWThis is the official dahdi-linux repository. All issues and PR should be raised here.
License: GNU General Public License v2.0
This is the official dahdi-linux repository. All issues and PR should be raised here.
License: GNU General Public License v2.0
DAHDI Telephony Interface Driver ================================= Asterisk Development Team <[email protected]> $Revision$, $Date$ DAHDI stands for Digium Asterisk Hardware Device Interface. This package contains the kernel modules for DAHDI. For the required userspace tools see the package dahdi-tools. Supported Hardware ------------------ Digital Cards ~~~~~~~~~~~~~ - wcte43x: * Digium TE435: PCI express quad-port T1/E1/J1 * Digium TE436: PCI quad-port T1/E1/J1 * Digium TE235: PCI express dual-port T1/E1/J1 * Digium TE236: PCI dual-port T1/E1/J1 - wcte13xp: * Digium TE131: PCI express single-port T1/E1/J1 * Digium TE133: PCI express single-port T1/E1/J1 with echocan * Digium TE132: PCI single-port T1/E1/J1 * Digium TE134: PCI single-port T1/E1/J1 with echocan - wct4xxp: * Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1 * Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1 * Digium TE220: PCI-Express dual-port T1/E1/J1 * Digium TE420: PCI-Express quad-port T1/E1/J1 * Digium TE820: PCI-Express eight-port T1/E1/J1 - wcte12xp: * Digium TE120P: PCI single-port T1/E1/J1 * Digium TE121: PCI-Express single-port T1/E1/J1 * Digium TE122: PCI single-port T1/E1/J1 - wcte11xp: * Digium TE110P: PCI single-port T1/E1/J1 - wct1xxp: * Digium T100P: PCI single-port T1 * Digium E100P: PCI single-port E1 - wcb4xxp: * Digium B410: PCI quad-port BRI * Digium B233: PCI-Express dual-port BRI with echo can * Digium B234: PCI dual-port dual-port BRI with echo can * Digium B433: PCI-Express quad-port BRI with echo can * Digium B434: PCI quad-port BRI with echo can Analog Cards ~~~~~~~~~~~~ - wcaxx: * Digium A8A: PCI up to 8 mixed FXS/FXO ports * Digium A8B: PCI express up to 8 mixed FXS/FXO ports * Digium A4A: PCI up to 4 mixed FXS/FXO ports * Digium A4B: PCI express up to 4 mixed FXS/FXO ports - wctdm24xxp: * Digium TDM2400P/AEX2400: up to 24 analog ports * Digium Hx8 Series: Up to 8 analog or BRI ports - wctdm: * Digium TDM400P: up to 4 analog ports - xpp: Xorcom Astribank: a USB connected unit of up to 32 ports (including the digital BRI and E1/T1 modules) - wcfxo: X100P, similar and clones. A simple single-port FXO card Other Drivers ~~~~~~~~~~~~~ - wctc4xxp: Digium hardware transcoder cards (also need dahdi_transcode) - dahdi_dynamic_eth: TDM over Ethernet (TDMoE) driver. Requires dahdi_dynamic - dahdi_dynamic_loc: Mirror a local span. Requires dahdi_dynamic Installation ------------ If all is well, you just need to run the following: make make install You'll need the utilities provided in the package dahdi-tools to configure DAHDI devices on your system. If using `sudo` to build/install, you may need to add /sbin to your PATH. If you still have problems, read further. Build Requirements ~~~~~~~~~~~~~~~~~~ gcc and friends. Generally you will need to install the package gcc. There may be cases where you will need a specific version of gcc to build kernel modules. Kernel Source / "Headers" ^^^^^^^^^^^^^^^^^^^^^^^^^ - Building DAHDI-linux requires a kernel build tree. - This should basically be at least a partial kernel source tree and most importantly, the exact kernel .config file used for the build as well as several files generated at kernel build time. - KERNEL_VERSION is the output of the command `uname -r` - If you build your own kernel, you need to point to the exact kernel build tree. Luckily for you, this will typically be pointed by the symbolic link /lib/modules/KERNEL_VERSION/build which is the location zaptel checks by default. - If you use a kernel from your distribution you will typically have a package with all the files required to build a kernel modules for your kernel image. * On Debian and Ubuntu this is +++ linux-headers-`uname -r` +++ * On Fedora, RHEL and compatibles (e.g. CentOS) and SUSE this is the kernel-devel package. Or if you run kernel-smp or kernel-xen, you need kernel-smp-devel or kernel-xen-devel, respectively. * In some distributions (e.g.: in RHEL/CentOS, Fedora, Ubuntu) the installation of the kernel-devel / kernel-headers package will be of a version that is newer than the one you currently run. In such a case you may need to upgrade the kernel package itself as well and reboot. - To point explicitly to a different build tree: set KSRC to the kernel source tree or KVERS to the exact kernel version (if "headers" are available for a different version). This parameter must be run on every calls to 'make' (e.g.: 'make clean', 'make install'). make KVERS=2.6.18.Custom make KSRC=/home/tzafrir/kernels/linus Kernel Configuration ^^^^^^^^^^^^^^^^^^^^ If you build a custom kernel, note the following configuration items: - CONFIG_CRC_CCITT must be enabled ('y' or 'm'). On 2.6 kernels this can be selected These can be selected from the "Library Routines" submenu during kernel configuration via "make menuconfig". - DAHDI will work if you disable module unloading. But you may need extra reboots. - DAHDI needs the BKL (Big Kernel Lock). This may be annoying in >=2.6.37 kernels. Make sure you enable CONFIG_BKL on those kernels. Installing to a Subtree ~~~~~~~~~~~~~~~~~~~~~~~ The following may be useful when testing the package or when preparing a package for a binary distribution (such as an rpm package) installing onto a subtree rather than on the real system. make install DESTDIR=targetdir This can be useful for any partial install target of the above (e.g: install-modules or install-programs). the targetdir must be an absolute path, at least if you install the modules. To install to a relative path you can use something like: make install-modules DESTDIR=$PWD/target Extra Modules ~~~~~~~~~~~~~ To build extra modules / modules directory not included in the DAHDI distribution, use the optional variables MODULES_EXTRA and SUBDIRS_EXTRA: make MODULES_EXTRA="mod1 mod2" make MODULES_EXTRA="mod1 mod2" SUBDIRS_EXTRA="subdir1/ subdir1/" Static Device Files ~~~~~~~~~~~~~~~~~~~ Userspace programs communicate with the DAHDI modules through special device files under /dev/dahdi . Those are normally created by udev, but if you use an embedded-type system and don't wish to use udev, you can generate them with the following script, from the source directory: ./build_tools/make_static_devs This will generate the device files under /dev/dahdi . If you need to generate them elsewhere (e.g. `tmp/newroot/dev/dahdi`) use the option -d to the script: ./build_tools/make_static_devs -d tmp/newroot/dev/dahdi DKMS ~~~~ DKMS, Dynamic Kernel Module Support, is a framework for building Linux kernel modules. It is used, among others, by several distributions that package the DAHDI kernel modules. DKMS is designed to provide updates over drivers installed from original kernel modules tree. Thus it installed modules into /lib/modules/updates or /lib/modules/VERSION/updates . This is generally not an issue on normal operation. However if you try to install DAHDI from source on a system with DAHDI installed from DKMS this way (potentially of an older version), be sure to remove the DKMS-installed modules from the updates directory. If you're not sure, the following command will give you a clue of the versions installed: find /lib/modules -name dahdi.ko ===== LINUX_DIR The relative path to the dahdi-linux tree. The default is '.' and normally there's no reason to override it. ===== TOOLS_DIR The relative path to the dahdi-tools tree. The default is 'dahdi-tools'. ===== XPP_SYNC Set a syncing astribank. See xpp_sync(8). Default is 'auto'. ===== AST_SCRIPT The command for an init.d script to start/stop Asterisk. Should accept 'start' and 'stop' commands. Use 'true' if you want to make that a no-op. Defaults to '/etc/init.d/asterisk' . ===== MODULES_LOAD Manual list of modules. They will be loaded by insmod. If reside in a subdir, add it explicitly. Modules for the drivers that are detected on the system will be added by the script. Default: 'dahdi dahdi_echocan_mg2' ===== REMOVE_MODULES A list of modules to remove when unloading. Will be resolved recursively. The default is 'dahdi'. You may also want to have 'oslec' or 'hpec' there if you use them. ===== KVERS If you want to build DAHDI for a different kernel version than the one currently running on the system (mostly useful for a remote install). Note that you will normally need to export this, in order for this to take effect on the 'make' command. In live/live.conf itself have the line: export KVERS="2.6.39-local" ===== KSRC Alternatively, if you want to point to an exact kernel source tree, set it with KSRC. Just like KVERS above, it needs to be explicitly exported. export KSRC="/usr/src/tree/linux" Module Parameters ----------------- The kernel modules can be configured through module parameters. Module parameters can optionally be set at load time. They are normally set (if needed) by a line in a file under /etc/modprobe.d/ or in the file /etc/modprobe.conf. Example line: options dahdi debug=1 The module parameters can normally be modified at runtime through sysfs: pungenday:~# cat /sys/module/dahdi/parameters/debug 0 pungenday:~# echo 1 >/sys/module/dahdi/parameters/debug pungenday:~# cat /sys/module/dahdi/parameters/debug 1 Viewing and setting parameters that way is possible as of kernel 2.6 . In kernels older than 2.6.10, the sysfs "files" for the parameters reside directly under /sys/module/'module_name' . Useful module parameters: === debug (most modules) Sets debug mode / debug level. With most modules 'debug' can be either disabled (0, the default value) or enabled (any other value). wctdm and wcte1xp print several extra debugging messages if the value of debug is more than 1. Some modules have "debugging flags" bits - the value of debug is a bitmask and several messages are printed if some bits are set: To get a list of parameters supported by a module, use modinfo module_name Or, for a module you have just built: modinfo ./drivers/dahdi/module_name.ko For the xpp modules this will also include the description and default value of the module. You can find a list of useful xpp module parameters in README.Astribank . - wctdm24xxp: * 1: DEBUG_CARD * 2: DEBUG_ECHOCAN - wct4xxp: * 1: DEBUG_MAIN * 2: DEBUG_DTMF * 4: DEBUG_REGS * 8: DEBUG_TSI * 16: DEBUG_ECHOCAN * 32: DEBUG_RBS * 64: DEBUG_FRAMER - xpp: See also README.Astribank: * 1: GENERAL - General debug comments. * 2: PCM - PCM-related messages. Tend to flood logs. * 4: LEDS - Anything related to the LEDs status control. The driver produces a lot of messages when the option is enabled. * 8: SYNC - Synchronization related messages. * 16: SIGNAL - DAHDI signalling related messages. * 32: PROC - Messages related to the procfs interface. * 64: REGS - Reading and writing to chip registers. Tends to flood logs. * 128: DEVICES - Device instantiation, destruction and such. * 256 - COMMANDS - Protocol commands. Tends to flood logs. + + The script xpp_debug in the source tree can help settting them at run time. === deftaps (dahdi) The default size for the echo canceller. The number is in "taps", that is "samples", 1/8 ms. The default is 64 - for a tail size of 8 ms. Asterisk's chan_dahdi tends to pass its own value anyway, with a different default size. So normally setting this doesn't change anything. === max_pseudo_channels (dahdi) The maximum number of pseudo channels that dahdi will allow userspace to create. Pseudo channels are used when conferencing channels together. The default is 512. === auto_assign_spans (dahdi) See <<_span_assignments,Span Assignments>> below. XPP (Astribank) module parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ==== debug (all modules) - see above. ==== dahdi_autoreg (xpp) Deprecated. See dahdi.<<_auto_assign_spans,auto_assign_spans>> above. Originally had a somewhat similar (but xpp-specific and more limited) role to auto_assign_spans. For backward compatibility this variable is still kept, but its value is unused. Astribanks will auto-register with dahdi if auto_assign_spans is not set. ==== tools_rootdir (xpp) Defaults to /. Passed (as the variable DAHDI_TOOLS_ROOTDIR) to generated events (which can be used in udev hooks). Also serves as the base of the variable DAHDI_INIT_DIR (by default: $DAHDI_TOOLS_DIR/usr/share/dahdi). ==== initdir (xpp) Deprecated. Setting both initdir and tools_rootdir will generate an error. A directory under tools_rootdir containing the initialization scripts. The default is /usr/share/dahdi . Setting this value could be useful if that location is inconvenient for you. ==== rx_tasklet (xpp) Enable (1) or disable (0) doing most of the packets processing in separate tasklets. This should probably help on higher-end systems with multiple Astribanks. ==== vmwi_ioctl (xpd_fxs) Does userspace support VMWI notification via ioctl? Default: 1 (yes). Disable this (0) to have the driver attempt to detect the voicemail message waiting indication status for this port from FSK messages userspace (Asterisk) sends. Set the ports to use AC neon-lamp style message waiting indication. The detection from the FSK messages takes extra CPU cycles but is required with e.g. Asterisk < 1.6.0 . Also note that in order for this parameter to take effect, it must be set before the span is registered. This practically means that it should be set through modprobe.d files. See also Voicemail Indication in README.Astribank. ==== usb1 (xpp_usb) Enable (1) or disable (0) support of USB1 devices. Disabled by default. USB1 devices are not well-tested. It seems that they don't work at all for Astribank BRI. Generally they should work with the current code, but we expect the voice quality issues. Hence we would like to make it very clear that you if you have a USB1 port (rather than a USB2 one, as recommended) you will have to take an action to enable the device. ==== poll intervals (various) There are various values which the driver occasionally polls the device for. For instance, the parameter poll_battery_interval for xpd_fxo to poll the battery, in order to know if the telco line is actually connected. The value of those parameters is typically a number in milliseconds. 0 is used to disable polling. Under normal operation there should be no reason to play with those parameters. ==== dtmf_detection (xpd_fxs) Enable (1) or disable (0) support of hardware DTMF detection by the Astribank. ==== caller_id_style (xpd_fxo) Various types of caller ID signalling styles require knowing the PCM even when the line is on-hook (which is usually a waste of CPU and bandwidth). This parameter allows fine-tuning the behaviour here: * 0 (default) - Don't pass extra PCM when on-hook. * 1 ETSI-FSK: Wait for polarity reversal to come before a ring and then start passing PCM until the caller ID has been passed. * 2 ETSI-DTMF: Always pass PCM and generate a DTMF if polarity reversal is detected before ring. * 3 Passthrough: Always pass PCM as-is. This parameter is read-only. It cannot be changed at run-time. ==== battery_threshold (xpd_fxo) Minimum voltage that shows there is battery. Defaults to 3. Normally you should not need to change this, unless dealing with a funky PSTN provider. ==== battery_debounce (xpd_fxo) Minimum interval (msec) for detection of battery off (as opposed to e.g. a temporary power denial to signal a hangup). Defaults to 1000. As with battery_threshold above, there's normally no need to tweak it. ==== use_polrev_firmware (xpd_fxo) Enable (1, default) or disable (0) support for polarity reversal detection in the hardware. Only has effect with PIC_TYPE_2.hex rev. >= 11039 and with the initialization changes (init_card_2_30) in rev. 949aa49. This parameter is read-only. It cannot be changed at run-time. Internals --------- DAHDI Device Files ~~~~~~~~~~~~~~~~~~ Userspace programs will usually interact with DAHDI through device files under the /dev/dahdi directory (pedantically: character device files with major number 196) . Those device files can be generated statically or dynamically through the udev system. * /dev/dahdi/ctl (196:0) - a general device file for various information and control operations on the DAHDI channels. * /dev/dahdi/chan/N/M - A device file for channel M in span N - Both N and M are zero padded 3 digit numbers - Both N and M start at 001 - M is chanpos - numbering relative to the current span. * /dev/dahdi/NNN (196:NNN) - for NNN in the range 1-249. A device file for DAHDI channel NNN. It can be used to read data from the channel and write data to the channel. It is not generated by default but may be generated as a symlink using udev rules. * /dev/dahdi/transcode (196:250) - Used to connect to a DAHDI transcoding device. * /dev/dahdi/timer (196:253) - Allows setting timers. Used anywhere? * /dev/dahdi/channel (196:254) - Can be used to open an arbitrary DAHDI channel. This is an alternative to /dev/dahdi/NNN that is not limited to 249 channels. * /dev/dahdi/pseudo (196:255) - A timing-only device. Every time you open it, a new DAHDI channel is created. That DAHDI channel is "pseudo" - DAHDI receives no data in it, and only sends garbage data with the same timing as the DAHDI timing master device. DAHDI Timing ~~~~~~~~~~~~ A PBX system should generally have a single clock. If you are connected to a telephony provider via a digital interface (e.g: E1, T1) you should also typically use the provider's clock (as you get through the interface). Hence one important job of Asterisk is to provide timing to the PBX. DAHDI "ticks" once per millisecond (1000 times per second). On each tick every active DAHDI channel reads and 8 bytes of data. Asterisk also uses this for timing, through a DAHDI pseudo channel it opens. However, not all PBX systems are connected to a telephony provider via a T1 or similar connection. With an analog connection you are not synced to the other party. And some systems don't have DAHDI hardware at all. Even a digital card may be used for other uses or is simply not connected to a provider. DAHDI cards are also capable of providing timing from a clock on card. Cheap x100P clone cards are sometimes used for that purpose. If a hardware timing source either cannot be found or stops providing timing during runtime, DAHDI will automatically use the host timer in order provide timing. You can check the DAHDI timing source with dahdi_test, which is a small utility that is included with DAHDI. It runs in cycles. In each such cycle it tries to read 8192 bytes, and sees how long it takes. If DAHDI is not loaded or you don't have the device files, it will fail immediately. If you lack a timing device it will hang forever in the first cycle. Otherwise it will just give you in each cycle the percent of how close it was. Also try running it with the option -v for a verbose output. Spans and Channels ~~~~~~~~~~~~~~~~~~ DAHDI provides telephony *channels* to the userspace applications. Those hannels are incorporated into logical units called *spans*. With digital telephony adapters (e.g: E1 or T1), a span normally represents a single port. With analog telephony a span typically represents a PCI adapter or a similar logical unit. Both channels and spans are identified by enumerating numbers (beginning with 1). The number of the channel is the lowest unused one when it is generated, and ditto for spans. There are up to 128 spans and 1024 channels. This is a hard-wired limit (see dahdi/user.h . Several places throuout the code assume a channel number fits in a 16 bits number). Channel and span numbers start at 1. Span Assignments ~~~~~~~~~~~~~~~~ A DAHDI device (e.g. a PCI card) is represented within the DAHDI drivers as a 'DAHDI device'. Normally (with auto_assign_spans=1 in the module dahdi, which is the default), when a device is discovered and loaded, it registers with the DAHDI core and its spans automatically become available. However if you have more than one device, you may be interested to set explicit spans and channels numbers for them. To use manual span assigment, set 'auto_assign_spans' to 0 . e.g. in a file under /etc/modprobe.d/ include the following line: options dahdi auto_assign_spans=0 You will then need to assign the spans manually at device startup. You will need to assign a span number and channel numbers for each available span on the system. On my test system I have one BRI PCI card and one Astribank BRI+FXS: # grep . /sys/bus/dahdi_devices/devices/*/spantype /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:1:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:2:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:3:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:4:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:5:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:6:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:7:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:8:BRI /sys/bus/dahdi_devices/devices/astribanks:xbus-00/spantype:9:FXS /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:1:TE /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:2:TE /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:3:NT /sys/bus/dahdi_devices/devices/pci:0000:00:09.0/spantype:4:NT All spans here, except the FXS one, are BRI spans with 3 channels per span. In order to assign a span, we write three numbers separated by colons to the file 'assign_span' in the SysFS node local_num:span_num:base_chan_num Thus: echo 9:5:10 >/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span echo 2:8:40 >/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/assign_span echo 1:1:1 >/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span echo 4:6:20 >/sys/bus/dahdi_devices/devices/pci:0000:00:09.0/assign_span echo 3:2:5 >/sys/bus/dahdi_devices/devices/astribanks:xbus-00/assign_span As you can see, the order of span numbers or local span number is insignificant. However the order of channel numbers must be the same as that of span numbers. Which indeed produced: # head -n3 -q /proc/dahdi/* Span 1: XBUS-00/XPD-00 "Xorcom XPD [usb:LAB-0003].1: BRI_NT" 1 XPP_BRI_NT/00/00/0 Span 2: XBUS-00/XPD-02 "Xorcom XPD [usb:LAB-0003].3: BRI_TE" 5 XPP_BRI_TE/00/02/0 Span 5: XBUS-00/XPD-10 "Xorcom XPD [usb:LAB-0003].9: FXS" (MASTER) 10 XPP_FXS/00/10/0 Span 6: B4/0/4 "B4XXP (PCI) Card 0 Span 4" RED 23 B4/0/4/1 YELLOW Span 8: B4/0/2 "B4XXP (PCI) Card 0 Span 2" RED 40 B4/0/2/1 RED Likewise spans can be unassigned by writing to the 'unassign-span' "file". Dynamic Spans ~~~~~~~~~~~~~ Dynamic spans are spans that are not represented by real hardware. Currently there are two types of them: tdmoe:: TDM over Ethernet. A remote span is identified by an ethernet (MAC) address. local:: Generates a span that is actually a loopback to a different local span. Modules that support the dynamic spans are typically loaded at the time the ioctl DAHDI_DYNAMIC_CREATE is called. This is typically called by dahdi_cfg when it has a line such as: dynamic,somename,params in /etc/dahdi/system.conf . In that case it will typically try to load (through modprobe) the modules dahdi_dynamic and dahdi_dynamic_'somename'. It will then pass 'params' to it. Dynamic spans are known to be tricky and are some of the least-tested parts of DAHDI. Echo Cancellers ~~~~~~~~~~~~~~~ (To be documented later) Tone Zones ~~~~~~~~~~ (To be documented later) PROCFS Interface: /proc/dahdi ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A simple way to get the current list of spans and channels each span contains is the files under /proc/dahdi . /proc/dahdi is generated by DAHDI as it loads. As each span registers to DAHDI, a file under /proc/dahdi is created for it. The name of that file is the number of that span. Each file has a 1-line title for the span followed by a few optional general counter lines, an empty line and then a line for each channel of the span. The title line shows the number of the span, its name and title, and (potentially) the alarms in which it is. The title shows the span number and name, followed by any alarms the span may have: For example, here is the first span in my system (with no alarms): Span 1: XBUS-00/XPD-00 "Xorcom XPD #0/0: FXS" There are several extra optional keywords that may be added there: (Master):: This span is the master span. See <<_dahdi_timing,DAHDI Timing>>. ClockSource:: The clock source among several spans that belong to a single E1/J1/T1 card. RED/YELLOW/RED/NOTOPEN/LOOP/RECOVERING:: The span is in alarm Following that line there may be some optional lines about IRQ misses, timing slips and such, if there are any. The channel line for each channel shows its channel number, name and the actual signalling assigned to it through dahdi_cfg. Before being configured by dahdi_cfg: This is DAHDI channel 2, whose name is 'XPP_FXS/0/0/1'. 2 XPP_FXS/0/0/1 After being configured by dahdi_cfg: the signalling 'FXOLS' was added. FXS channels have FXO signalling and vice versa: 2 XPP_FXS/0/0/1 FXOLS If the channel is in use (typically opened by Asterisk) then you will see an extra '(In use)': 2 XPP_FXS/0/0/1 FXOLS (In use) SysFS Interface ~~~~~~~~~~~~~~~ DAHDI exposes several interfaces under the SysFS virtual file system. SysFS represents kernel objects in nodes - directories. There properties are often files. They may also contain other nodes or include symlinks to other nodes. Class DAHDI ^^^^^^^^^^^ Under /sys/class/dadhi there exists a node for the non-channel DAHDI device file under /dev/dahdi. The name is 'dahdi!foo' for the file '/dev/dahdi/foo' (udev translates exclamation marks to slashes). Those nodes are not, for the most part, proper SysFS nodes, and don't include any interesting properties. The files in this class `ctl`, `timer`, `channel`, `pseudo` and (if exists) `transcode`. Devices Bus ^^^^^^^^^^^ Each DAHDI device (a physical device, such as a PCI card) is represented by a node under /sys/bus/dahdi_devices/devices named with the name of its device. Its attributes include: ===== /sys/bus/dahdi_devices/devices/DEVICE/assgin-span Write-only attribute: this device's spans should now be assigned ("registered"). See section about <<_span_assignments>>. ===== /sys/bus/dahdi_devices/devices/DEVICE/auto-assign Write-only attribute. Spans in the device auto-assign ("register" as in the original interface). See section about <<_span_assignments>>. ===== /sys/bus/dahdi_devices/devices/DEVICE/hardware_id A unique hardware-level identifier (e.g. serial number), if available. ===== /sys/bus/dahdi_devices/devices/DEVICE/manufacturer The name of the manufacturer. Freeform-string. ===== /sys/bus/dahdi_devices/devices/DEVICE/registration_time The time at which the device registered with the DAHDI core. Example value: "0005634136.941901429". ===== /sys/bus/dahdi_devices/devices/DEVICE/spantype A line for each available span: <num>:<type>. This has to be provided here as in the case of manual assignment, userspace may need to know it before span nodes are created. ===== /sys/bus/dahdi_devices/devices/DEVICE/spantype Device type. ===== /sys/bus/dahdi_devices/devices/DEVICE/unassign-span Write-only attribute: the span whose device-local number is written should now be unassigned ("unregistered"). See section about <<_span_assignments>>. Spans Bus ^^^^^^^^^ Each DAHDI span is represented by a node under /sys/bus/dahdi_spans/devices with the name 'span-N' (where N is the number of the span). Spans of each device also reside under the node of the device. Useful attributes in the span node: ===== /sys/bus/dahdi_spans/devices/span-N/alarms The alarms of the span. Currently this is a numeric representation. This may change in the future. ===== /sys/bus/dahdi_spans/devices/span-N/basechan The channel number of the first channel. The channel numbers of the following channels are guaranteed to follow it. ===== /sys/bus/dahdi_spans/devices/span-N/channels The number of the channels in the span. ===== /sys/bus/dahdi_spans/devices/span-N/desc A free-form description of the span. ===== /sys/bus/dahdi_spans/devices/span-N/is_digital 1 if the span is digital, 0 if it isn't. ===== /sys/bus/dahdi_spans/devices/span-N/is_sync_master 1 if the span is the sync master, 0 if it isn't. ===== /sys/bus/dahdi_spans/devices/span-N/lbo LBO setting for the channel. ===== /sys/bus/dahdi_spans/devices/span-N/lineconfig The framing and coding of the span, for a digital span. Textual represenation: <B8ZS|AMI|HDB3>/<D4|ESF|CCS>[/CRC4] ===== /sys/bus/dahdi_spans/devices/span-N/local_spanno The number of the span within the DAHDI device. ===== /sys/bus/dahdi_spans/devices/span-N/name A concise name for this span. ===== /sys/bus/dahdi_spans/devices/span-N/spantype A very short type string. ===== /sys/bus/dahdi_spans/devices/span-N/syncsrc Current sync source. ==== sys/bus/dahdi_spans/drivers/generic_lowlevel/master_span All spans in the bus are handled by a single driver. The driver has one non-standard attribute: master_span. printing it shows the current DAHDI master span writing a number to it forces setting this span as the master span. Channels Bus ^^^^^^^^^^^^ Each DAHDI channel is represented by a node under /sys/bus/dahdi_channels/devices with the name 'dahdi!channels!N!M' (where N is the number of the span and M is the number of the channel in the span - chanpos). Channels of each span also reside under the node of the span. Useful attributes in the channel node (All attributed listed below are read-only): ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/alarms List of names of the current active alarms (space separated). Normally (no alarms) empty. Example: RED YELLOW ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/blocksize The block size set by userspace. ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/channo The (global) channel number. ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/chanpos The channel number within the span. ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/dev Major and minor device numbers. ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/ec_factory The name of the echo canceller to be used in the channel, if one is configured. Example: MG2 ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/ec_state State of the echo canceller. ACTIVE: configured and inuse. INACTIVE otherwise. ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/in_use 1 if the channel is in use (was opepend by userspace), 0 otherwise. ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/name A name string for the channel ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/sig The signalling types set for the channel. A space-separated list of signalling types. ===== /sys/bus/dahdi_spans/devices/span-N/dahdi!channels!N!M/sigcap The signalling types this channel may be configured to handle. A space- separated list of signalling types. User-space Interface ~~~~~~~~~~~~~~~~~~~~ User-space programs can only work with DAHDI channels. The basic operation is 'read()' to read audio from the device and write() to write audio to it. Audio can be encoded as either alaw (G.711a) or (m)ulaw (G.711u). See the ioctl DAHDI_SETLAW. While it is technically possible to use /dev/dahdi/NUMBER directly, this will only work for channel numbers up to 249. Generally you should use: int channo = CHAN_NUMBER_TO_OPEN; int rc; int fd = open("/dev/dahdi/channel", O_RDRW, 0600); // Make sure fd >= 0 rc = ioctl(fd, DAHDI_SPECIFY, &channo) < 0); // Make sure this rc >= 0 FIXME: there's more to tell about the user-space interface. Configuration ~~~~~~~~~~~~~ Most of the configuration is applied from userspace using the tool 'dahdi_cfg' in the package dahdi_tools. This section will not cover the specifics of that file. Rather it will cover the way configuration from this file is applied. Also note that there are other methods to configure DAHDI drivers: there are <<_module_parameters,Module Parameters>>. The xpp driver have their own separate initialization scripts and xpp.conf that arecovered in README.Astribank. When a span is registered, it is considered "unconfigured". Only after dahdi_cfg has been run to apply configuration, the span is ready to run. Some of the configuration is handled by the DAHDI core. Some of it is handled by callbacks, which are function pointers in the `struct dahdi_span': 'spanconfig', 'chanconfig' and (in a way) 'startup'. Dahdi_cfg starts by reading the configuration from the configuration file ('/etc/dahdi/system.conf', by default), and creating a local configuration to apply. If you use -v, at this stage it will pront the configuration that is "about to be configured". Then it will start to actually apply the configuration. Before actually applying configuration, it destroys any existing <<_dynamic_spans,dynamic spans>> and generates new ones (if so configured. FIXME: what about running DAHDI_SPANCONFIG for new dynamic spans?). Next thing it will do is apply the parameters from *span* lines using the ioctl DAHDI_SPANCONFIG. Some generic processing of parameters passed in DAHDI_SPANCONFIG is done in the DAHDI core, in the callback function spanconfig in , but most of it is left to 'spanconfig' callback of the span (if it exists. This one typically does not exists on analog cards). Now dahdi_cfg will ask each existing channel for its existing configuration and apply configuration if configuration changes are needed. Configuration is applied to the channels using the ioctl call DAHDI_CHANCONFIG ioctl. As in the case of the span configuration, part of it is applied by the DAHDI core, and then it is handed over to the span's chanconfig callback. Typically all spans will have such a callback. <<_echo_cancellers,Echo cancellers>> and <<_tone_zones,tone-zones>> are handled separately later. Once everything is done, the ioctl DAHDI_STARTUP is called for every span. This is also translated to a call to the optional span callback 'startup'. Finally the ioctl DAHDI_HDLC_RATE is called for every channel (that is: if '56k' is not set for the channel, it will be explicitly set to the standard HDLC rate of 64k). Low-Level Drivers ~~~~~~~~~~~~~~~~~ Low-level drivers create spans ('struct dahdi_span'). They register the spans with the DAHDI core using 'dahdi_device_register()'. 'struct dahdi_span' has a number of informative members that are updated solely by the low-level driver: name:: A concise span name. E.g.: Foo/1 desc:: A slightly longer span name. spantype:: Span type in text form. manufacturer:: Span's device manufacturer devicetype:: Span's device type location:: span device's location in system irq:: IRQ for this span's hardware irqmisses:: Interrupt misses timingslips:: Clock slips There are various function pointers in the struct 'dahdi_span' which are used by the DAHDI core to call the low-level driver. Most of them are optional. The following apply to a span: setchunksize:: FIXME: seems to be unused. spanconfig:: Basic span configuration (called from dahdi_cfg). startup:: Last minute initialization after the configuration was applied. shutdown:: Explicit shutdown (e.g. for dynamic spans). Normally not needed. maint:: Enable/disable maintinance mode (FIXME: document). sync_tick:: Get notified that the master span has ticked. The following apply to a single channel. chanconfig:: Configure the channel (called from dahdi_cfg). open:: Channel was opened for read/write from user-space. close:: Channel was closed by user-space. ioctl:: Handle extra ioctls. Should return -ENOTTY if ioctl is not known to the channel echocan_create:: Create a custom echo canceller. Normally used for providing a hardware echo canceller. If NULL, the standard DAHDI echo canceller modules will be used. rbsbits:: Copy signalling bits to device. See below on signalling. hooksig:: Implement RBS-like signalling-handling. See below on signalling. sethook:: Handle signalling yourself. See below on signalling. hdlc_hard_xmit:: Used to tell an onboard HDLC controller that there is data ready to transmit. audio_notify:: (if DAHDI_AUDIO_NOTIFY is set) - be notified when the channel is (or isn't) in audio mode. Which may mean (for an ISDN B-channel) that its data need not be sent. There are several alternative methods for a span to use for signalling. One of them should be used. Signalling: rbsbits ^^^^^^^^^^^^^^^^^^^ If the device is a CAS interface, the driver should copy the signalling bits to and from the other side, and DAHDI will handle the signalling. The driver just need to provide a 'rbsbits' and set DAHDI_FLAG_RBS in the span->flags. Note that 'rbs' (Robed Bits Signalling) here merely refers to the (up to) 4 signalling bits of the channel. In T1 they are transmitted by "robbing" bits from the channels and hence the name. In E1 they are transmitted in a timeframe of their own. The driver should then signal a change in the signalling bits in a channel using dahdi_rbsbits(). Signalling: hooksig ^^^^^^^^^^^^^^^^^^^ If the device does not know about signalling bits, but has their equivalents (i.e. can disconnect battery, detect off hook, generate ring, etc directly) then the driver can specify a 'sethook' function and set DAHDI_FLAG_RBS in span->flags. In that case DAHDI will call that function whenever the signalling state changes. The hooksig function is only used if the rbsbits function is not set. The span should notify DAHDI of a change of signalling in a channel using dahdi_hooksig(). Signalling: sethook ^^^^^^^^^^^^^^^^^^^ Alternatively, if DAHDI_FLAG_RBS is not set in the flags of the span (to use either rbsbits or hooksig), the DAHDI core will try to call the 'sethook' function of the span (if it exists) to handle individual hook states. The span should then notify DAHDI of a change in the signalling state using dahdi_sethook(). FIXME: anybody using this one? ABI Compatibility ~~~~~~~~~~~~~~~~~ Like any other kernel code, DAHDI strives to maintain a stable interface to userspace programs. The API of DAHDI to userspace programs, dahdi/user.h, has remained backward-compatible for a long time and is expected to remain so in the future. With the ABI (the bits themselves) things are slightly trickier. DAHDI's interface to userspace is mostly ioctl(3) calls. Ioctl calls are identified by a number that stems from various things, one of which is the size of the data structure passed between the kernel and userspace. Many of the DAHDI ioctl-s use some specific structs to pass information between kernel and userspace. In some cases the need arose to pass a few more data members in each call. Simply adding a new member to the struct would have meant a new number for the ioctl, as its number depends on the size of the data passed. Thus we would add a new ioctl with the same base number and with the original struct. So suppose we had the following ioctl: ---------------------------------- struct dahdi_example { int sample; } #define DAHDI_EXAMPLE _IOWR (DAHDI_CODE, 62, struct dahdi_example) ---------------------------------- And we want to add the field 'int onemore', we won't just add it to the struct. We will do something that is more complex: ------------------------------------ /* The original, unchanged: */ struct dahdi_example_v1 { int sample; } /* The new struct: */ struct dahdi_example { int sample; int onemore; } #define DAHDI_EXAMPLE_V1 _IOWR(DAHDI_CODE, 62, struct dahdi_example_v1) #define DAHDI_EXAMPLE _IOWR(DAHDI_CODE, 62, struct dahdi_example) ------------------------------------ We actually have here two different ioctls: the old DAHDI_EXAMPLE would be 0xC004DA3E . DAHDI_EXAMPLE_V1 would have the same value. But the new value of DAHDI_EXAMPLE would be 0xC008DA3E . Programs built with the original dahdi/user.h (before the change) use the original ioctl, whether or not the kernel code is actually of the newer version. Thus in most cases there are no compatibility issues. When can we have compatibility issues? If we have code built with the new dahdi/user.h, but the loaded kernel code (modules) are of the older version. Thus the userspace program will try to use the newer DAHDI_EXAMPLE (0xC008DA3E). But the kernel code has no handler for that ioctl. The result: the error 25, ENOTTY, which means "Inappropriate ioctl for device". As a by-product of that method, for each interface change a new #define is added. That definition is for the old version and thus it might appear slightly confusing in the code, but it is useful for writing code that works with all versions of DAHDI. Past Incompatibilities ^^^^^^^^^^^^^^^^^^^^^^ .DAHDI 2.3: DAHDI_SPANINFO_V1 (extra members added). This will typically only be used on ISDN (PRI/BRI) spans in Asterisk. .DAHDI 2.2: * DAHDI_GET_PARAMS_V1, DAHDI_GETCONF_V1, DAHDI_SETCONF_V1, DAHDI_GETGAINS_V1 ('direction' changed from 'R' to 'RW' to fix FreeBSD support). * DAHDI_CONFDIAG_V1, DAHDI_CHANDIAG_V1 (fixed direction). Alarm Types ~~~~~~~~~~~ An alarm indicates that a port is not available for some reason. Thus it is probably not a good idea to try to call out through it. Red Alarm ^^^^^^^^^ Your T1/E1 port will go into red alarm when it cannot maintain synchronization with the remote switch. A red alarm typically indicates either a physical wiring problem, loss of connectivity, or a framing and/or line-coding mismatch with the remote switch. When your T1/E1 port loses sync, it will transmit a yellow alarm to the remote switch to indicate that it's having a problem receiving signal from the remote switch. The easy way to remember this is that the R in red stands for "right here" and "receive"... indicating that we're having a problem right here receiving the signal from the remote switch. Yellow Alarm ^^^^^^^^^^^^ (RAI -- Remote Alarm Indication) Your T1/E1 port will go into yellow alarm when it receives a signal from the remote switch that the port on that remote switch is in red alarm. This essentially means that the remote switch is not able to maintain sync with you, or is not receiving your transmission. The easy way to remember this is that the Y in yellow stands for "yonder"... indicating that the remote switch (over yonder) isn't able to see what you're sending. Blue Alarm ^^^^^^^^^^ (AIS -- Alarm Indication Signal) Your T1/E1 port will go into blue alarm when it receives all unframed 1s on all timeslots from the remote switch. This is a special signal to indicate that the remote switch is having problems with its upstream connection. dahdi_tool and Asterisk don't correctly indicate a blue alarm at this time. The easy way to remember this is that streams are blue, so a blue alarm indicates a problem upstream from the switch you're connected to. Recovering from Alarm ^^^^^^^^^^^^^^^^^^^^^ TODO: explain. Loopback ^^^^^^^^ Not really an alarm. Indicates that a span is not available, as the port is in either a local or remote loopback mode. Not Open ^^^^^^^^ Something is not connected. Used by e.g. the drivers of the Astribank to indicate a span that belongs to a device that has been disconnected but is still being used by userspace programs and thus can't e destroyed. License ------- This package is distributed under the terms of the GNU General Public License Version 2, except for some components which are distributed under the terms of the GNU Lesser General Public License Version 2.1. Both licenses are included in this directory, and each file is clearly marked as to which license applies. If you wish to use the DAHDI drivers in an application for which the license terms are not appropriate (e.g. a proprietary embedded system), licenses under more flexible terms can be readily obtained through Digium, Inc. at reasonable cost. Known Issues ------------ KB1 does not function when echocancel > 128 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ KB1 was not designed to function at greater than 128 taps, and if configured this way, will result in the destruction of audio. Ideally DAHDI would return an error when a KB1 echocanceller is configured with greater than 128 taps. Reporting Bugs -------------- Please report bug and patches to the Asterisk bug tracker at http://issues.asterisk.org in the "DAHDI-linux" category. Links ----- - http://asterisk.org/[] - The Asterisk PBX - http://docs.tzafrir.org.il/dahdi-linux/README.html[Up-to-date HTML version of this file]
Hello,
I currently have the following setup working perfectly:
However, when I try to upgrade to the following configuration:
The Digium Wildcard TE220 card does not work and gives the message:
wct4xxp 0000:04:08.0: Interrupts not detected.
I have tested using the same card on different servers with the same configurations:
ProLiant ML110 G7 (Work)
ProLiant ML110 G3 (Work)
I even tested this configuration:
Both the ProLiant ML110 G7 and ProLiant ML110 G3 work perfectly without any issues.
For some reason, the combination of (ML110 Gen9, Debian 11+, DAHDI 3.2.0+, TE220) does not work. I have the DAHDI configurations as follows:
/etc/dahdi/modules
wct4xxp
/etc/dahdi/system.conf
span=1,1,0,cas,hdb3
cas=1-15:1101
cas=17-31:1101
span=2,0,0,cas,hdb3
cas=32-46:1101
cas=48-62:1101
echocanceller=mg2,1-62
loadzone = br
defaultzone = br
kernel:
5.10.0-30-amd64
.
dahdi_cfg -vvvvvvvvv
DAHDI Tools Version - 3.2.0
DAHDI Version: 3.2.0
Echo Canceller(s): HWEC
Configuration
======================
SPAN 1: CAS/HDB3 Build-out: 0 db (CSU)/0-133 feet (DSX-1)
SPAN 2: CAS/HDB3 Build-out: 0 db (CSU)/0-133 feet (DSX-1)
Channel map:
Channel 01: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 01)
Channel 02: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 02)
Channel 03: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 03)
Channel 04: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 04)
Channel 05: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 05)
Channel 06: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 06)
Channel 07: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 07)
Channel 08: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 08)
Channel 09: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 09)
Channel 10: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 10)
Channel 11: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 11)
Channel 12: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 12)
Channel 13: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 13)
Channel 14: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 14)
Channel 15: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 15)
Channel 17: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 17)
Channel 18: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 18)
Channel 19: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 19)
Channel 20: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 20)
Channel 21: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 21)
Channel 22: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 22)
Channel 23: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 23)
Channel 24: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 24)
Channel 25: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 25)
Channel 26: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 26)
Channel 27: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 27)
Channel 28: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 28)
Channel 29: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 29)
Channel 30: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 30)
Channel 31: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 31)
Channel 32: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 32)
Channel 33: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 33)
Channel 34: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 34)
Channel 35: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 35)
Channel 36: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 36)
Channel 37: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 37)
Channel 38: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 38)
Channel 39: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 39)
Channel 40: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 40)
Channel 41: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 41)
Channel 42: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 42)
Channel 43: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 43)
Channel 44: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 44)
Channel 45: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 45)
Channel 46: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 46)
Channel 48: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 48)
Channel 49: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 49)
Channel 50: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 50)
Channel 51: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 51)
Channel 52: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 52)
Channel 53: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 53)
Channel 54: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 54)
Channel 55: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 55)
Channel 56: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 56)
Channel 57: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 57)
Channel 58: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 58)
Channel 59: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 59)
Channel 60: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 60)
Channel 61: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 61)
Channel 62: CAS / User (Default) (Echo Canceler: mg2) (Slaves: 62)
60 channels to configure.
Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2
Setting echocan for channel 3 to mg2
Setting echocan for channel 4 to mg2
Setting echocan for channel 5 to mg2
Setting echocan for channel 6 to mg2
Setting echocan for channel 7 to mg2
Setting echocan for channel 8 to mg2
Setting echocan for channel 9 to mg2
Setting echocan for channel 10 to mg2
Setting echocan for channel 11 to mg2
Setting echocan for channel 12 to mg2
Setting echocan for channel 13 to mg2
Setting echocan for channel 14 to mg2
Setting echocan for channel 15 to mg2
Setting echocan for channel 17 to mg2
Setting echocan for channel 18 to mg2
Setting echocan for channel 19 to mg2
Setting echocan for channel 20 to mg2
Setting echocan for channel 21 to mg2
Setting echocan for channel 22 to mg2
Setting echocan for channel 23 to mg2
Setting echocan for channel 24 to mg2
Setting echocan for channel 25 to mg2
Setting echocan for channel 26 to mg2
Setting echocan for channel 27 to mg2
Setting echocan for channel 28 to mg2
Setting echocan for channel 29 to mg2
Setting echocan for channel 30 to mg2
Setting echocan for channel 31 to mg2
Setting echocan for channel 32 to mg2
Setting echocan for channel 33 to mg2
Setting echocan for channel 34 to mg2
Setting echocan for channel 35 to mg2
Setting echocan for channel 36 to mg2
Setting echocan for channel 37 to mg2
Setting echocan for channel 38 to mg2
Setting echocan for channel 39 to mg2
Setting echocan for channel 40 to mg2
Setting echocan for channel 41 to mg2
Setting echocan for channel 42 to mg2
Setting echocan for channel 43 to mg2
Setting echocan for channel 44 to mg2
Setting echocan for channel 45 to mg2
Setting echocan for channel 46 to mg2
Setting echocan for channel 48 to mg2
Setting echocan for channel 49 to mg2
Setting echocan for channel 50 to mg2
Setting echocan for channel 51 to mg2
Setting echocan for channel 52 to mg2
Setting echocan for channel 53 to mg2
Setting echocan for channel 54 to mg2
Setting echocan for channel 55 to mg2
Setting echocan for channel 56 to mg2
Setting echocan for channel 57 to mg2
Setting echocan for channel 58 to mg2
Setting echocan for channel 59 to mg2
Setting echocan for channel 60 to mg2
Setting echocan for channel 61 to mg2
Setting echocan for channel 62 to mg2
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 8 0 0 0 IO-APIC 2-edge timer
1: 5 0 0 0 IO-APIC 1-edge i8042
8: 0 0 0 0 IO-APIC 8-edge rtc0
9: 0 1 0 0 IO-APIC 9-fasteoi acpi
12: 0 0 0 6 IO-APIC 12-edge i8042
16: 0 0 0 0 IO-APIC 16-fasteoi wct2xxp
18: 0 0 62 0 IO-APIC 18-fasteoi i801_smbus, ehci_hcd:usb1, ehci_hcd:usb3
19: 0 50 0 0 IO-APIC 19-fasteoi xhci-hcd:usb4, hpilo
25: 0 0 0 0 PCI-MSI 16384-edge PCIe PME
26: 0 0 0 0 PCI-MSI 18432-edge PCIe PME
28: 0 0 0 0 PCI-MSI 32768-edge PCIe PME
29: 0 0 0 0 PCI-MSI 34816-edge PCIe PME
30: 0 0 0 0 PCI-MSI 36864-edge PCIe PME
31: 0 0 0 0 PCI-MSI 38912-edge PCIe PME
33: 0 0 0 0 PCI-MSI 49152-edge PCIe PME
34: 0 0 0 0 PCI-MSI 51200-edge PCIe PME
35: 0 0 0 0 PCI-MSI 53248-edge PCIe PME
36: 0 0 0 0 PCI-MSI 55296-edge PCIe PME
37: 0 0 0 0 PCI-MSI 458752-edge PCIe PME
38: 0 0 0 0 PCI-MSI 462848-edge PCIe PME
39: 0 0 0 0 PCI-MSI 466944-edge PCIe PME
40: 0 0 0 0 PCI-MSI 532480-edge uhci_hcd:usb2
41: 6490 0 0 0 PCI-MSI 512000-edge ahci[0000:00:1f.2]
43: 0 0 2 0 PCI-MSI 65536-edge ioat-msix
45: 0 0 0 2 PCI-MSI 67584-edge ioat-msix
46: 2 0 0 0 PCI-MSI 69632-edge ioat-msix
47: 0 2 0 0 PCI-MSI 71680-edge ioat-msix
48: 0 0 2 0 PCI-MSI 73728-edge ioat-msix
49: 0 0 0 2 PCI-MSI 75776-edge ioat-msix
50: 2 0 0 0 PCI-MSI 77824-edge ioat-msix
51: 0 2 0 0 PCI-MSI 79872-edge ioat-msix
52: 0 0 235 0 PCI-MSI 1048576-edge eno1-tx-0
53: 0 0 0 2026 PCI-MSI 1048577-edge eno1-rx-1
54: 1 0 0 0 PCI-MSI 1048578-edge eno1-rx-2
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 50166 24851 35865 120181 Local timer interrupts
SPU: 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 Performance monitoring interrupts
IWI: 0 0 0 0 IRQ work interrupts
RTR: 1 0 0 0 APIC ICR read retries
RES: 194 170 91 94 Rescheduling interrupts
CAL: 1716 3120 2970 3338 Function call interrupts
TLB: 2 16 2 1 TLB shootdowns
TRM: 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 Threshold APIC interrupts
DFR: 0 0 0 0 Deferred Error APIC interrupts
MCE: 0 0 0 0 Machine check exceptions
MCP: 2 3 3 3 Machine check polls
ERR: 0
MIS: 0
PIN: 0 0 0 0 Posted-interrupt notification event
NPI: 0 0 0 0 Nested posted-interrupt event
PIW: 0 0 0 0 Posted-interrupt wakeup event
dmesg
[ 10.593113] dahdi: loading out-of-tree module taints kernel.
[ 10.593329] dahdi: module verification failed: signature and/or required key missing - tainting kernel
[ 10.596520] dahdi: Version: 3.4.0
[ 10.596732] dahdi: Telephony Interface Registered on major 196
[ 10.734042] wct4xxp 0000:04:08.0: Firmware Version: c01a016c
[ 10.736638] wct4xxp 0000:04:08.0: FALC Framer Version: 2.1 or earlier
[ 10.736754] wct4xxp 0000:04:08.0: Found a Wildcard: Wildcard TE220 (4th Gen)
[ 10.798833] wct4xxp 0000:04:08.0: firmware: direct-loading firmware dahdi-fw-oct6114-064.bin
[ 10.798844] VPM450: echo cancellation for 64 channels
[ 13.572753] tg3 0000:02:00.0 eno1: Link is up at 1000 Mbps, full duplex
[ 13.572760] tg3 0000:02:00.0 eno1: Flow control is off for TX and off for RX
[ 13.572763] tg3 0000:02:00.0 eno1: EEE is disabled
[ 13.572782] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[ 15.471722] wct4xxp 0000:04:08.0: VPM450: hardware DTMF disabled.
[ 15.471725] wct4xxp 0000:04:08.0: VPM450: Present and operational servicing 2 span(s)
[ 16.008063] wct4xxp 0000:04:08.0: TE2XXP: Span 1 configured for CAS/HDB3
[ 16.008187] wct4xxp 0000:04:08.0: SPAN 1: Primary Sync Source
[ 18.085304] wct4xxp 0000:04:08.0: Interrupts not detected.
[ 18.085543] wct4xxp 0000:04:08.0: TE2XXP: Span 2 configured for CAS/HDB3
[ 18.085588] wct4xxp 0000:04:08.0: Setting yellow alarm span 2
[ 20.165306] wct4xxp 0000:04:08.0: Interrupts not detected.
Considering that the card works on the same machine with an older version, it should work with a newer version.
Can anyone help me?
Thank you!
When using either the DAHDI linux complete 3.2.0 tar.gz file or the master branch sources, trying to compile on Rocky Linux 9.2 fails with error messages like these (not necessarily all of them at the same attempt):
linux/drivers/dahdi/xpp/xbus-core.c:1842:50: error: implicit declaration of function ‘PDE_DATA’; did you mean ‘NODE_DATA’? [-Werror=implicit-function-declaration]
1842 | return single_open(file, xbus_proc_show, PDE_DATA(inode));
^~~~~~~~
| NODE_DATA
Or
linux/drivers/dahdi/xpp/xbus-core.c:1842:50: warning: passing argument 3 of ‘single_open’ makes pointer from integer without a cast [-Wint-conversion]
1842 | return single_open(file, xbus_proc_show, PDE_DATA(inode));
| ^~~~~~~~~~~~~~~
| |
| int
Or
linux/drivers/dahdi/xpp/xbus-core.c:1949:28: warning: assignment to ‘void *’ from ‘ int’ makes pointer from integer without a cast [-Wint-conversion]
1949 | file->private_data = PDE_DATA(inode);
When using the DAHDI linux complete 3.2.0 tar.gz file, trying to compile on Rocky Linux 9.2 fails with error messages like these:
make all
make -C linux all
make[1]: Entering directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux'
make -C drivers/dahdi/firmware firmware-loaders
make[2]: Entering directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/firmware'
make[2]: Leaving directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/firmware'
make -C /lib/modules/5.14.0-284.25.1.el9_2.x86_64/build M=/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[2]: Entering directory '/usr/src/kernels/5.14.0-284.25.1.el9_2.x86_64'
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.o
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.c:49:10: fatal error: stdbool.h: No such file or directory
49 | #include <stdbool.h>
| ^~~~~~~~~~~
compilation terminated.
make[4]: *** [scripts/Makefile.build:321: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.o] Error 1
make[3]: *** [scripts/Makefile.build:607: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp] Error 2
make[2]: *** [Makefile:1923: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi] Error 2
make[2]: Leaving directory '/usr/src/kernels/5.14.0-284.25.1.el9_2.x86_64'
make[1]: *** [Makefile:74: modules] Error 2
make[1]: Leaving directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux'
make: *** [Makefile:9: all] Error 2
'make all' failed with 512.
The running Linux kernel version looks like this:
Linux localhost.localdomain 5.14.0-284.25.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 2 14:53:30 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Hi everyone,
I'm encountering an error while attempting to install Dahdi 3.3.0 on both RHEL 8 and Rocky Linux, using both manual installation and the provided installation script from https://github.com/InterLinked1/phreakscript.Any guidance or assistance to resolve this issue would be greatly appreciated.
CC [M] /usr/src/dahdi-linux-3.3.0/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_conf_bridge.o
/usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctc4xxp/base.c: In function 'wctc4xxp_net_register':
/usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctc4xxp/base.c:661:54: error: macro "netif_napi_add" passed 4 arguments, but takes just 3
netif_napi_add(netdev, &wc->napi, &wctc4xxp_poll, 64);
^
/usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctc4xxp/base.c:661:2: error: 'netif_napi_add' undeclared (first use in this function); did you mean 'netif_napi_del'?
netif_napi_add(netdev, &wc->napi, &wctc4xxp_poll, 64);
^~~~~~~~~~~~~~
netif_napi_del
/usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctc4xxp/base.c:661:2: note: each undeclared identifier is reported only once for each function it appears in
LD [M] /usr/src/dahdi-linux-3.3.0/drivers/dahdi/wct4xxp/wct4xxp.o
At top level:
/usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctc4xxp/base.c:552:1: warning: 'wctc4xxp_poll' defined but not used [-Wunused-function]
wctc4xxp_poll(struct napi_struct *napi, int budget)
^~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:318: /usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctc4xxp/base.o] Error 1
make[2]: *** [scripts/Makefile.build:558: /usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctc4xxp] Error 2
make[2]: *** Waiting for unfinished jobs....
CC [M] /usr/src/dahdi-linux-3.3.0/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_debug.o
CC [M] /usr/src/dahdi-linux-3.3.0/drivers/dahdi/wctdm24xxp/base.
Im testing on
Red Hat Enterprise Linux 8.9
4.18.0-513.18.1.el8_9.x86_64
CC [M] /usr/src/phones/dahdi-linux/drivers/dahdi/xpp/xbus-sysfs.o
/usr/src/phones/dahdi-linux/drivers/dahdi/xpp/xbus-sysfs.c:467:19: error: initialization of Ç int (*)(const struct device *, struct kobj_uevent_env *) Ç from incompatible pointer type Ç int (*)(struct device *, struct kobj_uevent_env *)
Ç [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wincompatible-pointer-types-Werror=incompatible-pointer-types8;;]
467 | .uevent = astribank_uevent,
| ^~~~~~~~~~~~~~~~
http://downloads.asterisk.org/pub/telephony/dahdi-linux/releases/
dahdi-linux-3.4.0.md5 18-Jun-2024 03:01 59
dahdi-linux-3.4.0.sha1 18-Jun-2024 03:01 67
dahdi-linux-3.4.0.sha256 18-Jun-2024 03:01 91
dahdi-linux-3.4.0.tar.gz 01-Jul-2024 13:27 1751872
dahdi-linux-3.4.0.tar.gz.asc 18-Jun-2024 03:01 833
The tarball has a new timestamp. My yocto build indicates the contents of the tarball have changed, in that the checksum has a different value than it used to have.
~$ sha256sum -c dahdi-linux-3.4.0.sha256
dahdi-linux-3.4.0.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
It seems like something bad is going on here.
Linux 5.17 commits adeef3e32146 ("net: constify netdev->dev_addr") and d07b26f5bbea ("dev_addr: add a modification check") make netdev->dev_addr
const, and add a runtime check that it is not being modified by casting off the const
.
There are a number of examples of this through the dahdi tree:
dahdi-linux/drivers/dahdi/datamods/hdlc_raw_eth.c
Lines 101 to 102 in 1476d3a
dahdi-linux/drivers/dahdi/datamods/hdlc_fr.c
Lines 1092 to 1095 in 1476d3a
Example build failure from OpenWrt with kernel 6.1:
from dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:24:
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c: In function 'wctc4xxp_net_register':
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:22: error: passing argument 1 of '__builtin_memcpy' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ~~~~~~^~~~~~~~~~
./include/linux/fortify-string.h:469:27: note: in definition of macro '__fortify_memcpy_chk'
469 | __underlying_##op(p, q, __fortify_size); \
| ^
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:9: note: in expansion of macro 'memcpy'
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ^~~~~~
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:22: note: expected 'void *' but argument is of type 'const unsigned char *'
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ~~~~~~^~~~~~~~~~
./include/linux/fortify-string.h:469:27: note: in definition of macro '__fortify_memcpy_chk'
469 | __underlying_##op(p, q, __fortify_size); \
| ^
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:9: note: in expansion of macro 'memcpy'
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ^~~~~~
From d51c10d, the const
is cast off, so would expect to hit the runtime check here:
dahdi-linux/drivers/dahdi/wctc4xxp/base.c
Line 646 in 1476d3a
I am not a dahdi user, only saw that the kernel module was failing to build for OpenWrt kernel 6.1, and wanted to fix that. This was the patch I came up with to address dev_addr
writes in dahdi for OpenWrt, but I have not checked that functionality has not changed. I do not currently have the time to rebase, build test, and PR. Feel free to use these suggestions as you see fit. Not completely confident with the drivers/dahdi/datamods/hdlc_fr.c
changes.
Thank you for working with this git repo once again!
From 3619bf1cc9c0cc67213cbda0db3534f8a64f5cc8 Mon Sep 17 00:00:00 2001
From: John Thomson <[email protected]>
Date: Wed, 14 Jun 2023 20:31:42 +1000
Subject: [PATCH 1/1] fix for const dev_addr for linux 5.17
Linux commit adeef3e32146 ("net: constify netdev->dev_addr")
dev_addr_set and _mod were introduced in linux 5.15 with
commit 48eab831ae8b ("net: create netdev->dev_addr assignment helpers")
from dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:24:
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c: In function 'wctc4xxp_net_register':
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:22: error: passing argument 1 of '__builtin_memcpy' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ~~~~~~^~~~~~~~~~
./include/linux/fortify-string.h:469:27: note: in definition of macro '__fortify_memcpy_chk'
469 | __underlying_##op(p, q, __fortify_size); \
| ^
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:9: note: in expansion of macro 'memcpy'
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ^~~~~~
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:22: note: expected 'void *' but argument is of type 'const unsigned char *'
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ~~~~~~^~~~~~~~~~
./include/linux/fortify-string.h:469:27: note: in definition of macro '__fortify_memcpy_chk'
469 | __underlying_##op(p, q, __fortify_size); \
| ^
dahdi-linux-3.2.0/drivers/dahdi/wctc4xxp/base.c:646:9: note: in expansion of macro 'memcpy'
646 | memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
| ^~~~~~
---
drivers/dahdi/datamods/hdlc_fr.c | 6 +++---
drivers/dahdi/datamods/hdlc_raw_eth.c | 4 ++--
drivers/dahdi/voicebus/voicebus_net.c | 2 +-
drivers/dahdi/wctc4xxp/base.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/dahdi/datamods/hdlc_fr.c
+++ b/drivers/dahdi/datamods/hdlc_fr.c
@@ -1089,10 +1089,10 @@ static int fr_add_pvc(struct net_device
}
if (type == ARPHRD_ETHER) {
- memcpy(dev->dev_addr, "\x00\x01", 2);
- get_random_bytes(dev->dev_addr + 2, ETH_ALEN - 2);
+ eth_hw_addr_random(dev);
+ dev_addr_mod(dev, 0, "\x00\x01", 2);
} else {
- *(u16*)dev->dev_addr = htons(dlci);
+ dev_addr_set(dev, htons(dlci));
dlci_to_q922(dev->broadcast, dlci);
}
dev->hard_start_xmit = pvc_xmit;
--- a/drivers/dahdi/datamods/hdlc_raw_eth.c
+++ b/drivers/dahdi/datamods/hdlc_raw_eth.c
@@ -98,8 +98,8 @@ int hdlc_raw_eth_ioctl(struct net_device
ether_setup(dev);
dev->change_mtu = old_ch_mtu;
dev->tx_queue_len = old_qlen;
- memcpy(dev->dev_addr, "\x00\x01", 2);
- get_random_bytes(dev->dev_addr + 2, ETH_ALEN - 2);
+ eth_hw_addr_random(dev);
+ dev_addr_mod(dev, 0, "\x00\x01", 2);
return 0;
}
--- a/drivers/dahdi/voicebus/voicebus_net.c
+++ b/drivers/dahdi/voicebus/voicebus_net.c
@@ -189,7 +189,7 @@ int vb_net_register(struct voicebus *vb,
return -ENOMEM;
priv = netdev_priv(netdev);
priv->vb = vb;
- memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
+ dev_addr_set(netdev, our_mac);
# ifdef HAVE_NET_DEVICE_OPS
netdev->netdev_ops = &vb_netdev_ops;
# else
--- a/drivers/dahdi/wctc4xxp/base.c
+++ b/drivers/dahdi/wctc4xxp/base.c
@@ -643,7 +643,7 @@ wctc4xxp_net_register(struct wcdte *wc)
return -ENOMEM;
priv = netdev_priv(netdev);
priv->wc = wc;
- memcpy(netdev->dev_addr, our_mac, sizeof(our_mac));
+ dev_addr_set(netdev, our_mac);
# ifdef HAVE_NET_DEVICE_OPS
netdev->netdev_ops = &wctc4xxp_netdev_ops;
OS: Debian 10 (Buster)
Kernel: 5.10.0-0.deb10.29-amd64
dahdi-linux release: 3.4.0
Issue:
I downloaded a fresh copy of of dahdi-linux-3.4.0.tar.gz. I extracted it, and cd into the directory. I then ran make
and it failed with the following error
/root/dahdi-linux-3.4.0/drivers/dahdi/xpp/xbus-sysfs.c:424:43: error: missing binary operator before token "("
RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,4)
DAHDI Tools Version - 3.4.0
Notice: Configuration file is /etc/dahdi/system.conf
line 0: Unable to open master device '/dev/dahdi/ctl'
1 error(s) detected
Asterisk 18.18.1
[root@47FAFE8 ~]# cd /usr/src/dahdi-linux-complete-3.4.0+3.4.0
[root@47FAFE8 dahdi-linux-complete-3.4.0+3.4.0]# uname -r
5.14.0-362.8.1.el9_3.x86_64
[root@47FAFE8 dahdi-linux-complete-3.4.0+3.4.0]# make
make -C linux all
make[1]: Entering directory '/usr/src/dahdi-linux-complete-3.4.0+3.4.0/linux'
make -C drivers/dahdi/firmware firmware-loaders
make[2]: Entering directory '/usr/src/dahdi-linux-complete-3.4.0+3.4.0/linux/drivers/dahdi/firmware'
make[2]: Leaving directory '/usr/src/dahdi-linux-complete-3.4.0+3.4.0/linux/drivers/dahdi/firmware'
You do not appear to have the sources for the 5.14.0-362.8.1.el9_3.x86_64 kernel installed.
make[1]: *** [Makefile:72: modules] Error 1
make[1]: Leaving directory '/usr/src/dahdi-linux-complete-3.4.0+3.4.0/linux'
make: *** [Makefile:9: all] Error 2
as you can see it has the kernel installed that its telling me is not installed, any suggestions?
Hi,
Is there a support for the tdm410?
Dec 20 17:22:31 ns sh[25951]: DAHDI_CHANCONFIG failed on channel 1: Invalid argument (22) Dec 20 17:22:31 ns sh[25951]: Selected signaling not supported Dec 20 17:22:31 ns sh[25951]: Possible causes: Dec 20 17:22:31 ns sh[25951]: #011FXS signaling is being used on a FXS interface (use a FXO signaling variant) Dec 20 17:22:31 ns sh[25951]: #011RBS signaling is being used on a E1 CCS span Dec 20 17:22:31 ns sh[25951]: #011Signaling is being assigned to channel 16 of an E1 CAS span Dec 20 17:22:31 ns systemd[1]: dahdi.service: Main process exited, code=exited, status=1/FAILURE Dec 20 17:22:31 ns systemd[1]: dahdi.service: Failed with result 'exit-code'. Dec 20 17:22:31 ns kernel: dahdi_ioctl_chanconfig: No channel for number 1 Dec 20 17:22:31 ns systemd[1]: Failed to start dahdi.service - The DAHDI drivers allow you to use your linux computer to accept incoming data and voice interfaces.
Thanks for your help.
Even the latest releases is unusable on any reasonable up to date kernel. We need a new release as a matter of urgency.
OS: CentOS
Kernel: 4.18.0-490
Version: 3.2.0
Issue:
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wctc4xxp/base.c: In function ‘wctc4xxp_net_register’:
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wctc4xxp/base.c:697:54: error: macro "netif_napi_add" passed 4 arguments, but takes just 3
netif_napi_add(netdev, &wc->napi, &wctc4xxp_poll, 64);
^
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wctc4xxp/base.c:697:2: error: ‘netif_napi_add’ undeclared (first use in this function); did you mean ‘netif_napi_del’?
netif_napi_add(netdev, &wc->napi, &wctc4xxp_poll, 64);
^~~~~~~~~~~~~~
netif_napi_del
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wctc4xxp/base.c:697:2: note: each undeclared identifier is reported only once for each function it appears in
At top level:
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wctc4xxp/base.c:583:1: warning: ‘wctc4xxp_poll’ defined but not used [-Wunused-function]
wctc4xxp_poll(struct napi_struct *napi, int budget)
^~~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:318: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wctc4xxp/base.o] Error 1
make[3]: *** [scripts/Makefile.build:558: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wctc4xxp] Error 2
make[2]: *** [Makefile:1616: module/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi] Error 2
make[2]: Leaving directory '/usr/src/kernels/4.18.0-490.el8.x86_64'
make[1]: *** [Makefile:74: modules] Error 2
make[1]: Leaving directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux'
make: *** [Makefile:9: all] Error 2
Installed, but cannot load dahdi module.
dahdi v3.3
[root@localhost ~]# modprobe dahdi
modprobe: ERROR: could not insert 'dahdi': Exec format error
dahdi: loading out-of-tree module taints kernel.
dahdi: module verification failed: signature and/or required key missing - tainting kernel
module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 000000002e026045, val ffffffffc0aecc40
module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 000000002e026045, val ffffffffc0aecc40
module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 000000002e026045, val ffffffffc0aecc40
BTW, was able to compile and install after making some changes in source.
Keep getting the following error:
root/dahdi-linux/drivers/dahdi/wct4xxp/base.c: In function ‘t4_allocate_buffers’:
/root/dahdi-linux/drivers/dahdi/wct4xxp/base.c:3864:17: error: implicit declaration of function ‘pci_alloc_consistent’ [-Werror=implicit-function-declaration]
3864 | alloc = pci_alloc_consistent(wc->dev, numbufs * T4_BASE_SIZE(wc) * 2,
| ^~~~~~~~~~~~~~~~~~~~
/root/dahdi-linux/drivers/dahdi/wct4xxp/base.c:3864:15: warning: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
3864 | alloc = pci_alloc_consistent(wc->dev, numbufs * T4_BASE_SIZE(wc) * 2,
| ^
/root/dahdi-linux/drivers/dahdi/wct4xxp/base.c: In function ‘t4_increase_latency’:
/root/dahdi-linux/drivers/dahdi/wct4xxp/base.c:3943:9: error: implicit declaration of function ‘pci_free_consistent’ [-Werror=implicit-function-declaration]
3943 | pci_free_consistent(wc->dev, T4_BASE_SIZE(wc) * oldbufs * 2,
Please advise.
Components/Modules:
Dahdi
Operating Environment
Os - rocky linux 9.2
Kernel version - kernel-5.14.0-284.25.1.el9_2.x86_64
Dahdi version - 3.2.0
Issue Description
Whenever we try to install dahdi in rocky linux 9.2 we are getting certain compilation errors .
Errors:
stdbool.h is not available in Rocky Linux 9.2 with Kernel 5.14.
Compilation failures are related to the netif_napi_add function.
Compilation failures are related to the function 'PDE_DATA'.
Installation steps:
cd /usr/src/
tar zxvf dahdi-linux-complete-3.2.0+3.2.0.tar.gz
cd dahdi-linux-complete-3.2.0+3.2.0
make && make install && make install-config
Relevant log output
Logs:
linux/drivers/dahdi/wctc4xxp/base.c: In function ‘wctc4xxp_net_register’:
linux/drivers/dahdi/wctc4xxp/base.c:665:9: error: too many arguments to function ‘netif_napi_add’
665 | netif_napi_add(netdev, &wc->napi, &wctc4xxp_poll, 64);
| ^~~~~~~~~~~~~~
In file included from ./include/net/inet_sock.h:19,
from ./include/linux/udp.h:16,
from /linux/drivers/dahdi/wctc4xxp/base.c:38:
./include/linux/netdevice.h:2519:1: note: declared here
2519 | netif_napi_add(struct net_device *dev, struct napi_struct *napi,
| ^~~~~~~~~~~~~~
linux/drivers/dahdi/xpp/xbus-core.c:1842:50: error: implicit declaration of function ‘PDE_DATA’; did you mean ‘NODE_DATA’? [-Werror=implicit-function-declaration]
1842 | return single_open(file, xbus_proc_show, PDE_DATA(inode));
^~~~~~~~
| NODE_DATA
make all
make -C linux all
make[1]: Entering directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux'
make -C drivers/dahdi/firmware firmware-loaders
make[2]: Entering directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/firmware'
make[2]: Leaving directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/firmware'
make -C /lib/modules/5.14.0-284.25.1.el9_2.x86_64/build M=/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[2]: Entering directory '/usr/src/kernels/5.14.0-284.25.1.el9_2.x86_64'
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.o
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.c:49:10: fatal error: stdbool.h: No such file or directory
49 | #include <stdbool.h>
| ^~~~~~~~~~~
compilation terminated.
make[4]: *** [scripts/Makefile.build:321: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.o] Error 1
make[3]: *** [scripts/Makefile.build:607: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp] Error 2
make[2]: *** [Makefile:1923: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi] Error 2
make[2]: Leaving directory '/usr/src/kernels/5.14.0-284.25.1.el9_2.x86_64'
make[1]: *** [Makefile:74: modules] Error 2
make[1]: Leaving directory '/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux'
make: *** [Makefile:9: all] Error 2
'make all' failed with 512.
When using either the DAHDI linux complete 3.2.0 tar.gz file or the master branch sources, trying to compile on Rocky Linux 8.9 or 9.2 fails with error messages like these:
linux/drivers/dahdi/wctc4xxp/base.c: In function ‘wctc4xxp_net_register’:
linux/drivers/dahdi/wctc4xxp/base.c:665:9: error: too many arguments to function ‘netif_napi_add’
665 | netif_napi_add(netdev, &wc->napi, &wctc4xxp_poll, 64);
| ^~~~~~~~~~~~~~
In file included from ./include/net/inet_sock.h:19,
from ./include/linux/udp.h:16,
from /linux/drivers/dahdi/wctc4xxp/base.c:38:
./include/linux/netdevice.h:2519:1: note: declared here
2519 | netif_napi_add(struct net_device *dev, struct napi_struct *napi,
| ^~~~~~~~~~~~~~
Hello,
I have tried unsuccessfully to pass parameters to the compiler and linker to see if this could be compiled standalone with gcc libs, as someone had suggested online. Any suggestions or assistance would be appreciated.
Thank you,
-Mike K.
here is the error I am getting
/usr/src/dahdi-linux/drivers/dahdi/xpp/xbus-sysfs.c:472:19: error: initialization of ‘int (*)(const struct device *, struct kobj_uevent_env )’ from incompatible pointer type ‘int ()(struct device *, struct kobj_uevent_env *)’ [-Werror=incompatible-pointer-types]
472 | .uevent = astribank_uevent,
| ^~~~~~~~~~~~~~~~
/usr/src/dahdi-linux/drivers/dahdi/xpp/xbus-sysfs.c:472:19: note: (near initialization for ‘toplevel_bus_type.uevent’)
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:299: /usr/src/dahdi-linux/drivers/dahdi/xpp/xbus-sysfs.o] Error 1
make[2]: *** [scripts/Makefile.build:585: /usr/src/dahdi-linux/drivers/dahdi/xpp] Error 2
make[1]: *** [Makefile:1934: /usr/src/dahdi-linux/drivers/dahdi] Error 2
Running Kali
6.0.0-kali5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.10-2kali1 (2022-12-06) x86_64 GNU/Linux (newest)
with asterisk
need to install dahdi but running into
`
make -C linux all
make[1]: Verzeichnis „/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux“ wird betreten
make -C drivers/dahdi/firmware firmware-loaders
make[2]: Verzeichnis „/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/firmware“ wird betreten
make[2]: Verzeichnis „/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/firmware“ wird verlassen
make -C /lib/modules/6.0.0-kali5-amd64/build M=/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[2]: Verzeichnis „/usr/src/linux-headers-6.0.0-kali5-amd64“ wird betreten
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_adpcm_chan.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_channel.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_chip_open.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_chip_stats.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_conf_bridge.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_debug.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_events.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_interrupts.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_memory.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_miscellaneous.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_mixer.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_phasing_tsst.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_playout_buf.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_remote_debug.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tlv.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tone_detection.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tsi_cnct.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_tsst.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/apilib/bt/octapi_bt0.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/apilib/largmath/octapi_largmath.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/apilib/llman/octapi_llman.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/oct612x-user.o
LD [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/oct612x/oct612x.o
CC [M] /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.o
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.c: In function ‘t4_allocate_buffers’:
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.c:3864:17: error: implicit declaration of function ‘pci_alloc_consistent’ [-Werror=implicit-function-declaration]
3864 | alloc = pci_alloc_consistent(wc->dev, numbufs * T4_BASE_SIZE(wc) * 2,
| ^~~~~~~~~~~~~~~~~~~~
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.c:3864:15: warning: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
3864 | alloc = pci_alloc_consistent(wc->dev, numbufs * T4_BASE_SIZE(wc) * 2,
| ^
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.c: In function ‘t4_increase_latency’:
/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.c:3943:9: error: implicit declaration of function ‘pci_free_consistent’ [-Werror=implicit-function-declaration]
3943 | pci_free_consistent(wc->dev, T4_BASE_SIZE(wc) * oldbufs * 2,
| ^~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[4]: *** [/usr/src/linux-headers-6.0.0-kali5-common/scripts/Makefile.build:254: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp/base.o] Fehler 1
make[3]: *** [/usr/src/linux-headers-6.0.0-kali5-common/scripts/Makefile.build:470: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi/wct4xxp] Fehler 2
make[2]: *** [/usr/src/linux-headers-6.0.0-kali5-common/Makefile:1876: /usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux/drivers/dahdi] Fehler 2
make[2]: Verzeichnis „/usr/src/linux-headers-6.0.0-kali5-amd64“ wird verlassen
make[1]: *** [Makefile:74: modules] Fehler 2
make[1]: Verzeichnis „/usr/src/dahdi-linux-complete-3.2.0+3.2.0/linux“ wird verlassen
make: *** [Makefile:9: all] Fehler 2
`
would be great to get some help here
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.