Hi all,
When I reload the config from either the web gui or via asterisk cli then my isdn lines are dropped - I then need to do a dahdi restart to get them back. This is not such a major problem except that I need to always remember and of course doing a dahdi restart drops all the current calls.
I am using FreePBX distro 3.211.63 32bit and asterisk 11 - dahdi drivers are 2.6.1.
the isdn lines are plugged into a digium B410P card.
otherwise the system seems to be operating fine.
Any help appreciated.
I have tried a lot of things here and failed miserably - I still get the same situation every time a config change is made - my ISDN lines are dead (giving congestion message), but the analogue card is operating fine - doing a dahdi restart from the asterisk cli fixes the problem.
Any help
Same or similiar problems here with a HFC-4S Card (which is almost the same as a Digium B410P, all those cards are HFC based).
As soon as “Apply Changes” is executed in the GUI, my ISDN lines are down. I’ve tried to track down the underlying cause and is seems to be /etc/init.d/dahdi reload: This calls the dahdi_cfg executable and as soon as dahdi_cfg is run my ISDN lines are down. To bring them back up I need to completely restart dahdi (which requires shutting down asterisk first, otherwise dahdi stop complains “Module wcb4xxp is in use”).
After removing the DAHDi Configuration Module from FreePBX “Apply Changes” does not seem to mess with the DAHDi init scripts anymore and I can sucessfully apply changes. No more GUI configuration for DAHDi settings though now…
@josep, l0ft13
Can you check by manually running dahdi_cfg once if this is also the root cause of your problem?
I’m using the latest FreePBX Distro (FreePBX-4.211.64-7-x86_64-Full-1379605000.iso).
DAHDI Version:
[root@freepbx dahdi]# dahdi_cfg -vvv
DAHDI Tools Version - 2.7.0
DAHDI Version: 2.7.0
FreePBX:
DAHDi Config FreePBX Module: 2.11.26
Installed Asterisk Version: 1.8 or 11 - does not make any difference.
Hardware:
ISDN Card: beroNet BN4S0e (had the same problem with another HFC-4S card though from “IOB4ST”)
After starting “dahdi_cfg” on the console, I get “Circuits are busy now” on the phone and the following in asterisk -r:
== Primary D-Channel on span 1 up
– Span 1: Channel 0/2 got hangup, cause 27
– DAHDI/i1/08003301000-2 is circuit-busy
– Hungup ‘DAHDI/i1/08003301000-2’
== Everyone is busy/congested at this time (1:0/1/0)
This can then only be solved by completely stopping DAHDi using:
/etc/init.d/asterisk stop && /etc/init.d/dahdi restart && /etc/init.d/asterisk start
(or of course a system reboot)
If you’d like to help us debug I implore you to remove lines 5-6 and 45-46 of page.dahdi.php in the dahdi modules folder and then see if anything changes.
Thank you very much for your help and suggestions! No need to implore, I’ll do whatever you tell me anyway
I have removed those lines and “Apply Changes” still does to DAHDi whatever makes my ISDN card go into this state of strangeness… (I’m not really applying any relevant changes, just toggling a Music-On-Hold option)
While removing the lines as requested, I noticed in your PHP file
"$astman->send_request(‘Command’, array(‘Command’ => ‘dahdi restart’));"
I thought since the module unload/load lines you wanted me to remove were not having any effect that this line might be responsible. So I just entered “dahdi restart” on the Asterisk CLI.
To my amazement: “dahdi restart” on the asterisk CLI did NOT bring down my ISDN lines (what I expected). But instead, if the ISDN lines were already in the non-working state, “dahdi restart” on the Asterisk CLI was actually able to make them work again ! Exactly the opposite of what I had expected.
So now I can at least use
asterisk -rx "dahdi restart"
instead of
/etc/init.d/asterisk stop && /etc/init.d/dahdi restart && /etc/init.d/asterisk start
to restore a working state…
Since line 4-8 of page.dahdi.php unload / load the module and then do a dahdi restart I tried copy&pasting
module unload chan_dahdi.so
module load chan_dahdi.so
dahdi restart
directly into the Asterisk CLI. Works fine, no problems… Something else must be happening when I press the “Apply Config” button. Could some other file be calling dahdi_cfg?
Manually running dahdi_cfg is my way of reproducing the problem… I dug around further and noticed that I did not even have to restart /etc/init.d/dahdi - the only thing needed to do was restarting Asterisk to get things working again.
My guess:
Something during “Apply Changes” triggers /usr/sbin/dahdi_cfg. The logs the following to Asterisk CLI:
[2013-10-18 01:31:45] NOTICE[2140]: chan_dahdi.c:3323 my_handle_dchan_exception: PRI got event: Alarm (4) on D-channel of span 1
[2013-10-18 01:31:45] WARNING[2144]: chan_dahdi.c:8209 handle_alarms: Detected alarm on channel 1: Red Alarm
[2013-10-18 01:31:45] WARNING[2144]: chan_dahdi.c:8209 handle_alarms: Detected alarm on channel 2: Red Alarm
[2013-10-18 01:31:45] NOTICE[2140]: chan_dahdi.c:3323 my_handle_dchan_exception: PRI got event: No more alarm (5) on D-channel of span 1
[2013-10-18 01:31:45] NOTICE[2144]: chan_dahdi.c:4112 handle_clear_alarms: Alarm cleared on channel 1
[2013-10-18 01:31:45] NOTICE[2144]: chan_dahdi.c:4112 handle_clear_alarms: Alarm cleared on channel 2
and afterwards the card is no longer working down.
My guesses on ways to fix this (based on the assumption that something calls dahdi_cfg on “Apply Changes”):
do not call dahdi_cfg on “Apply Changes”
call dahdi_cfg BEFORE doing a dahdi reload in asterisk
fix asterisk or dahdi_cfg so that they won’t break each other
I tried renaming the dahdi_cfg executable after the system had booted (it needs to run once in the init.d script for dahdi to work). With the dahdi_cfg executable gone => “Apply Changes” does not break my ISDN card anymore! So I guess something in FreePBX must be running this file! Should it?
We’ve got same problem and i believe it’s rather dahdi drivers than FreePbx problem (executing dahdi_cfg kills BRI interfaces).
Temporarily i’ve workarounded it by simple script running from cron every 2 minutes:
#!/bin/bash
if [ asterisk -rx "dahdi show channel 10"|grep InAlarm|awk '{print $2}' -eq “1” ]; then
echo "ISDN ALARM, RESETTING" asterisk -rx "dahdi restart"
fi
exit 0
If will have some spare time i’ll try recompiling dahdi libpri and asterisk and maybe do some more debugging.
Unfortunately it has been closed as “WorksForMe” since the bug reporter was not providing more detailled information.
I’ve now had a look at the dahdiconfig module sourcecode and the way I (as someone who does not really know php) understand it, the following is what happens:
/var/www/html/admin/modules/dahdiconfig/functions.inc.php seems to be the main file that provides the functionality of the module to FreePBX and right at the start it calls
$this->cards = new dahdi_cards();
$this->cards->dahdi_cfg();
The first line will also run dahdi_cfg via the constructor that calls the load() function, but thats only if the hwaddress has changed, so the problem is the second line.
I commented it out by putting /* before and */ after it
==> DAHDI no longer breaks on “Apply Changes”
==> DAHDI still works even on cold reboots (because dahdi_cfg is called in the init script!).
Negative effects of this: If you change “System Settings” (=/etc/dahdi/system.conf) you PERHAPS may not only need to “Restart Dahdi & Asterisk” as the GUI tells you but you need to reboot. But since System Settings contains exactly ONE configurable option (and the rest of the system.conf file probably only is autogenerated when you put new hardware in - something that seems to trigger a separate dahdi_cfg anyway) this is certainly WAY better than having your ISDN lines go down on every “Apply Changes”. Also I’m not sure if this is even the case - that probably depends on what the button “Restart Dahdi & Asterisk” actually does. It calls for an “amportal restart” but I don’t know what that exactly encompasses.
Is removing this line a proper fix? I guess only Andrew Nagy or Bryan Walters can tell (they seem to be the ones who wrote most of this code). Another option of fixing this is making sure that AFTER “Apply Changes” calls this function of the dahdiconfig module, a dahdi reload command is sent to asterisk. Currently, I don’t know if a dahdi reload command is not sent at all to asterisk or if it is just done in the wrong order…
Removing the line fixed it for me, but for a proper fix one of those two schmoozecom employees mentioned needs to have a look at this of course… Personally I think calling dahdi_cfg on every “Apply Changes” is absolutely uncalled for since it only applies changes in a single very specific config file that changes extremely rarely.
