Results 1 to 5 of 5

Thread: Wake-on-LAN, a working case

  1. #1
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    28,721

    Default Wake-on-LAN, a working case

    While this is labeled OTHER VERSION, it should be applicable to many versions and certainly those that use systemd.

    Wake-on-LAN, a working case

    Not long ago there was a question on the forum about getting Wake-on-LAN (WOL) functional. After this was solved, I implemented this in my own home network. Not long thereafter a new thread was started by another member about WOL and he could be helped with the same solution. While WOL is a subject with many aspects, these threads showed that a solution that worked for at least some of the cases in an opeSUSE environment might be helpful for others. So this is not an extensive article about WOL, but a practical solution that might fit your situation, or give you starting points for further study.

    What is Wake-on-LAN

    In short it is a way to "start" a computer by sending it something over the LAN (Local Area Network).
    See Wake-on-LAN.
    While the Wikipedia article mentions waking from other networks and waking over Wireless LAN, we restrict ourselves here to Ethernet LAN.

    You may see a need for WOL in an energy saving policy, to start systems when needed (to write a backup to, to use as file/print or other server, etc.)

    General

    We will call the computer to be woken up the "target" below.
    All commands shown below are to be done "as root".
    The program ethtool is used, it is normal installed at system installation, else install it, e.g.
    Code:
    # zypper in ethtool
    It has a long man page of which this is a quote:
    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.
    The type used in our examples is g (Wake on MagicPacket™) and this is the subject of this document.

    Hardware of the target

    The target must be connected to the LAN with an Ethernet cable in a Network Interface Card (NIC) and the NIC must be able to support WOL. To check that ability:
    Code:
    # ethtool eth0 | grep Wake
            Supports Wake-on: pumbg
            Wake-on: d
    #
    which shows which types are supported by the NIC and that at the moment it is disabled.
    (When your NIC has been given another name then eth0, use that one here and further down).
    It will be clear that when none of the types is supported, there is no WOL possible using this NIC.

    The fact that a NIC supports WOL does not imply that the system does so. When the NIC is detecting the MagicPacket™, it must signal the system in the same way as happens when one pushes the power switch. This requires a connection that may or may not be built in (I remember years ago that there was documentation on the internet how to add an extra electrical wire from the NIC to a point on the motherboard to achieve this). So check the system's manual or ask the seller/manufacturer. Or just try it.

    I have the idea that nowadays, with energy saving being an important issue, more desktop like systems will support WOL. I do not know about laptops and smaller devices.

    Last but not least, there must be some power available. The NIC must have some power to see the ethernet frames pass by, etc. When we look into the Advanced Configuration and Power Interface (ACPI), G3 (Mechanical Off) is a Nono, G2/S5 (Soft Off) should work. Some of the G1 (Sleeping) states might also works, as they also answer to pressing the Power button.

    Firmware of he target

    The firmware (BIOS) will most often have a possibility to switch WOL ON/OFF (the default being OFF). That depends of course much on the system and the BIOS used. In my system I found it under Hardware > Energy Management > Activate S4/S5 through LAN.

    Switching ON and testing

    When all the above can be satisfied the NIC must be "armed" with
    Code:
    # ethtool -s eth0 wol g
    For testing, bring the target in the power down state (shutdown) and send the MagicPacket™ from another partner on the LAN. When your target starts, you have passed the most difficult part .

    To make it persistent

    What was found out (and the main reason for people to ask for help on the forum) is that the "wol g" setting is not persistent. It must be repeated before the next shutdown. The solution we found was that it is best to do it right after boot (that is then in time for the next shutdown ). People still thought about doing something with rc.local, but that is old stuff. Using systemd, a systemd service was created:
    Code:
    # 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 it will be started at every boot:
    Code:
    # systemctl enable wol.service
    When you want to run it for a test:
    Code:
    # systemctl start wol.service
    When you want to see what happened:
    Code:
    # systemctl status wol.service
    And it worked happily ever after.

    =======================================================

    How to Wake from openSUSE

    Until now we did not explain much about the sender of the MagicPacket™. These can be manifold. Computers, other network devices, routers. Again this Howto will be restricted to openSUSE. Only one statement is needed:
    Code:
    # wol <MAC address>
    see:
    Code:
    $ man wol
    Thus you must know the MAC address of the target NIC. You can find the MAC address of a NIC with (on the target):
    Code:
    ip address
    It is after "link/ether" of the eth0 information and looks like ec:8e:b5:da:0d:0d.

    It depends of course very much on the need you have where this command is to be put. In a crontab, a backup script, ...... In any case, after the command is given there will be some time before the target is available, thus a testing loop (e.g. based on ping and sleep) might be needed.

    One case that was solved was the case to start the target as soon as possible after the system starts. At first sight it looks as if a simple systemd service as above will work. This turned out not to be the case. The timing not to send the MagicPacket™ before the network on the sending system was available was not easy. See Running Services After the Network is up.

    A working solution is:
    Code:
    # cat /etc/systemd/system/wake-boven.service
    [Unit]
    Description=Wake boven
    After=network-online.target
    Wants=network-online.target
    
    [Service]
    ExecStart=/usr/bin/wol ec:8e:b5:da:0d:0d
    
    Type=oneshot
    
    [Install]
    WantedBy=multi-user.target
    #
    But, read the above mentioned document, to let the "Wants=network-online.target" function there must be an active systemd network waiting function. It depends on the way you run your network. Two are mentioned in the document and both are found on my system (enable only one of them):
    Code:
    # enable NetworkManager-wait-online.service
    # enable systemd-networkd-wait-online.service
    I wonder about wicked?
    I use systemd-networkd, so I am happy enabling the second one.
    Last edited by hcvv; 27-Jan-2021 at 01:51.
    Henk van Velden

  2. #2
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    2,680
    Blog Entries
    1

    Default Re: Wake-on-LAN, a working case

    By default wicked waits 30 seconds for the interfaces:

    Datei: /etc/sysconfig/network/config
    Mögliche Werte: Beliebiger Ganzzahlenwert
    Standardwert: 30
    Beschreibung:

    Some interfaces need some time to come up or come asynchronously via hotplug.
    WAIT_FOR_INTERFACES is a global wait for all mandatory interfaces in
    seconds. If empty no wait occurs.

    BTW: systemctl status systemd-networkd-wait-online.service
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  3. #3
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    28,721

    Default Re: Wake-on-LAN, a working case

    Quote Originally Posted by karlmistelberger View Post
    By default wicked waits 30 seconds for the interfaces:

    Datei: /etc/sysconfig/network/config
    Mögliche Werte: Beliebiger Ganzzahlenwert
    Standardwert: 30
    Beschreibung:

    Some interfaces need some time to come up or come asynchronously via hotplug.
    WAIT_FOR_INTERFACES is a global wait for all mandatory interfaces in
    seconds. If empty no wait occurs.
    I assume that means that there is indeed no wicked-wait-online service, but that one has to wait for a fixed (configured after doing trial and error) amount of time. Not the most elegant solution.
    Quote Originally Posted by karlmistelberger View Post
    BTW: systemctl status systemd-networkd-wait-online.service
    Thanks for the correction. I edited the post.
    Henk van Velden

  4. #4
    Join Date
    Jan 2014
    Location
    Erlangen
    Posts
    2,680
    Blog Entries
    1

    Default Re: Wake-on-LAN, a working case

    Quote Originally Posted by hcvv View Post
    I assume that means that there is indeed no wicked-wait-online service, but that one has to wait for a fixed (configured after doing trial and error) amount of time. Not the most elegant solution.
    Indeed. However it's not a wait for a fixed time, but a wait for the links being ready with a timeout of WAIT_FOR_INTERFACES.

    Code:
    erlangen:~ # systemctl list-unit-files '*online*' 
    UNIT FILE                            STATE    VENDOR PRESET
    NetworkManager-wait-online.service   disabled disabled     
    systemd-networkd-wait-online.service enabled  disabled     
    network-online.target                static   -            
    
    3 unit files listed. 
    erlangen:~ #

    Another working case: Host erlangen has:
    Code:
    erlangen:~ # inxi -Mz 
    Machine:   Type: Desktop Mobo: ASRock model: Z170 Pro4S serial:<filter> UEFI: American Megatrends v: P3.50  
               date: 06/23/2016  
    erlangen:~ #
    Default configuration is:
    Code:
    erlangen:~ # ethtool enp0s31f6 | grep Wake                        
            Supports Wake-on: pumbg 
            Wake-on: g 
    erlangen:~ #
    With the above no action is required. wol would readily wake up erlangen from S3. Wake up from S5 was disabled in UEFI. Configured UEFI > Advanced > ACPI Configuration > PCIE Devices Power On = enabled. The system readily boots upon wol.
    AMD Athlon 4850e (2009), openSUSE 13.1, KDE 4, Intel i3-4130 (2014), i7-6700K (2016), i5-8250U (2018), AMD Ryzen 5 3400G (2020), openSUSE Tumbleweed, KDE Plasma 5

  5. #5
    Join Date
    Jun 2011
    Location
    Germany
    Posts
    338

    Default Re: Wake-on-LAN, a working case

    Thanks, Henk!

    I did read the initial thread just superficially. Your summary was really helpful. I initially thought WOL should work after enabling it in BIOS. It did with one machine per default so I thought that was the standard. Tried it with the new desktop but then abandoned it after failing gloriously.
    Now, ethtool showed me that WOL was disabled nevertheless. Your original suggestion worked out of the box for me with wicked, directly creating the wol.service file and enabling it.

    kasi

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •