Sangoma Card not detected

I wish I knew to run that before. I already did the hack job mentioned in the first post to get it working.

It should already be set to yes. Is that not the case?

Looking at the original issue the OP reported

This seems to be user misconfiguration. If the permissions on the file would have been fixed then the module would have worked after a reboot.

If I am wrong by all means let me know but I believe the module to be working correctly.

Just ran through this on our dev environment with @tonyclewis we did not have any problems. I believe the issue was with the permissions of that single file. All that had to be run was “fwconsole chown” which was mentioned in the dashboard (to fix permissions on said file)

I’m not convinced since I had a fresh installation. I don’t have a way to test it but I do very much appreciate the efforts.

My system has “Run Wanpipe In DAHDI/DIGIUM Mode” set to Yes. I believe that was default. I don’t recall changing it.

This is a me too post.

Sangoma A101DE card.
Same issues as the OP and others here. DAHDI config module 13.0.15

As suggested already, the following makes the card visible in FreePBX and dahdi_scan

Disable DAHDI config module
Running “/usr/sbin/wancfg_dahdi” at the cli.
Enable DAHDI config mdule

Card is now visible in FreePBX!

Also have a call in with the supplier of my appliance so will see what approach they suggest to take.\


I am a newbie so sorry for my question but I am having all the same issues with DAHDi not finding my Sangoma aft base 2005 card DAHDi version I have tried the all the above items but to no success. When I tried to give files permissions in the console I can’t find the missing files and I have not had any luck locating them on the web to install. Please help

Personally, I always set up DAHDI by hand to get it working. This means downloading all of the ‘-devel’ files and source code and installing the package from bare metal. After that, I find that the required files are all there and you should be good to go.

I’m sure it’s not the best way to do it, but it’s a strategy that worked for me when I was stuck at this same place a few years ago.

I have a really strange problem that has been ongoing for a few years now. I use solely HP MicroServers for our FreePBX machines with Sangoma BRI and PRI cards. It was all working fine until FreePBX 13. After that I started experiencing a weird disappearing act by Sangoma cards. Cards would be fine for a while, all configured and happily working, until there’s a power cut and the servers have an ungraceful shutdown. After the power is restored and servers automatically come back on, Sangoma cards would not show up in FreePBX or lspci! Like they are not even plugged in! How bizarre! In the beginning when this started happening, I would have to drive to the customer site, open up the server, take out the sangoma card, power on the server, power it off, put the sangoma card back in, and power it back on. But after some fiddling I realised that if I unplug the ISDN cable from the card and power on the server, the card shows up fine!! I just need to plug the ISDN cable back in when the server is already running and everything would work fine! This has become a huge pain and I started using older versions of FreePBX because they didn’t have this weird problem instead of the new versions. This is how I got around this… ideally it would be fixed so I can use newer versions of FreePBX with Sangoma BRI & PRI cards. Anyone with any ideas?

Sorry for reviving an old thread, I just had one of the servers do it to me again and got annoyed so started searching for a solution again :smiley:

The old thread problem notwithstanding, you need to submit a ticket on this ASAP. In fact, you should have submitted a ticket a long time ago on this.

DAHDI is a separate product from FreePBX and from Asterisk, but since Digium and Sangoma (DADHI software and the card’s hardware) are now the same company, you should be able to get some support on this.

Since it’s reproducible and can be avoided by older versions of the software, it should be reasonably straightforward to get in to. Since we’re all FreePBX users here, we (on the other hand) aren’t really going to be able to help you much, if at all.

1 Like

Thanks for the reply bro.

I tried creating a bug on but they closed it within minutes, saying it’s not a freepbx issue, and that I should contact the hardware supplier. -___-
I don’t understand - how is it not a freepbx issue if the same hardware works perfect on older versions of Freepbx but not on v13+?
Not sure where else to try to report this issue?

It’s not an issue when it’s not reproducible. This is not reproducible

But… it is reproducible… :confused:

I agree that it’s a weird problem and it might be isolated to this combination of hardware&software, but the PCIe card is made by Sangoma and the software is made by Sangoma… the only other variable is the HP Microserver, but as I said it all works flawlessly with FreePBX versions prior to v13+.
So I could have it all running on v14 and experience the problem described, then format the drive and install FreePBX v12 instead and the problem disappears. Same hardware, the only difference is different version of FreePBX installed…
I don’t understand why unplugging the ISDN cable before booting makes a difference and lets the PCIe card show up in lspci, but that’s what happens. If I leave the ISDN cable plugged in (as it should be) while the microserver is booting, the PCIe card won’t appear in lspci. This only happens after an unclean shutdown. If I power down the microserver gracefully and power it back on (having the ISDN cable plugged in), it will all work fine.
It would be great to test this with a different PC/server to see if it happens on other hardware too, but we don’t have an active ISDN line in the office so I wouldn’t be able to test it properly :grimacing: So far I could reproduce the problem on two different generations of HP Microservers (unfortunately deployed on customer sites).

At the wanpipe level, is the card been detected by wanpipe/wanrouter drivers?

Wanpipe doesn’t even start in this scenario for some bizarre reason. So if I leave the ISDN cable plugged in, wanpipe&dahdi don’t even run. However, if I uplug the ISDN cable and boot up, dahdi and wanpipe start fine and show the bri card. then I plug the cable back in and maybe reconfigure the channels a bit and that’s it! strange isn’t it?? is there some kind of a log that would show why wanpipe/dahdi don’t start or crash, or whatever is happening in the background?

Please open a support ticket about this under Telephony Cards department.

The right place to start is /var/log/messages

1 Like

I opened up a support ticket and they said to upgrade to FPBX 14 as it has a newer version of dahdi apparently. That will take some planning as the server is based on site and I will need to swap it out somehow.

But I did look at the logs and all I could see is that when the system was booting after the ungraceful shutdown, wanpipe would try to load itself but it doesn’t find any Sangoma cards so it doesn’t load. Whereas when the ISDN line is unplugged, wanpipe loads itself and actually finds the BRI PCIe card and everything carries on as normal. Not sure if there’s any other useful info that could be in there? Shall I attach the log?

I know this post is a little late to the party, but hopefully the information is found helpful by someone in the future. I was experiencing this issue with a new FreePBX 100 appliance using an A20002DE card. After scanning the forums I found the following solution to work.

From CLI run “sangoma_setup”, once you completed the analog card setup it will say configuration complete and give you two options 1>continue, 2>exit. You must choose continue from there and continue following the prompts until you’re returned to the root cli screen or the configuration does not actually complete.
After completely running the sangoma_setup process the card loaded as expected within dahdi configs in the GUI

I can add that this is reproducible and ongoing. It happened on at least the last four ver 14 systems I’ve setup. They all have this same issue. Each one was separate hardware with separate a101 cards. It’s no biggie(CLI config works) and I really think overall you’ve all done a great job. This is an initial “right out of the box” issue and trail by fire for newbies. Now that I think about it, it’s a good “do you really have this in you” test.

Running in to this issue myself in 16.0.9 with an a101 card straight off the bat.
Believe it may be a case of the dahdiconfig module not being able to create the required initial config files, but can edit them once they are present.
I fixed by touching the global.conf, and dahdi.conf files before saving settings in gui (the second time around, as didn’t create files the first time around), then it appeared as expected.
Assuming wancfg_dahdi would be a fix as that creates the files too.