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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 3 Feb 2016 10:19:04 +0100
From:	Nikolay Aleksandrov <>
To:	Nikolay Aleksandrov <>,
Subject: Re: [PATCH net-next v5 2/2] virtio_net: add ethtool support for set
 and get of settings

On 02/03/2016 04:04 AM, Nikolay Aleksandrov wrote:
> From: Nikolay Aleksandrov <>
> This patch allows the user to set and retrieve speed and duplex of the
> virtio_net device via ethtool. Having this functionality is very helpful
> for simulating different environments and also enables the virtio_net
> device to participate in operations where proper speed and duplex are
> required (e.g. currently bonding lacp mode requires full duplex). Custom
> speed and duplex are not allowed, the user-supplied settings are validated
> before applying.
> Example:
> $ ethtool eth1
> Settings for eth1:
> ...
> 	Speed: Unknown!
> 	Duplex: Unknown! (255)
> $ ethtool -s eth1 speed 1000 duplex full
> $ ethtool eth1
> Settings for eth1:
> ...
> 	Speed: 1000Mb/s
> 	Duplex: Full
> Based on a patch by Roopa Prabhu.
> Signed-off-by: Nikolay Aleksandrov <>
> ---
> v2: use the new ethtool speed/duplex validation functions and allow half
> duplex to be set
> v3: return error if the user tries to change anything besides speed/duplex
> as per Michael's comment
> We have to zero-out advertising as it gets set automatically by ethtool if
> setting speed and duplex together.
> v4: Set port type to PORT_OTHER
> v5: null diff1.port because we set cmd->port now and ethtool returns it in
> the set request, retested all cases

Hmm, nulling the advertising and ->port completely ignores them, i.e. won't produce
an error if the user actually specified a different value for either of them.
We can check if the ->port matches what we returned, but there's no fix for
advertising. I'm leaving both ignored for now, please let me know if you'd
prefer otherwise.


Powered by blists - more mailing lists