On 16.07.2013, at 23:41, Max Krasnyansky <maxk@qti.qualcomm.com> wrote:
> The patch looks fine to me (must admit that I only glanced at it). Please send it to the netdev
> mailing list netdev@vger.kernel.org, if you have't already done so.
> CC David Miller <davem@davemloft.net> and me.

Doing that. Now summarizing the issue for the new recipients:

Problem:

When querying a tap device for its speed using ethtool the tun driver reports a speed
of SPEED_10. This number is hard coded into the driver. Nowadays virtual network devices
can go way faster than that. When doing automatic bandwidth monitoring based on the
speed reported by ethtool, tap devices tend to come up as false positives. Arguably the
hard coded speed is wrong.

Proposed solution:

To that end I propose supporting the ETHTOOL_SSET command in addition to the already
supported ETHTOOL_GSET. It would deny setting any setting except for the bandwidth
where it would allow arbitrary values. You can find this patch attached.

With this patch an administrator can increase the reported speed for tap devices and
keep using automatic detection of interface speeds.

Workarounds:

Using ethtool a detection utility can determine the driver for an interface. If the
driver matches the string "tun", the reported speed should not be used.

Helmut