netdev - Re: wake-on-lan

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 17 Jul 2020 10:36:21 +0200
From:   "Michael J. Baars" <mjbaars1977.netdev@...erfiber.eu>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev@...r.kernel.org
Subject: Re: wake-on-lan

On Thu, 2020-07-16 at 18:09 +0200, Heiner Kallweit wrote:
> 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.
> 

I already suspected this. It's a work in progress. Programming the network nodes from a laptop in Paris will have to wait :)

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

Cheerz,
Mischa.