Message-ID: <7d4c5243-8949-6617-781b-915eadd9fbf0@gmail.com>
Date:   Thu, 16 Jul 2020 18:09:02 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     "Michael J. Baars" <mjbaars1977.netdev@...erfiber.eu>,
        Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev@...r.kernel.org
Subject: Re: wake-on-lan

On 16.07.2020 09:28, Michael J. Baars wrote:
> On Wed, 2020-07-15 at 15:39 +0200, Michal Kubecek wrote:
>> On Wed, Jul 15, 2020 at 11:27:20AM +0200, Michael J. Baars wrote:
>>> Hi Michal,
>>>
>>> This is my network card:
>>>
>>> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
>>> 	Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
>>> 	Kernel driver in use: r8169
>>>
>>> On the Realtek website
>>> (
>>> https://www.realtek.com/en/products/communications-network-ics/item/rtl8168e
>>> )
>>> it says that both wake-on-lan and remote wake-on-lan are supported.
>>> I
>>> got the wake-on-lan from my local network working, but I have
>>> problems
>>> getting the remote wake-on-lan to work.
>>>
>>> When I set 'Wake-on' to 'g' and suspend my system, everything works
>>> fine (the router does lose the ip address assigned to the mac
>>> address
>>> of the system). I figured the SecureOn password is meant to forward
>>> magic packets to the correct machine when the router does not have
>>> an
>>> ip address assigned to a mac address, i.e. port-forwarding does not
>>> work.
>>>
>>> Ethtool 'Supports Wake-on' gives 'pumbg', and when I try to set
>>> 'Wake-on' to 's' I get:
>>>
>>> netlink error: cannot enable unsupported WoL mode (offset 36)
>>> netlink error: Invalid argument
>>>
>>> Does this mean that remote wake-on-lan is not supported (according
>>> to
>>> ethtool)?
>>
>> "MagicPacket" ('g') means that the NIC would wake on reception of
>> packet
>> containing specific pattern described e.g. here:
>>
>>   https://en.wikipedia.org/wiki/Wake-on-LAN#Magic_packet
>>
>> This is the most frequently used wake on LAN mode and, in my
>> experience,
>> what most people mean when they say "enable wake on LAN".
>>
> 
> Yes, about that. I've tried the 'system suspend' with 'ethtool -s 
> enp1s0' wol g' several times this morning. It isn't working as fine as
> I thought it was. The results are in the attachment, five columns for
> five reboots, ten rows for ten trials. As you can see, the wake-on-lan
> isn't working the first time after reboot. You can try for yourself, I
> run kernel 5.7.8.
> 
>> The "SecureOn(tm) mode" ('s') is an extension of this which seems to
>> be
>> supported only by a handful of drivers; it involves a "password" (48-
>> bit
>> value set by sopass parameter of ethtool) which is appended to the
>> MagicPacket.
>>
> 
> Funny, it looks more like a mac address to me than like a password :) 
> 
>> I'm not sure how is the remote wake-on-lan supposed to work but
>> technically you need to get _any_ packet with the "magic" pattern to
>> the
>> NIC.
> 
>>> I figured the SecureOn password is meant to forward magic packets
>>> to the correct machine when the router does not have an ip address
>>> assigned to a mac address, i.e. port-forwarding does not work.
> 
> Like this? We put it on the broadcast address?
> 
>>
>>> I also tried to set 'Wake-on' to 'b' and 'bg' but then the systems
>>> turns back on almost immediately for both settings.
>>
>> This is not surprising as enabling "b" should wake the system upon
>> reception of any broadcast which means e.g. any ARP request. Enabling
>> multiple modes wakes the system on a packet matching any of them.
>>
> 
> I think the "bg" was supposed to wake the system on a packet matching
> both of them. We want to wake up on a packet with the magic packet
> signature on the broadcast address,
> 
This needs to be supported by the hardware. And also r8168 vendor driver
doesn't support the signature mode, you can check the r8168 sources.

>> _any_ packet with the "magic" pattern
> 
>> Michal
> 
> 

Powered by blists - more mailing lists