So, as my main OS is still windows, all works well when I shut down my rig from windows in terms of WOL - the NIC keeps at low-power state (or is re-started in such one after power off) - so I can boot the system via a WOL magic packet generated by a small SoC in my network.
As I was too lazy to reboot into windows I just shut down from linux. I didn’t noticed that the NIC was completely powered down until I came back from outside and expected my rig up and running as usual as I issued the WOL command when entered the housr 4 floors downstairs. As I opened my door I got surprised by my rig not powered up. I then checked the NIC LED - which were off completely.
Usually my router shows 10mbit/s half-duplex when the system is powered down - so I checked and it didn’t showed any connection at all - as if I would had pulled out the cable.
The NIC is an intel 82583V - at least that’s what shows up in windows device manager. I remember I had to fiddle around with the advanced power settings to get it working the way I have it currently set up.
So, my question goes this: Is it possible, that every time windows powers down to S5 the driver actively sets some low-power state - and linux just doesn’t and hence kills the NIC? If so - does anyone know a way to do the same on linux shutdown as the windows driver does?
I already checked a few things - and it seems not to matter what I set in the bios/uefi but actually what I set in the advanced power features in device manager. Like when I disable WOL it doesn’t work anymore - but when I enable the setting it works again. Of course, if I disable WOL in bios it doesn’t work no matter the setting.
Side note: My board manual actually explains, that for use WOL the specific driver setting in windows device manager has to be set. It doesn’t say anything about any other OS.
So, could it possible that the WOL feature of this NIC on this board is, like my fakeRAID, windows-specific? Did I really chose that bad of a board back then?
Hi
AFAIK, the operating system to last shutdown is the one that determines which controls WoL. Now, I would imagine if two NIC’s are available, use one for openSUSE and one for Windows may be an option?
Unfortunately I only have one NIC. But thanks for that info. I didn’t know that the WOL is actually controlled by the OS shutdown - always thought it’s some sort of lower-than-os/kernel-level set within the bios/uefi. But that makes sense that the setting within the bios/uefi only acts as kind of a “master switch” which controls if the NIC actually gets +5VSB at all or not - and then the OS shutting down triggers some driver event which causes the specific power state. mind blown +respect
I’ll try that next time and will report back. The explanation from malcolm and the linked thread makes sense that it has to be some power event while shut down.
On many systems this should be done before the system shuts down and is lost on next boot. Thus it must be set before each shutdown. In another thread this was solved by doing it on each boot (after all each shutdown is always preceded by a boot).
This is done by a systemd service. Create it by creating a service file in /etc/systemd/:
cat /etc/systemd/system/wol.service
[Unit]
Description=Wake-on-LAN
Requires=network.target
After=network.target
[Service]
ExecStart=/usr/sbin/ethtool -s eth0 wol g
Type=oneshot
[Install]
WantedBy=multi-user.target
To enable it (so that it starts on each boot):
systemctl enable wol.service
To run it now (because next boot is to late for the first shutdown to come):
systemctl start wol.service
The above is for WOL on g. When you use different then check what is uses in your shop.
To see what you NIC supports:
ethtool eth0 | grep Wake-on
When it is on d, it is switched off.
This is what
man ethtool
says
wol p|u|m|b|a|g|s|f|d…
Sets Wake-on-LAN options. Not all devices support this. The argument to this option is a string of characters specifying which options to enable.
p Wake on PHY activity
u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages
a Wake on ARP
g Wake on MagicPacket™
s Enable SecureOn™ password for MagicPacket™
f Wake on filter(s)
d Disable (wake on nothing). This option clears all previous options.
so choose what you need instead of g in my example above.
Just an impressive information. rep++
I’ll give it a shot this friday when I’m back in homeoffice.
Overall: nice to learn how WOL really works along solving that “issue”.
Just to clarify, if you mean the ethtool command that you were given, you need to know that is not persistent, hence the systemd unit that was suggested as part of the solution.
Just picking up from this thread as I need to be able to start using WoL I have some difficulty with starting the service on every boot.
I tried to set up the service I find:-
cat /etc/systemd/system/wol.service: No such file or directory.