netdev - Re: [PATCH] r8169: fix RTL8117 Wake-on-Lan in DASH mode

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]

Message-Id: <20251202.182328.1175792352280040166.rene@exactco.de>
Date: Tue, 02 Dec 2025 18:23:28 +0100 (CET)
From: René Rebe <rene@...ctco.de>
To: hkallweit1@...il.com
Cc: andrew@...n.ch, netdev@...r.kernel.org, nic_swsd@...ltek.com
Subject: Re: [PATCH] r8169: fix RTL8117 Wake-on-Lan in DASH mode

On Tue, 2 Dec 2025 18:04:18 +0100, Heiner Kallweit <hkallweit1@...il.com> wrote:

> On 12/2/2025 4:56 PM, René Rebe wrote:
> > On Tue, 2 Dec 2025 16:52:42 +0100, Andrew Lunn <andrew@...n.ch> wrote:
> > 
> >>> Well, the argument is for wakeup to “just work”. There also
> >>> should be some consistency in Linux. Either all drivers should
> >>> enable it or disable it by default. That is why I have thrown in
> >>> the idea of a new kconfig options for downstream distros to
> >>> make a conscious global choice. E.g. we would ship it it
> >>> enabled.
> >>
> >> You might need to separate out, what is Linux doing, and what is the
> >> bootloader doing before Linux takes over the machine.
> > 
> > By Grub2 boot loader is not enabling WoL.
> > 
> >> Linux drivers sometimes don't reset WoL back to nothing enabled. They
> >> just take over how the hardware was configured. So if the bootloader
> >> has enabled Magic packet, Linux might inherit that.
> >>
> >> I _think_ Linux enabling Magic packet by default does not
> >> happen. Which is why it would be good if you give links to 5 to 10
> >> drivers, from the over 200 in the kernel, which do enable WoL by
> >> default.
> > 
> > I'm sure supporting WoL requires active code in each driver. The next
> > time I have free time I'll go compile a list with grep for you.
> > 
> > Best,
> > 
> 
> How I see it:
> At least on consumer mainboards you have to enable WoL also in the BIOS,
> doing it just in Linux typically isn't sufficient. So it takes a user
> activity anyway. Common network managers allow to specify WoL as part
> of the interface configuration which is needed anyway, releasing users
> from the burden to use e.g. ethtool to configure WoL.
> And as stated before, WoL results in higher power consumption if system
> is suspended / shut down. What apparently is less of a concern for
> "professional-grade" NIC's, whilst basically every consumer system comes
> with Realtek NIC's (apart from few systems with Intel i225/i226).

I grepped the Linux kernel and quickly found drivers explicitly
enabling WoL usually unconditionally. Nothing to do with the BIOS.
Even the "professional" Intel drivers do it:

ixgbe:
       /* WOL not supported for all devices */
        adapter->wol = 0;
        hw->eeprom.ops.read(hw, 0x2c, &adapter->eeprom_cap);
        hw->wol_enabled = ixgbe_wol_supported(adapter, pdev->device,
                                                pdev->subsystem_device);
        if (hw->wol_enabled)
                adapter->wol = IXGBE_WUFC_MAG;

e1000:
        /* initialize the wol settings based on the eeprom settings */
        adapter->wol = adapter->eeprom_wol;
        device_set_wakeup_enable(&adapter->pdev->dev, adapter->wol);

tg3:
        /* Assume an onboard device and WOL capable by default.  */
        tg3_flag_set(tp, EEPROM_WRITE_PROT);
        tg3_flag_set(tp, WOL_CAP);
	...
                if (tp->phy_flags & TG3_PHYFLG_ANY_SERDES &&
                    !(nic_cfg & NIC_SRAM_DATA_CFG_FIBER_WOL))
                        tg3_flag_clear(tp, WOL_CAP);

Again, this is the only production board I have to enable it
explicitly. And I collected a lot, ... https://t2linux.com/hardware/

But I hear your argument. I suspend all our servers for energy
savings, too. All I say is it should be consistent. And as I
acknowledged from the beginning there might be different preferences,
I offered to make it a kconfig option to unify this default decission.

Happy to do such a patch if it helps and makes everyone happy.

I could also simply patch the realtek driver to enable it by default
for us in T2/Linux.

      René

-- 
René Rebe, ExactCODE GmbH, Berlin, Germany
https://exactco.de • https://t2linux.com • https://patreon.com/renerebe