Automate NIC Reconnect After Cable Unplug

Running Sangoma Core 7. Network will not reconnect after cable unplug and plugging back in.
From Console can bring connection backup with command: ifup eth0
What is line command to place in ifcg file to make this automatic?
I thought term hotplug or something of the sort might bring up answers, but alas no.
There is a distinct lack of online network configuration documentation, so I apologize in advance for posting a simple question of this sort.

So this link describes the problem access redhat com / solutions / 894763 [Forum bars people from putting links in posts]

Is NetworkManager supposed to be enabled on Freepbx? Will enable it break things? It is not enable on my box, but it is there to be enabled if doing so is fine.

I do lots of Suse networking. This is all unfamiliar territory. Incredibly poor design to not already permit link state to resume. Disrupts everything if switch, router, reboot (we typically automate reboot of router 1 time a week to clear memory etc.) Right now the PBx gui seems to manage networking in a half way sort of way thru simple ifcfg files.

This apparently requires a solution by those who create and distribute FreePBX as our tech support person states: “The issue here is the configuration in FreePBX and the Linux level OS not anything related to faulty hardware as its the software that has to bring back up the link when its plugged in. I know in the past the easy way to link a ETHX to a interface was by defining the Mac address in the ethX configuration but I know that has been changing in linux as of late. This is something your PBX installer/company would have to assist with as its a configuration issue/question with FreePBX and the OS.”

FreePBX is not involved with the network hardware, if you are referring to a FreePBX ‘distro’ then it will do basic network setups, plugging/unplugging a network cable should cause what linux considers a ‘hotplug’ event, check your hardware config files for the ‘auto-ness’ of HOTPLUG support which will almost certainly be ON.

Be aware that a network interface has levels of ‘connectedness’ and link-layer (layer 2) presence does not guarantee IP connectedness (layer 3)

So can we ask why you are plugging/unplugging network cables on an active server ?

Thanks. Not plugging/unplugging network cables in active server other than as a test. Real problem is if managed switch reboots and active pbx server loses connection with the managed switch, it will NOT reconnect on its own. [Pain in rear when remote working.] All other 40 plus devices connected to switch will reconnect. Not the PBX. On losing the switch only thing you can do is physically access console and restart network services. And no it is not the switch or cable as we have tested different cables and ports. And, all settings in hardware config files should permit a reconnect. It simply will not reconnect. At console before you restart network service you can give a [route -n command and it is missing all routing info it should have]. And yes, it will get a layer 2 level of connectedness, but will not regain layer 3 IP connectedness. Its as if all the auto back and forth between PBX and switch fails or does not occur.

Well, I don’t use ‘The Distro’ systems for FreePBX but “The Distro” DOES add a bit of somewhat secret sourced firewalling/IPtables setup that might get in the way of restoring full layer3 networking, have you tried restarting those bits?

I think the OP’s problem is that the problem is preventing his getting remote access, and local access requires a long journey. I think he says forcing the interface up locally does work.

Right. Forcing it up locally will work. But with the price of gas, it is a long costly journey to get into connect locally.

Well to save gas, I would continually test whether a well known network service is available and if it is not, them restart your networking service, something like

 while :; do if [[ ! $(nc -z 53) ]]; then  systemctl restart NetworkManager;sleep 30 ;fi ;done &
1 Like

That can be set up and will work as a stop gap measure. Alternatively, I have an old power switch [RPM1521E Minuteman] that will do the same thing that will ping a router and power cycle anything plugged into it if it cannot reach the destination after a set amount of time. - I think your suggestion is easier on equipment than power cycling.

And far more responsive, reloading/restarting NetworkManager takes less than a second, restarting the older ‘networking’ service still only a few seconds,

But I suggest you try to get to the bottom of what is preventing a proper reinstament of your network, Perhaps file a bug with Sangoma?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.