With version 7.0.20-9.sng7 of the wanpipe drivers I don’t need to do any fwconsole restart. DAHDi starts correctly on boot.
With version 7.0.20.13-1.sng7 of the wanpipe drivers (and the ones prior to 7.0.20-9.sng7) DAHDi does not start on boot. I need to do a service dahdi start, then fwconsole restart to get it working.
And before the latest updates you needed to restart DAHDI with this version of the Wanpipe drivers, right?
Have a nice day!
Nick
To be clear, and as mentioned in by previous post:
I should have also mentioned that a fwconsole restart on its own is not enough. It reports odd things, and DADHi still doesn’t actually run:
[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
DAHDi: Already started
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 4646
Running Asterisk post from Ucp module
Starting UCP Node Server...
[>---------------------------] 1 sec
Started UCP Node Server. PID is 4736
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 4834
Running Asterisk post from Zulu module
This product is not licensed
[root@freepbx ~]#
Doing a service dahdi start before fwconsole restart, then it all starts working correctly:
[root@freepbx ~]# service dahdi start
Starting dahdi (via systemctl): [ OK ]
[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 Started
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 6979
Running Asterisk post from Ucp module
Starting UCP Node Server...
[>---------------------------] < 1 sec
Started UCP Node Server. PID is 7063
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 7156
Running Asterisk post from Zulu module
This product is not licensed
[root@freepbx ~]#
I read that but there is something very important missing…
Both the version of the Wanpipe drivers and the version of the kernel is important… They are essentially built against a kernel AFAIK and while they support being used after a kernel with very subtle differences with the help of weak-modules this has pretty big limitations…
Some combinations result in broken Wanpipe drivers because of a mismatch between the Wanpipe drivers and the kernel…
It sounds like it’s only with a non-workiing Wanpipe drivers combination that things work for you without further interventions needed like restarting…
All of the Wanpipe drivers published worked for me when paired with the right kernels. Maybe not fully smoothly but as long as I was willing to have them timeout after 4-5 minutes at boot I never had to restart anything…
Good luck and have a nice day!
Nick
Ok…
Before the big update a few days ago, DAHDi would only start if I did a service dahdi start, then fwconsole restart. I don’t know what version of dahdi & wanpipe I was running at this point, but everything was being kept up to date.
After the big update (which I assume updated the both the kernel and the dahdi & wanpipe drivers?), everything started working correctly for me. At this point my Wanpipe driver was at 7.0.20-9.sng7.
Today the wanpipe drivers were updated to version 7.0.20.13-1.sng7. Having updated these drivers, once again DAHDi will only start if I do a service dahdi start, then fwconsole restart.
Wanpipe was actually broken at 7.0.20-9 with the new kernel. Since you have unsupported hardware that is acting like a digium card this might have made things better for you temporarily. Now that it works with supported hardware but broken for your unsupported it hard to say. You’re basically having the same issues others are so nothing has changed and we are where we were at last week. Which is a good thing.
Yes. Back where I was a week ago.
There is another member on here with the same issues that I’m having, who is using a digium (supported?) card:
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 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
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…
If I give it time to finish, things do end up being correctly initialized in the end and everything appears to be working…
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 [FREEPBX-15491] FreePBX 13 to 14 upgrade fails - Upgrade loops apparently because of lack of DNS resolution - Sangoma Issue Tracker)
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