Unable to create channel of type 'DAHDI' (Cause 0 - Unknown)

Asterisk Asterisk Support
1

Hi,

I’ve recently upgraded asterisk to 13.1.1 on fedora22 from fedora20 and it’s now not working. I’ve downloaded and compiled dahdi-linux from git, and the kernel modules are installed, but apparently asterisk now doesn’t see them. It appears to detect my IP450 phone, but immediately goes busy when trying to dial out. Asterisk also doesn’t answer when called.

The only thing I can think to do is paste the logs and my relevant config files in hopes that someone can help get my phone system running again.

[Jul 17 16:36:41] Asterisk 13.1.1 built by mockbuild @ buildhw-06.phx2.fedoraproject.org on a x86_64 running Linux on 2015-01-30 20:30:35 UTC [Jul 17 16:36:41] NOTICE[22326] cdr.c: CDR simple logging enabled. [Jul 17 16:36:41] NOTICE[22326] loader.c: 221 modules will be loaded. [Jul 17 16:36:41] WARNING[22326] res_phoneprov.c: Unable to find a valid server address or name. [Jul 17 16:36:41] WARNING[22326] res_crypto.c: Unable to open key file /usr/share/asterisk/keys/voicepulse20060419.pub: Permission denied [Jul 17 16:36:41] WARNING[22326] res_crypto.c: Unable to open key file /usr/share/asterisk/keys/voicepulse01.pub: Permission denied [Jul 17 16:36:41] ERROR[22326] ari/config.c: No configured users for ARI [Jul 17 16:36:41] WARNING[22326] loader.c: Error loading module 'res_ari_mailboxes.so': /usr/lib64/asterisk/modules/res_ari_mailboxes.so: undefined symbol: stasis_app_mailbox_to_json [Jul 17 16:36:41] WARNING[22326] loader.c: Module 'res_ari_mailboxes.so' could not be loaded. [Jul 17 16:36:42] WARNING[22326] res_musiconhold.c: No music on hold classes configured, disabling music on hold. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Unable to specify channel 1: No such device or address [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to open channel 1: No such device or address here = 0, tmp->channel = 1, channel = 1 [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to register channel '1' [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Channel '1' failure ignored: ignore_failed_channels. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Unable to specify channel 2: No such device or address [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to open channel 2: No such device or address here = 0, tmp->channel = 2, channel = 2 [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to register channel '2' [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Channel '2' failure ignored: ignore_failed_channels. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Unable to specify channel 3: No such device or address [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to open channel 3: No such device or address here = 0, tmp->channel = 3, channel = 3 [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to register channel '3' [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Channel '3' failure ignored: ignore_failed_channels. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Unable to specify channel 4: No such device or address [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to open channel 4: No such device or address here = 0, tmp->channel = 4, channel = 4 [Jul 17 16:36:42] ERROR[22326] chan_dahdi.c: Unable to register channel '4' [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Channel '4' failure ignored: ignore_failed_channels. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Ignoring any changes to 'userbase' (on reload) at line 23. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Ignoring any changes to 'vmsecret' (on reload) at line 31. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Ignoring any changes to 'hassip' (on reload) at line 35. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Ignoring any changes to 'hasiax' (on reload) at line 39. [Jul 17 16:36:42] WARNING[22326] chan_dahdi.c: Ignoring any changes to 'hasmanager' (on reload) at line 47. [Jul 17 16:36:42] NOTICE[22358] chan_sip.c: Peer '7003' is now Reachable. (15ms / 2000ms) [Jul 17 16:36:42] NOTICE[22326] confbridge/conf_config_parser.c: Adding default_menu menu to app_confbridge [Jul 17 16:36:42] NOTICE[22326] cel_custom.c: No mappings found in cel_custom.conf. Not logging CEL to custom CSVs. [Jul 17 16:36:42] WARNING[22326] pbx.c: Unable to register extension '_X' priority 1 in 'mainmenu-night', already in use [Jul 17 16:36:42] WARNING[22326] pbx_config.c: Unable to register extension at line 220 of extensions.conf [Jul 17 16:36:42] WARNING[22326] pbx.c: Unable to register extension 's' priority 2 in 'incoming-sales', already in use [Jul 17 16:36:42] WARNING[22326] pbx_config.c: Unable to register extension at line 292 of extensions.conf [Jul 17 16:36:42] ERROR[22326] codec_dahdi.c: Failed to open /dev/dahdi/transcode: No such file or directory [Jul 17 16:36:42] WARNING[22326] app_voicemail.c: maxsilence should be less than minsecs or you may get empty messages [Jul 17 16:36:50] ERROR[22394][C-00000000] utils.c: write() returned error: Broken pipe [Jul 17 16:36:50] ERROR[22394][C-00000000] utils.c: write() returned error: Broken pipe [Jul 17 16:36:50] WARNING[22394][C-00000000] app_dial.c: Unable to create channel of type 'DAHDI' (cause 0 - Unknown)

# lsmod|egrep 'dahdi|wctdm' wctdm 49152 0 dahdi_echocan_mg2 16384 0 dahdi 229376 2 wctdm,dahdi_echocan_mg2 crc_ccitt 16384 1 dahdi

orion*CLI> module load chan_dahdi Unable to load module chan_dahdi Command 'module load chan_dahdi' failed. [Jul 17 17:08:10] WARNING[25776]: loader.c:1028 load_resource: Module 'chan_dahdi' already exists.

orion*CLI> dahdi show status Description Alarms IRQ bpviol CRC Fra Codi Options LBO Wildcard TDM400P REV I Board 5 UNCONFI 0 0 0 CAS Unk 0 db (CSU)/0-133 feet (DSX-1)

[root@orion asterisk]# egrep -v '^#|^$|\;' sip.conf [general] port = 5060 bindaddr = 192.168.1.1 context = incoming limitonpeers = yes deny = 0.0.0.0/0.0.0.0 permit = 64.1.16.0/255.255.255.224 disallow = all allow = ulaw [7003] type = friend accountcode = dave host = dynamic defaultuser = Dave secret = Dave-7003 mailbox = 7003@local dtmfmode = rfc2833 callerid = Dave <7003> context = trusted qualify = yes canreinvite = no call-limit = 5

[root@orion asterisk]# egrep -v '^#|^$|\;' chan_dahdi.conf [channels] language = en context = incoming accountcode = pstn-incoming signalling = fxs_ks callwaiting = no immediate = no amaflags = default cancallforward = no busydetect = no callprogress = no musiconhold = default threewaycalling = no callreturn = no transfer = no usedistinctiveringdetection = no usecallerid = yes hidecallerid = no callwaitingcallerid = no echocancel = yes echotraining = no group = 1 pickupgroup = 1 channel => 1 channel => 2 group = 2 context = incoming channel => 3 group = 3 context = incoming channel => 4

[root@orion dahdi]# egrep -v '^#|^$|\;' system.conf fxsks=1 echocanceller=mg2,1 fxsks=2 echocanceller=mg2,2 fxsks=3 echocanceller=mg2,3 fxsks=4 echocanceller=mg2,4 loadzone = us defaultzone = us

[root@orion asterisk]# rpm -qva|egrep 'asterisk|dahdi' dahdi-tools-devel-2.10.0-2.fc22.x86_64 dahdi-tools-2.10.0-2.fc22.x86_64 asterisk-sounds-core-en-1.4.26-1.fc22.noarch asterisk-voicemail-plain-13.1.1-1.fc22.x86_64 asterisk-dahdi-13.1.1-1.fc22.x86_64 asterisk-sounds-core-en-gsm-1.4.26-1.fc22.noarch dahdi-tools-libs-2.10.0-2.fc22.x86_64 asterisk-gui-2.0-10.20120518svn5220.fc21.noarch asterisk-13.1.1-1.fc22.x86_64 asterisk-voicemail-13.1.1-1.fc22.x86_64 asterisk-sip-13.1.1-1.fc22.x86_64

Thanks for any ideas. Please let me know what information I can provide to troubleshoot this.

2

I’m seeing the same thing (also having just upgraded from FC20 to FC22).

I have found a work-around - not sure WHY it’s not working on boot.

Try this:
systemctl stop asterisk.service
dahdi_cfg -vvvv
systemctl start asterisk.service

It almost looks like the the dahdi interfaces aren’t initializing (they switch from “Unused” to Kewlstart (FXS/FXO as appropriate when I run dahdi_cfg).

Like I said - this is a workaround, at best. Not sure why /etc/rc.d/init.d/dahdi isn’t running them. I need to check if it’s being executed on the right runlevels. But this will, hopefully, get your lines back up and running, for now.

3

[quote=“pwtotten”]I’m seeing the same thing (also having just upgraded from FC20 to FC22).

I have found a work-around - not sure WHY it’s not working on boot.

Try this:
systemctl stop asterisk.service
dahdi_cfg -vvvv
systemctl start asterisk.service

It almost looks like the the dahdi interfaces aren’t initializing (they switch from “Unused” to Kewlstart (FXS/FXO as appropriate when I run dahdi_cfg).

Like I said - this is a workaround, at best. Not sure why /etc/rc.d/init.d/dahdi isn’t running them. I need to check if it’s being executed on the right runlevels. But this will, hopefully, get your lines back up and running, for now.[/quote]

Thanks very much. Definitely something strange going on. I did get it running, but I don’t consider it fixed. I don’t believe I made any changes outside of just restarting the service and just waiting.

4

I think I have a solution.
In /etc/rc.d/init.d/dahdi, there is a call to /etc/rc.d/init.d/functions which exits if functions returns 1 - which it always does. Other routines in /etc/rc.d/init.d also call functions, but ignore the return code.

So, in /etc/rc.d/init.d/dahdi, if you comment out:
#if [ $system = redhat ]; then

. $initdir/functions || exit 0

#fi

And, in their place, add the one line (the ‘.’ is necessary)
. $initdir/functions

This has solved the problem on my system. The dahdi ports come up right away. Hope this helps you, as well.

5

“,” is inclusion, not calling. This will be a library of utility functions. I would never have considered doing it as anything except a line of its own, but I suspect the intent was to fail if the file was missing. The status will be set by the last command, but you would expect all the commands to succeed.

I’d suggest this is a Redhat bug.

6

[quote=“david55”]"," is inclusion, not calling. This will be a library of utility functions. I would never have considered doing it as anything except a line of its own, but I suspect the intent was to fail if the file was missing. The status will be set by the last command, but you would expect all the commands to succeed.

I’d suggest this is a Redhat bug.[/quote]

Yes, the problem seems to be the /etc/init.d/functions file returns 1 when /proc/cmdline doesn’t contain “rc.debug”. I updated an existing dahdi bug last week for this:

bugzilla.redhat.com/show_bug.cgi?id=1022767

This only prevented the dahdi and hardware drivers from loading properly. I was still having a problem beyond this, but it magically started working a few days later. Still not entirely sure what’s going on, and since it’s working for the moment, haven’t had time to investigate.