I have a 14 Sangoma PBX 60 with FreePBX 1707-1 Distro on them.
When i reboot the Nic does not Start. i have verified that it is set to start on boot.
If i Statically set the IP and reboot it still does not start.
If i do a fwconsole restart then the nic will initialize.
any idea if its a bad Build on the distro? or any suggestions would be great.
Hi!
A few questions…
-
Was this installed from scratch or an upgrade from a previous version using the beta distro upgrade “script”? It sounds like this is a new install.
-
Is this a pure SIP system or are there other technologies involved like DAHDI?
Some of the people, like me, who upgraded from FreePBX 13 to FreePBX 14 using the distro upgrade “script” had a loss of network connectivity at one point…
The two most likely culprits at the time were DAHDI hardware and VMs and the most likely one, common to more than one upgrade, was DAHDI hardware…
Good luck and have anice day!
Nick
Rebuilt From Scratch with Usb Recovery Key
Also If i Blow it Away and rebuild it with 10.13.66 Recover Usb Key all hardware works Fine.
only having the Issue with any of my systems if Built with 1707-1 USB Recovery key.
Hi,
Do you have DAHDI hardware in that system?
Those cards usually look like network cards to the system and this seems / seemed to cause problems with the new new Linux distro…
Have a nice day,
Nick
To clarify, Sangoma’s wanpipe drivers have network interfaces because they can do more than DAHDI , Most other DAHDI hardware devices do not.
1 Like
I didn’t want to point fingers in one specific direction 
but you are right…
Considering the OP uses Sangoma hardware, there’s a lot of chances that if he has DAHDI hardware it might be hardware which uses the Wanpipe drivers…
I also currently have problems with those same Wanpipe drivers on Sangoma 7, they fail to initialize properly at boot but not after adding more than 4 minutes of boot time so I am far from sure every issue related to their use has been fixed.
I reported the problem in the ticket I initially opened to track down all the issues I had with the distro upgrade “script” but I am not sure if anyone receives notifications when I add to this ticket anymore (even though the ticket is not closed…)…
Have a nice day,
Nick
i do have an A200 card in the system. and a A101 in the other so what is the solution?
I think you should go to Sangoma support for this.
Hi!
Let’s first try to see if your problem is caused by them…
If you can easily remove the A200, remove it from the system…
If it’s a pain to remove, try
systemctl disable wanrouter
If you have network connectivity, please report back…
I am not sure how recent FreePBX 1707-1 is package wise, it’s possible you might have an updated set of Wanpipe/DAHDI packages to download for it to work OK…
(I still have some problems with them but overall my systems works OK…)
Let’s start by making sure your problem is related to those cards for now though…
Good luck and have a nice day!
Nick
An interesting problem, perhaps
updatedb
locate wanrouter.service
and if you have it , please post it’s content, it is likely starting too early and screwing up your network
Hi dicko,
On my own system it starts just before the real network card but actually fails after a little bit more than 4 minutes… Once it fails the startup continues and the network card initializes…
It does work later when Asterisk tries to use it but then it’s probably restarted by fwconsole so it’s difficult to say if it truly failed at boot or the system mistakenly thought it was the case…
I am talking here of a working system though, one which setup completed which I don’t believe is truly the case for the OP system…
Back when I initially upgraded my system there were problems with the wanpipe and DAHDI drivers and my system did lose network connectivity at one point…
The problem was supposed to be fixed but it looks like it was not entirely…
Have a nice day
Nick
arrange for systemd to only start wanrouter after multiuser, you will be fine
1 Like
That won’t find anything…
It’s actually started by an old style SysV file…
systemctl “sees” wanrouter.service but looks looks like it’s just giving us a way to access those old style startup files in a consistent way…
Looks like I have some reading to do…
Thank you and have a nice day!
Nick
Then rename the file in the startup scripts to something above the network script
Hi dicko!
and
You are definitely on to something, wanrouter starts properly if it is started after network…
I changed the chkconfig line of /usr/sbin/wanrouter (they made a symbolic link to it) to
# chkconfig: 2345 20 80
and issued
chkconfig wanrouter on
To have the rcX.d entries refreshed…
It did work but unfortunately only once, something reorganizes them to what they were after and wanrouter is once again started before network on the next boot if I don’t re-refresh those rcX.d entries…
I am currently digging up why that happens…
Thank you very much and have a nice day!
Nick
It is the name of the symlink, S16* starts before S17* so rename it to something higherthan the network SNN* script
I changed
# chkconfig: 2345 7 9
to
# chkconfig: 2345 20 80
before wanrouter was
S08wanrouter
and network
S10network
after wanrouter became
S20wanrouter
so it starts after network…
Problem is after a reboot wanrouter returns to
S08wanrouter
Isn’t changing that chkconfig line at the top of the SysV script the legit way of changing those symbolic links?
Thank you and have a nice day!
Nick
OK, I figured it out…
config_boot_linux() of /etc/wanpipe/wancfg_zaptel/wancfg_zaptel.pl gets runs after each boot and this is what updates the wanrouter script and recreates those links…
I had to set the start and stop level at the top of that function to the ones I had decided on…
i.e.
my $wanrouter_start_level=20;
my $wanrouter_stop_level=80;
They were initiallty set to
my $wanrouter_start_level=8;
my $wanrouter_stop_level=91;
I guess I could have kept that stop level but I had decided on 80…
Boot time is now under a minute and starting wanrouter no longer fails…
Thank you very much dicko and have a nice day!
Nick
PS @GameGamer43, this fixes the last problem I reported on https://issues.freepbx.org/browse/FREEPBX-15491?focusedCommentId=109614&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-109614 .
We are aware of the updates you have been adding
1 Like
Wow thanks for the suggestions i will be testing this morning. and give my feedback asap