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: <78aaaa09-1b35-4ddb-8be8-b8f40cf280bc@lunn.ch>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ