netdev - Re: ethtool - LLDP Not staying Persistent

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>] [day] [month] [year] [list]

Message-ID: <20200710130251.gn6vprhwom7dgtnb@lion.mk-sys.cz>
Date:   Fri, 10 Jul 2020 15:02:51 +0200
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Jerko Begic <JerkoB@...ermicro.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ethtool - LLDP Not staying Persistent

On Thu, Jul 09, 2020 at 11:20:15PM +0000, Jerko Begic wrote:
> Hello,
> 
> Not sure if this is the best way to reach out to ethtool team in
> regards to the issues but I came across this
> site<https://mirrors.edge.kernel.org/pub/software/network/ethtool/>
> and wanted to check if you are aware of LLDP not staying persistent
> when turned off using ethtool? Originally, we have filed a case with
> Intel, but they have pointed us to reach out to ethtool team.
> 
> We have customers that keep contacting us about the LLDP not staying
> persistent when using our Networking cards (as an example AOC-MTG-i4S:
> https://www.supermicro.com/en/products/accessories/addon/AOC-MTG-i4S.php).
> We did some testing on our side with the card above and this
> MB<https://www.supermicro.com/en/products/motherboard/X11DPT-B> :
> 
> First we check that disable-fw-lldp is set to off by default
> ethtool --show-priv-flags <port#>
> 
> Then go ahead and disable LLDP on the FW with command:
> ethtool --set-priv-flags <port#> disable-fw-lldp on
> 
> Reboot the system and check:
> ethtool --show-priv-flags <port#>
> 
> LLDP is OFF (same as default) but we need it to be persistent after
> the reboot and to be ON
> 
> Please let me know if anyone can help with this case... We have tried
> on multiple ethtool versions and the results are the same :(

This is not something that could be addressed in ethtool alone, not even
by general ethtool code in kernel. Private flags, their meaning and
implementation are determined by network device and its drivers.

Private flags are a black box from ethtool point of view: driver reports
the list of available flags for a device and implements querying and
viewing them; ethtool only serves as an interface between user and the
driver but the implementation and properties, including the persistency.

In general, most settings are not persistent; if you want them to
persist through reboots, the usual way to achieve that is to have some
init script (or service) that will set them on each boot. Some
distributions allow setting such parameters in their config files, e.g.
in openSUSE or SLE it's ETHTOOL_OPTIONS in /etc/sysconfig/network/ifcfg-*

Hope this helps
Michal