I have been using FreePBX on a distro from 2022. According to dmesg, it is based on Red Hat 4.8.5. It is not working after a power failure in my building.
It is a networking problem. The machine has IP 192.168.1.40 and the gateway is at 192.168.1.1. It cannot ping 192.168.1.1. ip neighbor show returns
192.168.1.1 dev eth0 failed.
ifconfig shows eth0 is up
I did not change any of the configuration settings. When I take the cable plugged into the FreePBX machine and put it into another machine, it can ping 192.168.1.1, so there is apparently not a cabling or network problem.
also in /etc/sysconfig/network-scripts/
is there a route-eth0 file?
No, there is no route-eth0 file. If this is the problem, how do I fix it?
I’m wondering also if issue: route add default gw 192.168.1.1 eth0
No, this produces
SIOCADDRT: File exists
and I am still unable to ping 192.168.1.1.
If that gets you talking.
This command will not stay in place after issuing a network restart.
Thank you for your help.
If the issue is the missing route-eth0 file, how can I fix this?
Could it be a hardware issue, eg power surge after the outage (though the box is connected to a ups)? Ifconfig shows eth0 up but maybe the hardware is malfunctioning?
In relation to having the route file, I would say its not necessarily needed unless you are doing some fancy routing or static routes, or if the machine had ever been in an environment that had it.
I would say hardware failure is a possibility. I suppose the 101 of that would be to confirm a link light if you have one on the back of the machine, or check at the router/switch port.
Two other areas that come to mind is to see if you by chance have a macine that someone installed an alternate network manager on it:
One that I see commonly is Network Manager Text User Interface
in terminal run:nmtui
if that opens an graphical interface, though quite handy that program can compete with how the FreePBX distro wants networking managed.
The last thing coming to me at the moment is if your machine was by an chance cloned. Sometimes the NICs mac address will get messed with or a competing entry on the same interface is caused. I believe you would check: /etc/udev/rules.d/70-persistent-net.rules
Look and see if anything looks off in there Examples: 2 Devices assigned to Eth0, MAC not matching up with MAC in ifcfg-eth0 file, Device matching MAC but showing as assigned to another interface like eth1.