Arming NIC for WOL at boot fails

English Network/Internet
#1

I have written a How to for this that helped several people: https://forums.opensuse.org/showthread.php/549615-Wake-on-LAN-a-working-case
And now it does not work for me anymore :frowning:

Just upgraded from 15.2 to 15.3 using the online way. No big problems, but at boot I get a red message about my systemd service to set the NIC to act on WOL requests failed.

And indeed:

boven:~ # systemctl status wol
● wol.service - Wake-on-LAN
     Loaded: loaded (/etc/systemd/system/wol.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Thu 2021-12-09 11:27:19 CET; 26min ago
    Process: 484 ExecStart=/usr/sbin/ethtool -s eth0 wol g (code=exited, status=75)
   Main PID: 484 (code=exited, status=75)

Dec 09 11:27:19 boven systemd[1]: Starting Wake-on-LAN...
Dec 09 11:27:19 boven ethtool[484]: netlink error: no device matches name (offset 24)
Dec 09 11:27:19 boven ethtool[484]: netlink error: No such device
Dec 09 11:27:19 boven systemd[1]: wol.service: Main process exited, code=exited, status=75/TEMPFAIL
Dec 09 11:27:19 boven systemd[1]: wol.service: Failed with result 'exit-code'.
Dec 09 11:27:19 boven systemd[1]: Failed to start Wake-on-LAN.
boven:~ #

The service is:

boven:~ # 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
boven:~ #

There seems not to be a problem with the code above, because it works when done manually:

boven:~ # systemctl start wol
boven:~ # systemctl status wol
● wol.service - Wake-on-LAN
     Loaded: loaded (/etc/systemd/system/wol.service; enabled; vendor preset: disabled)
     Active: inactive (dead) since Thu 2021-12-09 12:05:06 CET; 4s ago
    Process: 5693 ExecStart=/usr/sbin/ethtool -s eth0 wol g (code=exited, status=0/SUCCESS)
   Main PID: 5693 (code=exited, status=0/SUCCESS)

Dec 09 12:05:06 boven systemd[1]: Starting Wake-on-LAN...
Dec 09 12:05:06 boven systemd[1]: wol.service: Succeeded.
Dec 09 12:05:06 boven systemd[1]: Finished Wake-on-LAN.
boven:~ #

So the first status tells us that ethtool errored with return code 75. Alas, the man page of ethtool does not provide any information about the return codes it may generate and their meaning.
I also read it as that eth0 is till not known at the moment that the service runs. Somehing changed to network.target?

It also strucks me that as far as I understand it, several people use this way of setting (after reading the How TO) were using 15.3 and/or Tumbleweed.

Any body any suggestions on where to get information about the error, or on the problem itself?

#2

To start with: I’m far from being an expert in this and i use openSUSE Tumbleweed. So all the following may be wrong and/or not apply to your system.

On my system the name “eth0” is created by an UDEV-rule (before that rule comes into action the interface does have a different name assigned to it by the kernel?). I have no idea at what point in the startup process this rule comes in to action.

However if your service is started before that rule was applied, your interface would have a different name (i.e. would not be found by the name “eth0”). But you would be able to run your service successfully when system startup has completed.

Regards

susejunky

#3

Thanks for your input.

What more or less denies your suggestion is that this worked here in 15.2 (and elsewhere in other versions) and that I assume (but all assumption may be just thin air of course) that when network.target is reached all naming is settled (or should have been).

I can add that I can re-create the error message:

boven:~ # /usr/sbin/ethtool -s FOOBAR wol g
netlink error: no device matches name (offset 24)
netlink error: No such device
boven:~ # echo $?
75
boven:~ #

which would confirm your idea that at that moment the device name is either different or not defined at all.

Also, I was amazed that the error during boot was displayed at the very beginning (I do not have Plymouth btw), where I expected this service to be run a bit later.

I will try to get some logging (have to find out how :wink: )

#4

Hm, this seems to confirm your idea:

boven:~ # journalctl  -b | grep wol
Dec 09 11:27:19 boven systemd[1]: wol.service: Main process exited, code=exited, status=75/TEMPFAIL
Dec 09 11:27:19 boven systemd[1]: wol.service: Failed with result 'exit-code'.
boven:~ # journalctl  -b | grep eth0
Dec 09 11:27:23 boven kernel: r8169 0000:01:00.0 eth0: RTL8168gu/8111gu, ec:8e:b5:da:0d:0d, XID 509, IRQ 127
Dec 09 11:27:23 boven kernel: r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
Dec 09 11:27:23 boven systemd-networkd[738]: eth0: IPv6 successfully enabled
Dec 09 11:27:23 boven systemd-networkd[738]: eth0: Link UP
Dec 09 11:27:23 boven kernel: r8169 0000:01:00.0 eth0: Link is Down
Dec 09 11:27:35 boven kernel: r8169 0000:01:00.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx
Dec 09 11:27:35 boven kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Dec 09 11:27:35 boven systemd-networkd[738]: eth0: Gained carrier
Dec 09 11:27:35 boven avahi-daemon[467]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.0.154.
Dec 09 11:27:35 boven avahi-daemon[467]: New relevant interface eth0.IPv4 for mDNS.
Dec 09 11:27:35 boven avahi-daemon[467]: Registering new address record for 10.0.0.154 on eth0.IPv4.
Dec 09 11:27:36 boven avahi-daemon[467]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::ee8e:b5ff:feda:d0d.
Dec 09 11:27:36 boven avahi-daemon[467]: New relevant interface eth0.IPv6 for mDNS.
Dec 09 11:27:36 boven systemd-networkd[738]: eth0: Gained IPv6LL
Dec 09 11:27:36 boven avahi-daemon[467]: Registering new address record for fe80::ee8e:b5ff:feda:d0d on eth0.*.
Dec 09 11:27:37 boven avahi-daemon[467]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::ee8e:b5ff:feda:d0d.
Dec 09 11:27:37 boven avahi-daemon[467]: Joining mDNS multicast group on interface eth0.IPv6 with address 2001:980:91a0:1:ee8e:b5ff:feda:d0d.
Dec 09 11:27:37 boven avahi-daemon[467]: Registering new address record for 2001:980:91a0:1:ee8e:b5ff:feda:d0d on eth0.*.
Dec 09 11:27:37 boven avahi-daemon[467]: Withdrawing address record for fe80::ee8e:b5ff:feda:d0d on eth0.
boven:~ #

The service runs on 11:27:19 and the first mentioning of eth0 is at 11:27:23.

#5

I re-read my own How To and the link mentioned there that is about “starting something after the network is available”.

What is recommended in that article is used in the second part of my How TO, where the WOL is send to the target (for which an available network is needed).

I now changed my arming of the NIC on the target to the same method:

boven:~ # cat /etc/systemd/system/wol.service 
[Unit]
Description=Wake-on-LAN 
#Requires=network.target
#After=network.target
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/sbin/ethtool -s eth0 wol g
Type=oneshot

[Install]
WantedBy=multi-user.target
boven:~ #

And one can see the differences. I also enabled the waiting service:

systemctl enable systemd-networkd-wait-online.service

as mentioned in the How To and the article.

Reboot!
The sesult is that it now “works” as intended.

boven:~ # systemctl status wol
● wol.service - Wake-on-LAN
     Loaded: loaded (/etc/systemd/system/wol.service; enabled; vendor preset: d>
     Active: inactive (dead) since Thu 2021-12-09 15:01:28 CET; 55s ago
    Process: 975 ExecStart=/usr/sbin/ethtool -s eth0 wol g (code=exited, status>
   Main PID: 975 (code=exited, status=0/SUCCESS)

Dec 09 15:01:28 boven systemd[1]: Starting Wake-on-LAN...
Dec 09 15:01:28 boven systemd[1]: wol.service: Succeeded.
Dec 09 15:01:28 boven systemd[1]: Finished Wake-on-LAN.
boven:~ # ethtool eth0 | grep Wake
        Supports Wake-on: pumbg
        Wake-on: g
boven:~ #

Recap.
While we do not need the network being “online”, we need the device name of the NIC being set. In openSUSE 15.2 this worked with the Unit file to be found in post #1 above. In 15.3 it didn’t. The solution is to postpone running of the service to network-online.

Remember that there is no “hurry” to run this service, it should only be done before system shutdown.

I will make amendments to the How To.

@susejunky, thanks for your input.

#6

You are always welcome!

As i said: I’m no expert in this. So for me to gain a better understanding of how things work i do have a question:

Will the old (15.2) version of your service work (in 15.3) as expected when you replace “eth0” by the device name originally set by the kernel?

Regards

susejunky

#7

I am not even sure there is such a thing as a name set by the kernel before the name as we see it is set. The kernel will have the hardware path to the device and things like type, manufacturer and that kind of information. In earlier days the kernel then gave it a device name to present it to the world. Nowadays it asks udev, giving it all that information, to give the name (and do more things if needed) and then uses it.

And I do not think that, whatever indication the kernel uses, can be used from a program (in fact in a library call to the kernel).

#8

Thanks for your explanation.

If i remove the UDEV-rule (from /etc/udev/rules.d) which sets the interface name to “eth0” the interface is called something like “enp0s3”. Is this name created by just another UDEV rule or are there any other system components involved?

Regards

susejunky

#9

That is the schema used to make “predictable device names”. Better “persistant” because they are very difficult to predict.
Goal is to have always the same name regardless of the detection sequence.

For disks, by using e.g. the UUID, that is nowadays rather accepted, but for NICs I am not so sure. openSUSE had it by default some versions ago, but AFAICS abandoned it.

But I think that is also done using udev. Thus another udev rule tuned in, using some algorithm to decide what a good persistent name is. See e.g. here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/ch-consistent_network_device_naming

#10

Thanks a lot for the link!

Regards

susejunky

#11

Hi
Add the following to grub kernel options for old names…


net.ifnames=0