netdev - RE: [PATCH net 3/3] net: lan743x: Address problems with wake option flags configuration sequences

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: <LV8PR11MB8700C2F9461F4200431446D49F5F2@LV8PR11MB8700.namprd11.prod.outlook.com>
Date: Thu, 29 Feb 2024 08:59:20 +0000
From: <Raju.Lakkaraju@...rochip.com>
To: <andrew@...n.ch>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>, <kuba@...nel.org>,
	<linux-kernel@...r.kernel.org>, <Bryan.Whitehead@...rochip.com>,
	<richardcochran@...il.com>, <UNGLinuxDriver@...rochip.com>
Subject: RE: [PATCH net 3/3] net: lan743x: Address problems with wake option
 flags configuration sequences

Hi Andrew,

Thank you for review comments.

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Tuesday, February 27, 2024 7:28 AM
> To: Raju Lakkaraju - I30499 <Raju.Lakkaraju@...rochip.com>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; kuba@...nel.org; linux-
> kernel@...r.kernel.org; Bryan Whitehead - C21958
> <Bryan.Whitehead@...rochip.com>; richardcochran@...il.com;
> UNGLinuxDriver <UNGLinuxDriver@...rochip.com>
> Subject: Re: [PATCH net 3/3] net: lan743x: Address problems with wake option
> flags configuration sequences
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> On Mon, Feb 26, 2024 at 01:39:34PM +0530, Raju Lakkaraju wrote:
> > Wake options handling has been reworked as follows:
> > a. We only enable secure on magic packet when both secure and magic wol
> >    options are requested together.
> > b. If secure-on magic packet had been previously enabled, and a
> subsequent
> >    command does not include it, we add it. This was done to workaround a
> >    problem with the 'pm-suspend' application which is unaware of secure-on
> >    magic packet being enabled and can unintentionally disable it prior to
> >    putting the system into suspend.
> 
> This seems to be in a bit of a grey area. But ethtool says:
> 
>            wol p|u|m|b|a|g|s|f|d...
>                   Sets  Wake-on-LAN  options.   Not  all devices support this.
>                   The argument to this option is a string of characters speci‐
>                   fying which options to enable.
>                   p   Wake on PHY activity
>                   u   Wake on unicast messages
>                   m   Wake on multicast messages
>                   b   Wake on broadcast messages
>                   a   Wake on ARP
>                   g   Wake on MagicPacket™
>                   s   Enable SecureOn™ password for MagicPacket™
>                   f   Wake on filter(s)
>                   d   Disable (wake on  nothing).   This  option
>                       clears all previous options.
> 
> d clears everything. All other things enable one option. There does not
> appear to be a way to disable a single option, and i would say, adding options
> is incremental.
> 

Yes. "d" clears everything.
But, if we enable "g" then enable "a", "g" option overwritten by "a"
Please find the attached log information 
> So:
> 
> > a. We only enable secure on magic packet when both secure and magic wol
> >    options are requested together.
> 
> I don't think they need to be requested together. I think you can first enable
> Wake on MagicPacket and then in a second call to ethtool Enable SecureOn
> password for MagicPacket. I also don't think it would unreasonable to accept
> Enable SecureOn password for MagicPacket and have that imply Wake on
> MagicPacket.
> 

If we need to enable any 2 options, we have to provide both options together.
i.e.
sudo ethtool -s enp9s0 wol ga

> And:
> 
> > b. If secure-on magic packet had been previously enabled, and a
> subsequent
> >    command does not include it, we add it.
> 
> If there has not been a d, secure-on magic packet should remain enabled until
> there is a d.
> 

This is not happened with existing "Ethtool".
Please find the log information in an attachment file.

>         Andrew

Thanks,
Raju

View attachment "ethtool_wol_op_log.txt" of type "text/plain" (10834 bytes)