internet network down after wake on lan

I have seen similar behavior on other proprietary linux based NAS systems if using DHCP for the IP address of the NAS. I believe it may be due to the DHCP lease expiring and the NIC is not requesting a lease renewal when waking from sleep, but will when the system boots or systemd-networkd is restarted.

You may be able to address the issue by setting a static IP and DNS server in the OMV GUI. I should note that I have not tried this myself as I don't use WOL on my system.

Sorry, it's not something I have encountered on my own OMV system, so I haven't done any further investigation. The idea only came from seeing a couple of commercial NAS systems owned by other people do the same kind of thing but I couldn't troubleshoot their systems

Quote from crashtest

Set a static DHCP lease, at your DHCP server.

I didn't suggest that as I had set up the couple of commercial NAS systems like that and it didn't help. The only fix was a reboot or an interface restart. both were linux based, but using custom/proprietary build so further troubleshoot was not an option.

The only thing I can think of is to get the system to restart systemd-networkd (ie down and up the interface) on wakeup, but I haven't looked to see how that could be scripted or even if it can.

A google search for "linux automatic systemd-networkd restart after wol" does return some ideas on how to get systems-networkd to restart automatically, but once again, I have never tried it.

If you want to look into it feel free, but I take no responsibility if things go sideways.

Quote from crashtest

It was a pot shot suggestion.

fair enough, so was my initial suggestion since I have never gone down the road of troubleshooting the problem.

I don't think its a suspend duration issue, I think it is just that the network stack needs to be re-initialized becuse it is not reliably re-establishing the connection after the wol packet brings the system up. Your restart of systemd-networkd pretty much proves that point.

once again if I were you I would look into this:

Quote from BernH

A google search for "linux automatic systemd-networkd restart after wol" does return some ideas on how to get systems-networkd to restart automatically, but once again, I have never tried it.

If you want to look into it feel free, but I take no responsibility if things go sideways.

In particular, I would investigate this section (networkd-dispatcher is not installed by default, so you will have to install it with apt-get install networkd-dispatcher first:

• Automatic Restart upon Network Changes (Optional):

  
  

  • While systemd-networkd typically handles network changes, if specific scenarios require a full restart (e.g., policy-based routing issues), consider using networkd-dispatcher or a custom udev rule to trigger a systemctl restart systemd-networkd command when the network interface state changes.

    
    

  • Example networkd-dispatcher script (e.g., /etc/networkd-dispatcher/routable.d/restart-networkd

    
    

Code

!/bin/sh
DEVICE=${1} STATE=${2}
if [ "$STATE" = "routable" ]; then
    systemctl restart systemd-networkd.service
fi

Make the script executable: sudo chmod +x /etc/networkd-dispatcher/routable.d/restart-networkd

Quote from neeqkowlah

ok for the solution but why the network stack needs to be re-initialized ? why does it not re-establishing the connection after the wol packet ?

I had not the problem in OMV 6

maybe if we know the cause, it will be possible to correct the problem without a script

I can't tell you why it needs a restart, I don't write systemd, I don't write drivers for your hardware, and I don't write the BIOS for your board. There are a lot of different layers that are not actually omv, and omv 6 vs omv 7 also use different debian versions under the hood (v11 vs v12), which, if I recall correctly, did change from netplan to systemd as the as the network management tool.

All I can offer is a potential work around for the problem. If you want the reason for the problem and a coded solution to the debian os that omv is sitting on top of (omv is not the OS or drivers, that is debian), you would have to report the issue to the debian project.

Quote from ryecoaaron

OMV 6 and 7 are both netplan using the networkd backend.

fair enough, there was a change at some point if I recall correctly, but I couldn't recall when that happened with debian.

Quote from ryecoaaron

Even OMV 5 used netplan with the systemd backend. There are been changes on the resolv.conf/systemd-resolved side and tweaks to the netplan file but nothing I can think of that would cause this issue. Debian itself did change from ifupdown to systemd-networkd with Debian 12 but OMV reconfigures networking and does not use the debian default. Debian desktops use network-manager.

Ah, perhaps that is the change I am remembering. It's hard to keep it straight in your head when you are administering debian, ubuntu, centos, and rocky systems of varying versions.