[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200715133922.tu2ptsfeu25fnuwe@lion.mk-sys.cz>
Date: Wed, 15 Jul 2020 15:39:22 +0200
From: Michal Kubecek <mkubecek@...e.cz>
To: "Michael J. Baars" <mjbaars1977.netdev@...erfiber.eu>
Cc: netdev@...r.kernel.org
Subject: Re: wake-on-lan
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".
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.
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 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.
Michal
Powered by blists - more mailing lists