As far as I know Wanpipe 7.0.20-9.sng7 and kernel 3.10.0-514.26.2...

This resulted in a working Wanpipe drivers and the need for you to start DAHDI manually..

No, it only updated the kernel unfortunately and did not provide matching Wanpipe drivers...

This resulted in broken Wanpipe drivers but for you this fixed things...

I reported this here:

and created this ticket: Latest system updates (October 2017) breaks Wanpipe drivers.

Now in response to this ticket the version of the Wanpipe drivers was updated to 7.0.20.13-1...

This fixed things for me, broke them for you...

When i said things were somewhat convoluted earlier this is what I was referring to...

Somehow proper DAHDI initialization of a non-Sangoma card appears to require the Wanpipe drivers to be broken in some way. Having them not find a Sangoma card is not enough.

Something in the way DAHDI is initialized at startup make this a requirement. Maybe something in the Wanpipe init script initialize DAHDI in a non-compatible way when the drivers are functional. I don't know, I am no guru in this, it's only an hypothesis...

Now even for me things are not perfect but if I don't mind a very slow boot (this adds like 4-5 minutes to the boot and actually times out at one point) and used the scripts as they were published once the system has booted there is no need for me to restart anything, everything works perfectly...

If however I modify one of the published script to have the Wanpipe drivers start after the network service is up it doesn't take those additional 4-5 minutes and doesn't time out but it looks like DAHDI no longer starts properly for me either...

(or maybe starts too late, are these things started sequentially?)

It seems to be somehow timing related because it works for a while and then starts failing (at least this is how it behaves now)...

It's not a real fix but if you want to try it I wonder what would happen if you did

chkconfig wanrouter off

and rebooted...

and if this is not enough

chkconfig --list | grep -i dahdi
chkconfig dahdi on

and rebooted...

The first line command would stop the Wanpipe drivers from being initialized, whether they are functional or not, the second and third command would check if DAHDI is setted up to start at boot (please post the results if you do this, I am not sure how things will be initialized when the Wanpipe drivers are not involved) and actually set it to start at boot if it doesn't already...

To revert things, replace on with off and vice versa...

Don't feel obligated to do this, I am only suggesting this as a workaround...

Good luck and have a nice day!

Nick

Yikes, I take too much time to write these posts, both of you had time to post in the mean time....

Have a nice day!

Nick

Ok. Without any modifications,

chkconfig --list | grep -i dahdi gives the following:

[root@freepbx ~]# chkconfig --list | grep -i dahdi

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

      If you want to list systemd services use 'systemctl list-unit-files'.
      To see services enabled on particular target use
      'systemctl list-dependencies [target]'.

[root@freepbx ~]#

and chkconfig --list | grep -i wanrouter gives the following:

[root@freepbx ~]# chkconfig --list | grep -i wanrouter

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

      If you want to list systemd services use 'systemctl list-unit-files'.
      To see services enabled on particular target use
      'systemctl list-dependencies [target]'.

wanrouter       0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@freepbx ~]#

Does that look right?

Well, that worked! With all the latest drivers installed, DAHDi started up perfectly on reboot.

Your system was the result of an upgrade or a new install?

I thought it was an upgrade but my upgrade has /etc/init.d/dahdi which chkconfig "sees" and which does not appear to be present on your system...

Which one is right, I wish I knew...

For real?

No restart needed, no nothing?

Does it survive a few reboots, both warm and cold?

if it does work consistently it's only a workaround until the root cause of the problem is found though...

Good luck and have a nice day!

Nick

An upgrade, but a stalled upgrade (stalled when updating http.d, if I recall), which has then required a few subsequent 'fixes' along the way. I think this was why I had to do the 'weak modules' fix, amongst other fixes.

I also have the /etc/init.d/dahdi file, but as posted above, it's not seen by chkconfig.

It's survived one reboot, and one fwconsole restart so far!

Interestingly, wanrouter is still reporting errors when I do a fwconsole restart, even though I disabled wanrouter startup through chkconfig.:

<snip>
Shutting down Asterisk Gracefully. Will forcefully kill after 30 seconds.
Press C to Cancel
Press N to shut down NOW
[============================] 2 secs
Wanrouter: No valid Sangoma Hardware found, if you have no Sangoma cards this is OK
Stopping DAHDi for Digium Cards
DAHDi Stopped
Queue Callback Server is not running
Running FreePBX startup...
Running Asterisk pre from Dahdiconfig module
Wanrouter: No valid Sangoma Hardware found, if you have no Sangoma cards this is OK
Starting DAHDi for Digium Cards
DAHDi Started
<snip>

I can almost guarantee you that the Wireless provider will not prove that call information to you when a call is forwarded to your flowroute DID.

I am definitely low on caffeine today... I did not only read that you were running an upgrade, I actually helped you for at least that fix (ie "weak modules)...

Looks like it's not needed anyway... I could be wrong but I guess DAHDI is now started by the fwconsole script...

Keep us posted to see if it continues to work correctly or starts misbehaving at one point...

When you have a chance try a few reboots (including from being powered off) to make sure things are always OK after without needing a restart..

Good luck and have a nice day!

Nick

I just made a little edit above, about wanrouter. It still seems to run, even though I've disabled it through chkconfig. I think it might also be getting started by fwconsole?

Done a few reboots and fwconsole restarts now, and everything seems to be in order so far. I'll try a power down shortly.

It's disabled from starting at boot but one of the steps fwconsole restart is to try to initialize it in some way before continuing...

Unfortunately what it does here is not enough to get things working when you have a card which needs those drivers, I tried...

I was hoping to find another way to avoid my slow boot and have everything working...

I noticed and replied within seconds of your post I think...

Whatever it does here is not enough to get things working for me with a card which needs those drivers...

I would not worry about it unless it causes you issues...

Do keep in mind that it's a workaround, a more proper fix will have to be found by the FreePBX devs...

Good luck and have a nice day!

Nick

Thanks for your help, and I'm sorry you've not been able to get your system working properly yet. Hopefully some of the work we've been doing here will give the devs some pointers.

Wanrouter should not be chkconfig on. It gets started from fwconsole.

You are welcome and don't worry, except for a slower boot than it should I am pretty lucky things work as they should...

I was one of the initial testers when they made the distro upgrader "script" publicly available and my test system was, I think, one of the systems which needed the most fixes to get working...

If I had no other choice but to try to get things to work entirely correctly I would put the time but my time is better spent elsewhere (like trying to help people here) than trying to track down a problem other people are, at least currently , more qualitified than me to track down...

Good luck and have a nice day!

Nick

Hi Tony!

I actually tried that with my Sangoma A200 when I saw that it fixed thing for him and knowing some initialization of the Wanpipe drivers is done by fwconsole. I was hoping it would fix my slow boot (caused by the wanrouter service running before the network service is up) and causing a timeout. It definitely booted a lot faster things didn't work...

Unfortunately something doesn't get initialized properly DAHDI-wise (I think).

The problem when I put wanrouter off is essentially like the one I described here:

I also had a few error message popup when I remoted my system using SSH... Nothing which seemed critical and the two I saw appeared only once but still...

Fortunately chaser doesn't seem to have that problem...

Have a nice day!

Nick

Right. I think we've got this sorted now. Discussion had moved to another thread for some reason, but the solution was fairly straight forward in the end!

Before running the command above I did a quick check with chkconfig --list | grep -i wanrouter which gave the following

[root@freepbx ~]# chkconfig --list | grep -i wanrouter

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

      If you want to list systemd services use 'systemctl list-unit-files'.
      To see services enabled on particular target use
      'systemctl list-dependencies [target]'.

wanrouter       0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@freepbx ~]#

Turns out this probably was the real fix...

All working perfectly now :).

OK, what I just said is not entirely accurate...

My system becomes available a lot faster, actually before the freepbx service has finished doing its job...

It's too early to say before I do more exhaustive tests but it seems like this fixes my slow boot problem... Unfortunately, and more on that later in this message, it only does this once...

It does add new ones tough...

I occasionally get an error message from System Admin about being unable to create a directory and another error message I unfortunately lost but hopefully will get again...

Then why is there code in /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl which sets it up that way?

(and I know it's working because of this https://issues.freepbx.org/browse/FREEPBX-15491?focusedCommentId=110997&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-110997)

Running wanrouter before the network service is on (like /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl tries to by default) causes problems and running it after seemed to now after the updates (I get line voltage but no dial tone). I am beginning to wonder if I all what is needed is to give it a little bit more time to finish starting up everything. I an pretty sure I did but I would need to test this more exhaustively to be absolutely sure...

Hopefully wanrouter will not be reactivated at boot for @chaser (which doesn't have hardware which uses it) but for me it was already automagically reenabled as soon as /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl got run at one point by fwconsole...

Currently short of modifying more heavily those Wanpipe scripts there seems to be no way to avoid having wanrouter start at boot by a SysV script...

Have a nice day!

Nick

Not to start it at boot I think is but not the way I suggested you do it temporarily for now...

The Wanpipe scripts are actually setting things up that way...

If I try to do the same thing I told you to do

ie

chkconfig wanrouter off

I get one or two error messages (which relatively seem harmless and which you apparently did not get so it's probably specific to my Sangoma Wanpipe card) but it doesn't stick..

It takes a while before everything gets initialized but once it is done everything works beautifully..

Unfortunately, it only survives one boot...

There is code in /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl (see https://issues.freepbx.org/browse/FREEPBX-15491?focusedCommentId=110997&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-110997 for more information) which actually reenables wanrouter to start at boot...

Since you do not have a card which uses Wanpipe this bit of code hopefully does not get run (if it did things would have went back to the way they were before after one reboot) but for someone like me which has a card which does use Wanpipe the fix I suggested you do will not work for them (unless they reapply it over and over again...).

So for now only consider this a workaround and to everyone else, if you have a card which uses Wanpipe, don't bother doing this as it will not survive a reboot...

Have a nice day!

Nick

Ok, and it turns out that I'm still having some problems too. DAHDi now consistently starts on boot (so far, anyway), but fwconsole restart has a 50/50 chance of throwing a dahdi error:

[root@freepbx ~]# fwconsole restart
Running FreePBX shutdown...

Stopping RestApps Server
Stopped RestApps Server
Stopping UCP Node Server
[>---------------------------] 1 sec
Stopped UCP Node Server
Stopping Chat Server
Stopped Chat Server
Zulu Server is not running
Shutting down Asterisk Gracefully. Will forcefully kill after 30 seconds.
Press C to Cancel
Press N to shut down NOW
[============================] 2 secs
Wanrouter: No valid Sangoma Hardware found, if you have no Sangoma cards this is OK
Stopping DAHDi for Digium Cards
DAHDi Stopped
Queue Callback Server is not running
Running FreePBX startup...
Running Asterisk pre from Dahdiconfig module
Wanrouter: No valid Sangoma Hardware found, if you have no Sangoma cards this is OK
Starting DAHDi for Digium Cards
DAHDi Failed: The command "/etc/init.d/dahdi start" failed.

Exit Code: 1(General error)

Working directory: /root

Output:
================
Starting dahdi (via systemctl):  [FAILED]


Error Output:
================
Job for dahdi.service failed because the control process exited with error code. See "systemctl status dahdi.service" and "journalctl -xe" for details.

Running Asterisk pre from Firewall module
Running Asterisk pre from Sysadmin module
Running Sysadmin Hooks
Restarting fail2ban
fail2ban Restarted
Updating License Information for 58918804
Checking Vpn server
Starting Asterisk...
[============================] 2 secs
Asterisk Started
Running Asterisk post from Dahdiconfig module
Running Asterisk post from Endpoint module
Running Asterisk post from Pagingpro module
Running Asterisk post from Restapps module
Starting RestApps Server...
[>---------------------------] 1 sec
Started RestApps Server. PID is 6307
Running Asterisk post from Ucp module
Starting UCP Node Server...
[>---------------------------] 1 sec
Started UCP Node Server. PID is 6449
Running Asterisk post from Vqplus module
RestApps is not licensed.
Running Asterisk post from Xmpp module
Starting Chat Server...
[>---------------------------] 1 sec
Started Chat Server. PID is 6537
Running Asterisk post from Zulu module
This product is not licensed
[root@freepbx ~]#

Once it has failed like this, a reboot is required to get it going again.

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ ┃
┃ Sangoma 6 to 7 Upgrade Tool ┃
┃ ┃
┃ Distro Upgrade - Version 1707-17.sng7 ┃
┃ Build Date: 2017-08-23 ┃
┃ ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Checking prerequsites...
Checking bitsize of machine [ ] - x86_64
Checking available disk space [ ] - 99G Available
Checking for outdated system [ ✘ ]
This machine has pending yum updates. This machine must be up to date before
the upgrade tool is run. To resolve this issue please run 'yum update'. The
output of 'yum check-update' is below.

Loaded plugins: fastestmirror, kmod
Cleaning repos: base extras pbx schmooze-commercial updates
18 metadata files removed
5 sqlite files removed
0 metadata files removed
Loaded plugins: fastestmirror, kmod
Loading mirror speeds from cached hostfile

dahdi-firmware.noarch 1:2.9.5-1.shmz65.1.15 pbx
dahdi-firmware-a4a.noarch 1:1.a0017-1.shmz65.1.15 pbx
dahdi-firmware-a4b.noarch 1:1.d001e-1.shmz65.1.15 pbx
dahdi-firmware-a8a.noarch 1:1.1d0017-1.shmz65.1.15 pbx
dahdi-firmware-a8b.noarch 1:1.1f001e-1.shmz65.1.15 pbx
dahdi-firmware-hx8.noarch 1:2.06-1.shmz65.1.15 pbx
dahdi-firmware-oct6114-032.noarch 1:1.07.01-1.shmz65.1.15 pbx
dahdi-firmware-oct6114-064.noarch 1:1.05.01-1.shmz65.1.15 pbx
dahdi-firmware-oct6114-128.noarch 1:1.05.01-1.shmz65.1.15 pbx
dahdi-firmware-oct6114-256.noarch 1:1.05.01-1.shmz65.1.15 pbx
dahdi-firmware-oct6126-128.noarch 1:01.07.04-1.shmz65.1.15 pbx
dahdi-firmware-tc400m.noarch 1:MR6.12-1.shmz65.1.15 pbx
dahdi-firmware-te133.noarch 1:1.7a001e-1.shmz65.1.15 pbx
dahdi-firmware-te134.noarch 1:1.780017-1.shmz65.1.15 pbx
dahdi-firmware-te435.noarch 1:1.13001e-1.shmz65.1.15 pbx
dahdi-firmware-te436.noarch 1:1.10017-1.shmz65.1.15 pbx
dahdi-firmware-te820.noarch 1:1.76-1.shmz65.1.15 pbx
dahdi-firmware-vpmoct032.noarch 1:1.12.0-1.shmz65.1.15 pbx
fail2ban.noarch 0.8.14-1.shmz65.1.131 schmooze-commercial
iSymphonyServerV3-fpbx.noarch 3.5.1.24-1 pbx

When I run yum update

I get a bunch of these errors

Transaction Check Error:
_ file /opt/isymphony3/server/conf/main.xml from install of iSymphonyServerV3-fp bx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59 -1.noarch_
_ file /opt/isymphony3/server/config-vars.sh from install of iSymphonyServerV3-f pbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.5 9-1.noarch_
_ file /opt/isymphony3/server/config.sh from install of iSymphonyServerV3-fpbx-3 .5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59-1.n oarch_
_ file /opt/isymphony3/server/iSymphonyServer.jar from install of iSymphonyServe rV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3. 3.2.59-1.noarch_
_ file /opt/isymphony3/server/iSymphonyServer.sh from install of iSymphonyServer V3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3 .2.59-1.noarch_
_ file /opt/isymphony3/server/install.sh from install of iSymphonyServerV3-fpbx- 3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59-1. noarch_
_ file /opt/isymphony3/server/modules/asterisk/module.xml from install of iSymph onyServerV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonySer verV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/chat/module.xml from install of iSymphonyS erverV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV 3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/contact/module.xml from install of iSympho nyServerV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServ erV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/framework/module.xml from install of iSymp honyServerV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonySe rverV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/lang-en-us/module.xml from install of iSym phonyServerV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyS erverV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/pbx/module.xml from install of iSymphonySe rverV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3 -3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/xmpp/module.xml from install of iSymphonyS erverV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV 3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/asterisk/plugins/com.xmlnamespace.panel.ad min.asterisk_1.0.0.jar from install of iSymphonyServerV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/asterisk/plugins/com.xmlnamespace.panel.ag ent.asterisk.recording_1.0.0.jar from install of iSymphonyServerV3-fpbx-3.5.1.24 -1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/asterisk/plugins/com.xmlnamespace.panel.ag ent.asterisk.voicemail_1.0.0.jar from install of iSymphonyServerV3-fpbx-3.5.1.24 -1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/asterisk/plugins/com.xmlnamespace.panel.pr oxy.asterisk_1.0.0.jar from install of iSymphonyServerV3-fpbx-3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/asterisk/plugins/com.xmlnamespace.panel.re st.asterisk_1.0.0.jar from install of iSymphonyServerV3-fpbx-3.5.1.24-1.noarch c onflicts with file from package iSymphonyServerV3-3.3.2.59-1.noarch_
_ file /opt/isymphony3/server/modules/asterisk/plugins/com.xmlnamespace.panel.se rver.core.asterisk.callhistory_1.0.0.jar from install of iSymphonyServerV3-fpbx- 3.5.1.24-1.noarch conflicts with file from package iSymphonyServerV3-3.3.2.59-1. noarch_

Strange part, I no longer have iSymphony. I removed it from the Module Admin section. I wasn't able to delete /opt/isymphony even when trying to force delete

Now you see why I am so insistent about testing things multiple times, under different conditions...

There seems to be quite a few things involved in having this works correctly consistently...

In my case I think timing might be in for some things, in yours I guess we should

See "systemctl status dahdi.service" and "journalctl -xe" for details.

to see if there is anything we can do about your new problem...

Good luck and have a nice day!

Nick

I got it working now I can make and receive call from asterisk. Now I have an ext on cucm 1000 how can I forward all incoming calls to that ext. also when I try to call from cucm an outbound number it is ringing the ext that I have enable for the in bound route in cucm. I can I forward the call to the pstn