netdev - Re: WoL broken in r8169.c since kernel 4.19

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190122161005.GA27062@torres.zugschlus.de>
Date:   Tue, 22 Jan 2019 17:10:05 +0100
From:   Marc Haber <mh+netdev@...schlus.de>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: WoL broken in r8169.c since kernel 4.19

On Sun, Jan 13, 2019 at 05:19:41PM +0100, Heiner Kallweit wrote:
> I assume you want to wake the system from S5 (poweroff).

No. The machine is almost never completely powered down.

> Does is wake from S3 (suspend-to-RAM) ? You can trigger this with
> "systemctl suspend".

That's what I am doing, with the behavior I reported: No reaction to
magic packet with the 4.20 driver, waking up from suspend to ram with a
current kernel with 4.18's r8169.c transplanted.

> Any difference if you enable WoL manually via ethtool "ethtool -s <if> wol g" ?

Would that make any difference if ethtool already says "Wake-on: g"? Why
would that make a difference with the 4.20 driver, but not with the
older one?

And yes, I remember this being one of the very first attempts after
noticing the issue, and I frankly would consider it at least a
regression if the 4.20 driver needs manual intervention while the 4.18
driver works fine with the appropriate setting in systemd-networkd
configuration.

Let me repeat, the issue does immediately vanish once I replace the
r8169 driver in the kernel with an older version, and re-establishes
itself immediately once I use a current driver version. No other parts
of the system or the network do not even get touched.

> And a basic question: Once you have powered off your system, is network
> LED on PC and router on?

When the system is in suspend, the manageable TP-Link 52 Port Gigabit
Switch reports the link on port 41 going down for a second and then
coming up again with 10 Mbit/s Full-Duplex. The Link LED on the system
board is _off_ in this case, even with the older driver and working Wake
on LAN. After receiving the magic packet, the system wakes up from
suspend to RAM, the link LED on the system board lights up again, the
switch reports the link going down again for a second and then
re-establishes as 1000 Mbit/s Full-Duplex.

The router's link to the same switch, different port, stays up with 1000
Mbit/s Full-Duplex, as expected, and frankly I do not see why the
totally unrelated network link between switch and router plays a role
here.

All those tests were done with Linux 4.20.3 with the driver from 4.18
transplanted and WoL working. I guess you want me to retry with the
broken driver?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421