Installation steps for FreePBX 17 with DAHDI / Sangoma TE133 T1 Card

I recently moved from FreePBX 15 with a Rhino R1T1 card to FreePBX 17 with a Digium/Sangoma TE133 T1 card. As there were quite a few steps required that did not seem to be documented in the installation instructions, and as I will probably have to do this again soon, I wanted to document the issues I found.

Much of this has to do with DAHDI, which was needed for my T1 card. I had been using a Rhino R1T1 card with FreePBX 15, but that card does not seem to be supported under FreePBX 17, so I switched to the Digium/Sangoma TE133.

The first issue has to do with the Debian 12 kernel version. The DAHDI drivers only work with specific kernel versions.

After installing Debian 12, when you start the installation script with the –dahdi flag, you will get a message if the kernel version is not supported.

The steps then required are:

  1. install the correct kernel version,

  2. boot into that specific kernel version by selecting it when grub appears on the console during boot,

  3. Delete the other kernels so they don’t get selected by grub because they are more current, and

  4. Pin the kernel version so it does not get updated.

You can see which kernel you are running with:

uname -r

and you can install the version you want with something like:

sudo apt update
sudo apt install linux-image-6.1.0-37-amd64 linux-headers-6.1.0-37-amd64

You can prevent unwanted kernel upgrades with

sudo apt-mark hold linux-image-amd64 linux-headers-amd64
apt-mark showhold

Also, it may have been my hardware, but one of the installed modules had an illegal instruction, so I had to disable it just to get Asterisk to start:

sudo mv /lib/x86_64-linux-gnu/asterisk/modules/res_digium_phone.so /lib/x86_64-linux-gnu/asterisk/modules/res_digium_phone.so.disabled

(I used gdb, The Gnu Debugger, to find the offending module causing the crash)

Sometimes, I would get an error in the GUI that said the ionCube loader (which Sangoma uses to protect its php code) needed to be added, but that generally resolved if I

  1. ensured I had Internet access from the box, so it could check licensing, and

  2. restarted apache:

systemctl restart apache2

To configure DAHDI, you can first check that the card is recognized:
sudo dahdi_hardware

which should produce:
pci:0000:09:00.0 wcte13xp+ d161:800a Wildcard TE131/TE133

Generate the DAHDI configuration with:

dahdi_genconf

Check the generated dahdi config:

cat /etc/dahdi/system.conf

and

cat /etc/asterisk/dahdi-channels.conf

For some reason, /etc/dahdi/system.conf gets modified and the dahdi config gets removed by some automatic process. Typically, this occurs after a reboot or restart, and results in the DAHDI card simply not working, pri show spans returning no text, and on inspection, /etc/dahdi/system.conf is largely empty. To keep that from happening randomly, I have made the file immutable with:

sudo chattr +i /etc/dahdi/system.conf

If we ever need to change this file, we will need to remove the immutable attribute:

sudo chattr -i /etc/dahdi/system.conf

Also, /etc/asterisk/dahdi-channels.conf makes reference to the need that it be #include-d by /etc/chan_dahdi.conf, but there is no such file, and it did not appear that /etc/asterisk/dahdi-channels.conf was included anywhere.

I resolved that by editing /etc/asterisk/chan_dahdi_channels_custom.conf and adding this line:

#include dahdi-channels.conf 

Useful commands (many of these require sudo for them to be found by the shell):

sudo fwconsole restart
sudo fwconsole reload

Check that the card is recognized with:

sudo dahdi_hardware

which should produce:

pci:0000:09:00.0     wcte13xp+    d161:800a Wildcard TE131/TE133

Generate the DAHDI configuration with:

sudo dahdi_genconf

(Note that the UI for DAHDI configuration seems to be broken; attempting to save produces a SQL error that probably reflects the more strict Debian 12 version of MariaDB.)

Check the generated dahdi config:

cat /etc/dahdi/system.conf

which should include:

# Span 1: WCT13x/0 "Wildcard TE131/TE133 Card 0" (MASTER) 
span=1,1,0,esf,b8zs
# termtype: te
bchan=1-23
dchan=24
echocanceller=oslec,1-23

and:

cat /etc/asterisk/dahdi-channels.conf

which should include:

; Span 1: WCT13x/0 "Wildcard TE131/TE133 Card 0" (MASTER) 
group=0,11
context=from-pstn
switchtype = national
signalling = pri_cpe
channel => 1-23
context = default
group = 63

Apply the DAHDI settings and/or check that the channels are loaded:

sudo dahdi_cfg -vv

which should produce lines like
DAHDI Tools Version - 3.4.0.
DAHDI Version: 3.4.0
Echo Canceller(s): HWEC
Configuration
======================

SPAN 1: ESF/B8ZS Build-out: 0 db (CSU)/0-133 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 02: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 02)

. . .

Channel 24: D-channel (Default) (Echo Canceler: none) (Slaves: 24)

24 channels to configure.

Setting echocan for channel 1 to oslec
. . .

Check that the driver is loaded with:

lsmod | grep dahdi

which should produce:

dahdi_transcode        16384  1 wctc4xxp
dahdi_voicebus         77824  2 wcte12xp,wctdm24xxp
dahdi                 258048  87 wcte12xp,wctdm24xxp,wct4xxp,wct1xxp,dahdi_voicebus,dahdi_transcode,wcte11xp,wctdm,wcb4xxp,oct612x,xpp,wcaxx,wcfxo,wcte13xp,wcte43x

You can check that the T1 card is recognized at the Asterisk CLI (sudo asterisk -rvv) with:

pri show spans

which should produce:

PRI span 1/0: Up, Active

and

pri show span 1

which should produce:

Primary D-channel: 24
Status: Up, Active
Switchtype: National ISDN
Type: CPE
Remote type: Network
Overlap Dial: 0
Logical Channel Mapping: 0
Timer and counter settings:
  N200: 3
  N202: 3
  K: 7
  T200: 1000
  T201: 1000
  T202: 2000
  T203: 10000
  T303: 4000
  T305: 30000
  T308: 4000
  T309: 6000
  T312: 6000
  T313: 4000
  T316: -1
  N316: 2
  T-HOLD: 4000
  T-RETRIEVE: 4000
  T-RESPONSE: 4000
Q931 RX: 73
Q931 TX: 72
Q921 RX: 992
Q921 TX: 923
Q921 Outstanding: 0 (TEI=0)
Total active-calls:0 global:1
CC records:
Overlap Recv: No

You can restart dahdi:

sudo systemctl restart dahdi

When I tried to create the DAHDI configuration with the UI, at Connectivity → DAHDI Config, that produced this error:

SQLSTATE[HY000]: General error: 1364 Field 'mfcr2_mfback_timeout' doesn't have a default value::

That appears to be an error that prevents using the UI to generate the DAHDI configuration, hence the more manual method above.

I have written this down mostly for my future self, since I will need to do most of this soon to create a fallback system, and also when it is time to upgrade FreePBX again.

Hopefully it will also help others avoid some of these issues.

With luck, you won’t have to. Copper T1/E1 is being retired everywhere. Carrier will bring in SIP over fiber, with a CPE gateway to convert to copper T1. Just tell them to skip the gateway and connect directly to your PBX.

On a somewhat irregular installation, I found that I had to add “After=dahdi.service"to the freepbx startup script to ensure that dahdi was running before the fwconsole service starts. Be interested to know if other users have had similar experiences.

Both the FreePBX v17 shell installer and the ISO wrapper around the shell installer are geared towards matching kernel and hardware – so it automatically helps with a number of the initial installation steps outlined in OP, such as blocking incompatible kernel upgrades.

Noted, thanks!