netdev - Re: [PATCH net-next 1/2] ethtool: Introduce WAKE

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]

Date: Thu, 12 Oct 2023 14:45:42 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Michal Kubecek <mkubecek@...e.cz>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jonathan Corbet <corbet@....net>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>, opendmb@...il.com,
	justin.chen@...adcom.com
Subject: Re: [PATCH net-next 1/2] ethtool: Introduce WAKE_MDA

> I am having some second thoughts about this proposed interface as I can see
> a few limitations:
> 
> - we can only specify an exact destination MAC address to match, but the HW
> filter underneath is typically implemented using a match + mask so you can
> actually be selective about which bits you want to match on. In the use case
> that I have in mind we would actually want to match both multicast MAC
> destination addresses corresponding to mDNS over IPv4 or IPv6
> 
> - in case a MAC/PHY/switch supports multiple filters/slots we would not be
> able to address a specific slot in the matching logic
> 
> This sort of brings me back to the original proposal which allowed this:
> 
> https://lore.kernel.org/all/20230516231713.2882879-1-florian.fainelli@broadcom.com/

The Marvell PHY i just looked at supports upto 8 slots, and can match
up to the first 128 bytes of frame data. So it does seem like a more
generic and flexible interface would fit the hardware.

My previous concern was discoverability of the feature. Its not part
of ethtool -s eth0 wol. At minimum, i would suggest something in the
--help text in the wol section and man page pointing to the
alternative way to configure wol. And maybe report via the standard
wol flags that the hardware has the capability to use flow-type WoL?

The example you gave matched on Flow Type: Raw Ethernet. Is it
possible to combine flow types? If i can match on the first 128 bytes
of the frame i might want to go deeper into the frame, so want both
Ethernet and IP matching?

    Andrew