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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 27 Apr 2020 09:33:09 +0800
From:   Yi Zhao <yi.zhao@...driver.com>
To:     Michal Kubecek <mkubecek@...e.cz>, <netdev@...r.kernel.org>
CC:     <linville@...driver.com>
Subject: Re: ethtool -s always return 0 even for errors


On 4/23/20 9:36 PM, Michal Kubecek wrote:
> On Thu, Apr 23, 2020 at 05:45:47PM +0800, Yi Zhao wrote:
>> The ethtool -s returns 0 when it fails with an error (stderr):
>>
>> $ ethtool -s eth0 duplex full
>> Cannot advertise duplex full
>> $ echo $?
>> 0
>> $ ethtool -s eth0 speed 10
>> Cannot advertise speed 10
>> $ echo $?
>> 0
> These two are not really errors, just warnings. According to comments in
> the code, the idea was that requesting speed and/or duplex with
> autonegotiation enabled (either already enabled or requested to be
> enabled) and no explicit request for advertised modes (no "advertise"
> keyword), ethtool should enable exactly the modes (out of those
> supported by the device) which match requested speed and/or duplex
> value(s). The messages you see above are warnings that this logic is not
> implemented and all parameters are just passed to kernel and probably
> ignored (depends on the driver).
>
> Actually, with kernel 5.6 (with CONFIG_ETHTOOL_NETLINK=y) and ethtool
> built from git (or 5.6 once released), these commands work as expected:
>
> lion:/home/mike/work/git/ethtool # ./ethtool eth0
> Settings for eth0:
> ...
>          Advertised link modes:  10baseT/Half 10baseT/Full
>                                  100baseT/Half 100baseT/Full
>                                  1000baseT/Full
> ...
>          Auto-negotiation: on
> ...
> lion:/home/mike/work/git/ethtool # ./ethtool -s eth0 speed 100
> lion:/home/mike/work/git/ethtool # ./ethtool eth0
> Settings for eth0:
> ...
>          Advertised link modes:  100baseT/Half 100baseT/Full
> ...
> lion:/home/mike/work/git/ethtool # ./ethtool -s eth0 duplex full
> lion:/home/mike/work/git/ethtool # ./ethtool eth0
> Settings for eth0:
> ...
>          Advertised link modes:  10baseT/Full
>                                  100baseT/Full
>                                  1000baseT/Full
> ...
> lion:/home/mike/work/git/ethtool # ./ethtool -s eth0 speed 100 duplex full
> lion:/home/mike/work/git/ethtool # ./ethtool eth0
> Settings for eth0:
> ...
>          Advertised link modes:  100baseT/Full
> ...
>
>> $ ethtool -s eth1 duplex full
>> Cannot get current device settings: No such device
>>    not setting duplex
>> $ echo $?
>> 0
> The problem here is that for historical reasons, "ethtool -s" may issue
> up to three separate ioctl requests (or up to four netlink requests with
> new kernel and ethtool), depending on which parameters you request on
> command line. Each of them can either succeed or fail and you can even
> see multiple error messages:
>
> lion:/home/mike/work/git/ethtool # ethtool -s foo phyad 3 wol um msglvl 7
> Cannot get current device settings: No such device
>    not setting phy_address
> Cannot get current wake-on-lan settings: No such device
>    not setting wol
> Cannot get msglvl: No such device
>
> Currently, do_sset() always returns 0. While it certainly feels wrong to
> return 0 if all requests fail (including your case where there was only
> one request and it failed), it is much less obvious what should we
> return if some of the requests succeed and some fail.


Thank you for the detailed explanation.


//Yi

>
> Michal

Powered by blists - more mailing lists