Upgrade to v14 error > Network

Hi!

What is your network card, any possibility it is no longer supported?

Good luck and have a nice day!

Nick

Ah, I do have an A200.

I will take a look at your other suggestions…

Hi!

An easy way to see if it makes a difference might be to remove the card temporarily…

The script you ran has quite a few problems that were present when I ran it over a month ago fixed, Back when I run it looks like something I did at one point somehow got me out of the no network connectivity problem.

Somehow, while trying to fix some of those problems, network connectivity got restored…

The A200 I have (and other DAHDI hardware (including another A200) another early tester had) seemed to play a part in our loss of network connectivity.

Mind you, there were other DAHDI and Wanpipe problems present that you should no longer have but I had to get unstuck from that loss of network connectivity to have them…

After that problem got apparently resolved I could not access the FreePBX GUI and I had to disable both the iptables and firewalld service if I recall correctly.

I do not recall anybody else mentioning this problem and I am not sure why this was needed. Not everyone has telephony hardware (like the A200) and not everyone’s setup essentially put the PBX in a DMZ of sorts…

(A real DMZ, a different subnet with it’s own firewall rules, usually more server than the main LAN…)

The other person who had network connectivity problem and telephony hardware had to restore from a backup so i do not know if he would have had the same problem or not…

To this day I still have one problem related to the Wanpipe drivers… About 4 of the about 5 minutes of the boot time of my system are taken by them:

re:

Sep 9 09:18:17 jester wanrouter: Configuring interfaces: w1g1
Sep 9 09:18:17 jester wanrouter: done.
Sep 9 09:18:17 jester wanrouter: Waiting for Dahdi /dev/dahdi …
Sep 9 09:22:42 jester systemd: wanrouter.service start operation timed out. Terminating.
Sep 9 09:22:42 jester systemd: Failed to start SYSV: WANPIPE WAN Router Initialization Script…
Sep 9 09:22:42 jester systemd: Unit wanrouter.service entered failed state.
Sep 9 09:22:42 jester systemd: wanrouter.service failed.
Sep 9 09:22:42 jester systemd: Starting LSB: Bring up/down networking…
Sep 9 09:22:43 jester network: Bringing up loopback interface: [ OK ]
Sep 9 09:22:43 jester kernel: sky2 0000:04:00.0 eth0: enabling interface

Looks like something times out at 09:22:42 after running since 09:18:17…

Interesting tidbit, can you see what gets initialized after the wanrouter? :wink:

Things works after that and if I stop and then start them once the system is up they take nowhere that time… They perform flawlessly as far as I can see, it’s only that initial initialization that fails in this way…

Keep us posted and good luck and have a nice day!

Nick

Did you make progress on solving this? I am seeing this on one of my machines. It is running in a VMWare instance.

It is unlikely that you need wanrouter on a VMWARE machine (or any machine for that matter unless you have Sangoma hardware), you should

systemctl disable wanrouter

and try again.

Thanks.

This is more to do with this message than the wanrouter:

Hi!

I believe @waldrondigital had a similar problem with a VM install…

He had to change something on his virtual network card I believe…

Let me dig it up…

Good luck and have a nice day!

Nick

Found it…

Good luck and have a nice day!

Nick

1 Like

If you disable wanrouter then it is quite possible that you WILL have network connectivity, if

ip address

shows any spurious interfaces , and

ip route

shows a bad default and

cat /etc/resolve.conf

is nonsense , then you won’t have network connectivity to to named internet sites.

Thanks! Taking a look now, and will report back how it goes.

[quote]
shows any spurious interfaces[/quote]

Interesting…I think IPv6 is enabled…would that cause issues as well?

It shouldn’t but if you have only ipv4 then I suggest you disable it.

You are welcome!

Keep us posted!

Back when we upgraded (or tried to, I don’t know if @waldrondigital was able to ensuccessfully upgrade one of his installs) the two things that appeared to causes issues were VM related (like the network card) or DAHDI hardware that appeared as network cards…

(In my case, my Sangoma A200…)

I am pretty sure it’s active on mine and doesn’t cause problems (but then, things that don’t cause any problems for some end up causing problems for others) but I am not running this on a VM.

I do recall that someone reported this recently:

He was not talking of a total loss of network connectivity, only DNS problems (which would look like a loss of network connectivity), but that’s something to keep in mind…

Good luck and have a nice day!

Nick

If you have debian +8 or perhaps centos >= 7 then there is a chance that your eth devices are now ens devices if “virtualized” , check your

dmesg for that, if so then I would perhaps look at

https://access.redhat.com/solutions/2592561

If this specifies a UUID for the interface you may want to remove it. I had this issue too. The UUID had changed somehow during the process, perhaps due to the newer kernel.

Your udev rules might well impact the nameing of your network devices, I prefer the good old ethN (not ens or uuid :wink: ) usage both in udev and your network interfaces definitions, many older scripts just expect that the internet is available through /dev/eth0 , and there is no downside to reverting to that naming as far as I know. You might need to add some kernel options to grub if you want to do that though

https://access.redhat.com/discussions/916973

Hi!

I fixed my remaining DAHDI problem by doing this:

and this too (but it gets overwritten by the script I mention in the other post):

This was done at the suggestion of @dicko in that other thread…

Would it work in your case, possibly but possibly not… Network connectivity had been restored at that point on that system so it was not mandatory to do this (at least on my system) for it to be restored…

Good luck and have a nice day!

Nick

I got tired of gopher basing these errors. Just wiped clean, reinstalled and used restore to get most of my setting back. Worked pretty good too, except my MOH didn’t restore. No biggie.

All good now. Thanks, and sorry for not having the time to determine root cause.

I had to set this aside for a few weeks to work on another project; finally got back to it today.

I found the root cause of the internet connectivity issues to be that I had three DNS entries set; two were internal servers, and the last was external. My initial build on this server was a while ago, but it has been sitting powered off for a while. While the external DNS entry was still valid, the IP addresses for our internal DNS servers are now different. I suspect that pre-upgrade, the system was failing through to the third DNS entry, but mid-upgrade, it was not.

After manually updating resolv.conf with the correct entries, I was able to resolve DNS entries from the machine. I decided to attempt just rebooting the machine.

Things seemed to go reasonably well for a while; it made it through module upgrades and repairs, and then on to adding new modules.

It then hit a point where I received a rapidly repeating message: “error running fwconsole ma disable bria - file not found”

I ended up cancelling the script. It apparently didn’t get far enough to present me with a web GUI yet. Any thoughts on how to proceed?

I seem to be past that issue as well; I found a suggestion to essentially remove the schoozecom.conf and restart apache.

  • mv /etc/httpd/conf.d/schmoozecom.conf /etc/httpd/conf.d/schmoozecom.conf.bak
  • service httpd restart

I am not able to access the GUI.