netdev - Re: ethtool 5.7: netlink ENOENT error when setting WOL

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: <0353ce74-ffc6-4d40-bf0f-d2a7ad640b30@gmail.com>
Date:   Wed, 10 Jun 2020 08:27:10 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Heiner Kallweit <hkallweit1@...il.com>,
        Michal Kubecek <mkubecek@...e.cz>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ethtool 5.7: netlink ENOENT error when setting WOL



On 6/10/2020 3:50 AM, Heiner Kallweit wrote:
> On 10.06.2020 11:13, Michal Kubecek wrote:
>> On Wed, Jun 10, 2020 at 10:52:26AM +0200, Heiner Kallweit wrote:
>>> On 10.06.2020 10:26, Heiner Kallweit wrote:
>>>> Since ethtool 5.7 following happens (kernel is latest linux-next):
>>>>
>>>> ethtool -s enp3s0 wol g
>>>> netlink error: No such file or directory
>>>>
>>>> With ethtool 5.6 this doesn't happen. I also checked the latest ethtool
>>>> git version (5.7 + some fixes), error still occurs.
>>>>
>>>> Heiner
>>>>
>>> Bisecting points to:
>>> netlink: show netlink error even without extack
>>
>> Just to make sure you are hitting the same problem I'm just looking at,
>> please check if
>>
>> - your kernel is built with ETHTOOL_NETLINK=n
> 
> No, because I have PHYLIB=m.
> Not sure what it would take to allow building ethtool netlink support
> as a module. But that's just on a side note.

Not sure it makes sense to build ETHTOOL_NETLINK as a module, but at
least ensuring that ETHTOOL_NETLINK is built into the kernel if PHYLIB=y
or PHYLIB=m would make sense, or, better we find a way to decouple the
two by using function pointers from the phy_driver directly that way
there is no symbol dependency (but reference counting has to work).
-- 
Florian