lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 15 Jul 2020 15:39:22 +0200
From:   Michal Kubecek <>
To:     "Michael J. Baars" <>
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
> (
> 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:

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

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

> 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.


Powered by blists - more mailing lists