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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Apr 2020 21:40:14 +0200
From:   Michal Kubecek <>
Cc:     Konstantin Kharlamov <>,
Subject: Re: (repost for 2020y) inconsistency of ethtool feature names for
 get vs. set

On Wed, Apr 08, 2020 at 04:07:39PM +0300, Konstantin Kharlamov wrote:
> I noticed some inconsistency of feature names with the ethtool getting/setting of features mechanics -- the name of the feature you need to set (through -K) isn't what displayed by the get (-k) directive, here's an example:
> $ ethtool -k eth1  | grep generic-receive-offload
> generic-receive-offload: on
> $ ethtool -K eth1  generic-receive-offload off
> ethtool: bad command line argument(s)
> For more information run ethtool -h
> --> looking in the sources and realizing I need to use "rx-gro"
> $ ethtool -K eth1  rx-gro on
> $ethtool -k eth1  | grep generic-receive-offload
> generic-receive-offload: on
> same problem for rx checksum which is displayed as "rx-checksumming" by the get (-k)
> but need to be "rx-checksum" for the set (-K) directive.

This is actually going to work with netlink implementation in kernel
5.7-rc1 (or current mainline) and corresponding userspace patchset I'm
going to submit after ethtool 5.6 is released:

  lion:~ # ~mike/work/git/ethtool/ethtool -k dummy0 | grep generic-receive-offload
  generic-receive-offload: on
  lion:~ # ~mike/work/git/ethtool/ethtool -K dummy0 generic-receive-offload off
  Actual changes:
  rx-gro: off
  lion:~ # ~mike/work/git/ethtool/ethtool -k dummy0 | grep generic-receive-offload
  generic-receive-offload: off

(The "rx-gro" in "Actual changes" section which probably comes from
using a dump function in ioctl code. I'll look into it.)

But independent of that, the ioctl code path should also accept actual
feature names provided by kernel. I'll try to find where the problem is
and fix it.

Michal Kubecek

Powered by blists - more mailing lists