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
| ||
|
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