Hello, after upgrading to Freepbx 14, a major problem started.
When you restart the pc, it does not recognize the FXO board.
So I can not make or receive calls.
In principle when I put dahdi_tool nothing appears to me as if no board was connected.
Now what I have to do to start/excecute this steps
service dahdi start ( after this step, the card appear on dahdi_tool)
dahdi_genconf
Then in the control panel enter the connectivity - DAHDi Config - Analog Hardware - press Edit button and then in the 4 buttons put
Group 0 and in Context from-analog
Can anyone know what it’s like to fix it ???
What I miss the most is that it would seem that the dahdi service does not start with the system
Unfortunately, I’ve not been able to get this fixed yet, and it’s being blamed on an incompatible card (which I’m not convinced about). What make of card do you have?
I don’t have to run ‘dahdi_genconf’ and reconfigure hardware settings to get it working. I just need to do a ‘fwconsole restart’ after doing the ‘service dahdi start’ and it all jumps back into life.
Ok, Sounds very similar to my issue, but in your case with supported Digium hardware. Hopefully because you’re running supported hardware, it might be easier to get a the developers to have a look at this.
To help narrow down the problem, after a reboot, can you type the following and post back the results.
[root@freepbx ~]# /etc/init.d/dahdi status
[root@freepbx ~]# echo $?
[root@freepbx ~]# systemctl status dahdi
[root@freepbx ~]# echo $?
If it returns an exit code of ‘0’, then this is meant to indicate ‘Dahdi is running’. If it returns ‘3’ this is meant to indicate that ‘Dahdi is not running’. In my case dahdi status is returning ‘0’ even when Dahdi is not running. systemctl status dahdi is correctly returning ‘3’:
I don’t know why the two different commands report different results, since ‘dahdi status’ is just meant to redirect to ‘systemctl status dahdi’.
From what I understand, the startup script uses ‘dahdi status’ during start up, and will only attempt a dahdi start if it returns a status of 3. Because ‘dahdi status’ is returning the wrong status, a dahdi start is not even attempted.
Out of interest, did your update to FreePBX14 run smoothly, or did it hang up at any point?
If I recall, my update hung up at the point it was modifying the httpd.conf file. I eventually had to reboot the machine and manually fix some issues in the httpd.conf file (I think I had to remove a duplicate ‘Listen 80’ line) to get the web interface running.
I’m fairly certain the upgrade script didn’t finish correctly due to the forced reboot, because I then ran into a number of DAHDi issues. Most of these have been resolved by manually running some of the commands that should have been executed by the script. Unfortunately I still have the outstanding DAHDi startup issue, and I suspect this is due to missing a part of the upgrade that influences the way DAHDi is started in FreePBX14.
Thanks for creating a report! The issue has entered the triage (open) process. That means the issue will wait in this status until the FreePBX team has an opportunity to review the issue. Our weekly triage meetings happen every Monday. Once the issue has been reviewed you may receive comments regarding the next steps towards resolution.
I’ve just finished a fairly large System Update, and this has solved the problem for me. Here is my new version details:
Current PBX Version:14.0.1.15
Current System Version:12.7.3-1708-1.sng7
Total Module Count:119
Enabled:117
The numbers below may be inaccurate if new modules have been released since the last check:
Last online check:2017-10-05T23:32:39+00:00
Modules with Upgrades:0
System Upgrades Available:0
The PBX already update but i have only 108 module enable but, when i see the modules not are no one disabled.
Current PBX Version:14.0.1.15
Current System Version:12.7.3-1708-1.sng7
Total Module Count:117
Enabled:108
The numbers below may be inaccurate if new modules have been released since the last check:
Last online check:2017-10-06T20:12:39+00:00
Modules with Upgrades:0
System Upgrades Available:0
which will bring you back to version 7.0.20-9.sng7. This is what has worked for me. You can always upgrade them back to the latest version later with a yum update if it didn’t work for you.
Note that there’s a lot of discussion about this issue just now, and what I’ve posted above is just a work around that works for me. If you don’t have any Sangoma hardware (and I don’t think you have. I think you have digium hardware), then the wanpipe driver shouldn’t be having any influence on DAHDi, but at least in my case it certainly seems to be having an influence.
● dahdi.service - LSB: DAHDI kernel modules
Loaded: loaded (/etc/rc.d/init.d/dahdi; bad; vendor preset: disabled)
Active: active (exited) since Sat 2017-10-07 09:53:32 UTC; 21min ago
Docs: man:systemd-sysv-generator(8)
Process: 1375 ExecStart=/etc/rc.d/init.d/dahdi start (code=exited, status=0/SUCCESS)
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: wcb4xxp: [ OK ]
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: wctc4xxp: [ OK ]
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: xpp_usb: [ OK ]
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: r1t1: [ OK ]
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: rxt1: [ OK ]
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: rcbfx: [ OK ]
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: D: auto '/sys/bus/dahdi_devices/devices/pci:0000:02:05.0’
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: auto-assign /sys/bus/dahdi_devices/devices/pci:0000:02:05.0
Oct 07 09:53:32 localhost.localdomain dahdi[1375]: Running dahdi_cfg: [ OK ]
Oct 07 09:53:32 localhost.localdomain systemd[1]: Started LSB: DAHDI kernel modules.
[root@localhost ~]# echo $?
0
but i need to make fwconsole restart to make and receive calls