Sangoma Card not detected

Using FreePBX Distro ver 10.13.66
Installed using Asterisk ver 13.7.1

With a fresh install on 2 separate machines, a sangoma A500 BRI ard PCI Express with echo cancellation and 1 x BRI module installed, fails to be automatically detected and doesn’t show in the DAHDI configuration module. Running “lspci” from command prompt does show the card listed. Running “wanrouter status” comes back as wanrouter not running.

System displays the following error in Dashboard:

Unable to write to /etc/wanpipe/global.conf
Please change permissions on /etc/wanpipe/global.conf or disable Sangoma DIGIUM mode

I have to run “/usr/sbin/wancfg_dahdi” from command prompt and run
throught the config and then once I reboot, the card appears as normal
under digital hardware tab. After this, everything else works as

All modules are fully up to date and DAHDI module is version 13.0.14

I did report this as a bug on Jira but it was immediately closed off as a support issue ie. user error.

When you run the standalone DAHDI tools (since DAHDI is technically not part of Asterisk or FreePBX), do you get a Red or Green status indicator on the output?

When happens when you start DAHDI manually and do you wait for it to complete initialization before you start Asterisk?

Hi Dave,

If I run setup-sangoma or dahdi config then the card is detected ok. So in that respect, its not a show stopper. It just seems like a bug to me. This wasnt happening in previous versions. I have always used sangoma cards and they were detected automatically, showing up in the Dahdi config module. It feels like a step back to when I used to have to install wanrouter drivers and do the setup via command line. I would be surprised if this has been done by design, as with Sangoma now running the FreePBX project, I would expect closer intergration and compatibility between Sangoma hardware and FreePBX.

1 Like

The prevailing wisdom (until FreePBX 14 comes out) is to disable the DAHDI modules in FreePBX and set the card up by hand.

Also, remember that DAHDI isn’t a Sangoma product - it’s over on the Digium/Asterisk side, so it wouldn’t actually surprise me at all if it suddenly stopped working in FreePBX.

Not saying that anyone would deliberately screw anyone else up, but PJ-SIP…

I see. I guess there is always going to be these kind of issues with multi vendor open products but I was hoping things would improve when Sangoma took over the FreePBX project. While I am impressed by the new GUI and other improvements, I can’t help feeling that the last few releases haven’t been as stable as the version 10 was. Considering DAHDI is an intergral part of using Sangoma hardware within FreePBX, I would think they would be very proactive in sorting out any issues.

PJ-SIP stays disabled on any of my production systems.

We can always hope…

On the other hand, the FreePBX team has committed to a new version of the DAHDI interface management modules for 14, so it’s just another temporary problem.

Honestly we do not have the resources to keep tab on every little thing that can go wrong in something as complex as FreePBX. Even only supporting Sangoma and Digium cards puts us at over 50+ cards. No one has time to check these daily. Anything can break it, from OS to Asterisk to Digium to, yes, FreePBX.

We sort out issues when we run into them. You are the first to report an A200 issue. Also looking at the issue was previously solved and confirmed working.

Remember “Only you can prevent forest fires” The same applies to FreePBX. If you are having an issue you have the ability to report a bug so we can get it fixed.

We can only do so much.

1 Like

Which is why lots of people hang around here even when they don’t have problems. It’s a community project, even with the commercial aspects included, so trying to help people get the most out of their installation is all we can do.

Kevin, for example, did it right. He read about his problem, got smart and asked a few good questions. His experience had told him to have a certain expectation, and it wasn’t met. The fact that the answer was “it would be cool if that worked, but experience tells us it doesn’t.” has gotten him moving forward again. He has submitted a ticket explaining what he needs and how he needs it so you guys don’t have to guess. He now also has the information he needs to get about with doing his actual job and maybe ponying up some code or some cash to help make his life, and the lives of others, better.

In the end, though, it is all self-help. We help the ones that can help themselves and have to let the rest go.

I’m also trying to get an A101 to show up in freepbx. It shows up in lspci. There must be something simple to fix this. Its a new install.

I guess I can do the old method… but rather do it right …whatever that may be.

1 Like

So below is what I got out of the box. I’ll run /usr/sbin/wancfg_dahdi and cross my fingers. To me it seems like two people confirming that it doesn’t work means there is an issue that warrants a bug valid.

[[email protected] sudoers.d]# wanrouter hwprobe

| Wanpipe Hardware Probe Info |
1 . AFT-A101-SH : SLOT=0 : BUS=3 : IRQ=11 : CPU=A : PORT=1 : HWEC=32 : V=36

Sangoma Card Count: A101-2=1

[[email protected] sudoers.d]# 

dmesg | tail

WANPIPE(tm) Interface Support Module (c) 1994-2013 Sangoma Technologies Inc
WANPIPE(tm) Multi-Protocol WAN Driver Module (c) 1994-2013 Sangoma Technologies Inc
wanpipe: Probing for WANPIPE hardware.
  alloc irq_desc for 21 on node -1
  alloc kstat_irqs on node -1
pci 0000:03:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21
wanpipe: AFT-A101-SH PCI T1/E1 card found (HDLC (DS) rev.36), cpu(s) 1, bus #3, slot #0, irq #11
wanpipe: Allocating maximum 1 devices: wanpipe1 - wanpipe1.
WANPIPE: TDM Codecs Initialized
WANPIPE(tm) Socket API Module (c) 1994-2013 Sangoma Technologies Inc
NET: Registered protocol family 25
WANPIPE(tm) WANEC Layer (c) 1995-2006 Sangoma Technologies Inc.
wanec_create_dev: Registering Wanpipe ECDEV Device!
WANPIPE: TDM Codecs unloaded.

wanpipe: WANPIPE Modules Unloaded.
[[email protected] sudoers.d]#

[[email protected] sudoers.d]# wanrouter stop

ERROR: Wanpipe configuration file not found:

No devices running, Unloading Modules
[[email protected] sudoers.d]# wanrouter start

ERROR: Wanpipe configuration file not found:

[[email protected] sudoers.d]# wanrouter status

Router is stopped !

[[email protected] sudoers.d]#

Hmm . . . But you surely ARE Sangoma, and as they are not DAHDI compatible directly, without the wanpipe driver properly configured, then what?

I will caveat that I have been using the Sangoma hardware for many years, now by preference over the Digium products, I have never had a problem configuring them. I will also caveat that I don’t use the Dahdi helper for other reasons.

So should not that be your prime priority?

(just me tweaking you guys, sorry :wink: )

This is a priority in 14 as previously stated.

This is a priority in 14 as previously stated

This is called trolling and serves no purpose.

Furthermore, never said it wasn’t a priority. You implied that out of my response (and I have no idea why or how other than to just stir the pot and poke some people)

Maybe but many here are not using 14 and there seems to be a problem in < 14

This is called pragmatism.

There is no 14. What are you talking about. No one can use it. The “bug” was reported today. It’ll get fixed if there is an issue. There is no need for this nonsensical argument from you.

I’m going to ask you once. This is your ONE warning to stop trolling. Back away.

OK, I will stop trolling. Or being a pragmatist.

The reopening of will be addressed on Monday along with other bugs. It has the same priority as everything else. Never once stated anything different. In 14 the priority is to make DAHDi Config even better. Doesn’t mean we aren’t going to fix other bugs.

What does “dahdi_scan” show. That is how cards show up in the GUI.

Next up is select the setting “Run Wanpipe In DAHDI/DIGIUM Mode” in Sangoma Settings to yes (This is in the Dahdi Config Module).

Make sure it stays selected to “yes”. Let me know if it doesn’t

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.