I'm using an Ubuntu server 20.04 and I've set up the wake on lan. Everything is working fine when I shutdown the computer, I can wake it. But when I suspend it : impossible to wake it by the lan. Have anyone ever had this issue ? If someone have a solution, you're very welcome.
Thanks
The Wake-on-LAN feature is a hardware setting rather than something the OS controls, so it technically makes sense that the machine remains suspended when receiving the magic packet. That said, it can be quite bothersome for people who want their servers to wake and return to operation.
First, let’s confirm that the driver used for the network card supports WoL. Open a terminal and type:
sudo ethtool <interface>
Note: Be sure to replace <interface> with the name of your device. If you’re not sure what the name is, ip link show will provide the interface name.
The output should look something like this:
Settings for enp0s31f6:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Check the value of Wake-on contains a letter that is not d. If it does, this means to wake the machine, it needs to receive a "MagicPacket" rather than something else. There are several different options that the machine might be listening for. A complete list can be found in the documentation (search for the string Wake-on-LAN options).
If the value is d, this means the Wake-on value is disabled. If this is the case, you can enable it with this command:
sudo ethtool -s <interface> wol g
-s means "set", <interface> is the network interface, wol is "Wake on LAN", and g is "MagicPacket". You can choose other wake options as well, which are documented in the link above.
Unfortunately this command will need to be run every time your system boots, so be sure to add it to an appropriate startup script, such as part of the up rules in /etc/network/interfaces.
Hope this gives you the info you need to have your machines wake up from suspend.
It worked for me when I did:
sudo systemctl suspend
instead of:
systemctl suspend
The Wake-on-LAN feature is a hardware setting rather than something the OS controls.
No, it's not. It was, and ideally it should be, but modern suspend is definitely OS controlled. And it's very annoying.
I have been busting my brains over this the last days. I have got a new NUC 13 pro and WOL works fine in windows. But not in Ubuntu 23.10 or 24.04. It works fine when the machine is shutdown. In a shutdown state, control over the network adapter is managed by the BIOS and I can wake it up with WOL. Not so in suspend, which is OS, in case of Ubuntu, Networkmanager or systemd-networkd controlled. I can wake the NUC up from a suspended state with a wired or Bluetooth keyboard but not with WOL.
At first I thought the problem was a WD blue NVME drive that gave an error which caused the OS to default to simple suspend. I replaced the drive, the errors disappeared but still no WOL during suspend.
In 23.10 I had no problems setting persistent WOL on the ethernet adapter with ethtool and a startup script. In 24.04 however with every power cycle or suspend the WOL property got reset. The only way to set persistent WOL is not on the adapter but on the connection via nmcli (Networkmanager). Idk about networkd in Server, might be different. Most tutorials and the man pages don't mention this.
In the end I figured out that the underlying cause with suspend and WOL is the OS putting Networkmanager to sleep and thereby killing the ethernet connection. I imagine the same is happening with networkd on Ubuntu server. I could observe this in the logs. Networkmanager kept the ethernet connection alive with sudo systemctl suspend and then Networkmanager itself went asleep. Coming out of suspension Networkmanager came out of sleep and then turned on the ethernet adapter that was unmanaged and asleep (but was never put to sleep by Networkmanager itself). It's not the BIOS because WOL from shutdown works fine. So it must be either Networkmanager going to sleep or another service shutting the Ethernet connection.
TLdr; Modern suspend puts the machine in OS controlled s0 instead of BIOS controlled s3. The OS puts Networkmanager and the ethernet adapter to sleep instead of handing control over the ethernet adapter to the BIOS. It's a step back in functionality. You could try to force to suspend to s3 via GRUB, that might work or maybe set WOL via networkd instead of (or next to) ethtool.
Wol works when the os tells the NIC when powering down to listen for magic packets which makes the NIC stays at low power mode to listen to magic packets and when we are suspending the server the os instead of telling NIC to stay on it is making the NIC to power down which is causing the wol to not work we need to make nic stay on after the suspend command.
