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