Reporting tap interface speed

[András Korn]

Hi,

currently openvpn seems to unconditionally report a connection speed of 10mbps for TAP devices.

In bonding setups with load-balancing, it would be beneficial to be able to configure the reported value. Can this be implemented at all?

[Gert Döring]

No idea. If it can be done, it would be an ifconfig / "ip link" setting - something inside Linux... one would need to figure out how link speed info works in general on Linux, and whether it can be set from userland, or only "from the hardware driver".

How do you query link speed from userland, anyway? "ifconfig" and "ip link" doesn't seem to tell me anything on my linux box...

[András Korn]

You can query the link speed using e.g. ethtool, which uses a SIOCETHTOOL ioctl.

See e.g. ​http://www.linuxjournal.com/article/6908.

[Gert Döring]

Thanks for the pointer to the linuxjournal article, which contained the magic phrase "documentation ... driver source code".

So, if you go to tun.c in the linux kernel, you find:

/* ethtool interface */
static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{

cmd->supported = 0;
cmd->advertising = 0;
ethtool_cmd_speed_set(cmd, SPEED_10);

... aka "a tun interface will report 10 Mbit/s, always, period".

So to be able to set the speed of the tun interface, you'd need to add a settable speed to the tun driver first, including the implementation of tun_set_settings() (or however drivers usually call it), as there is currently no "set parameters" capability in the tun driver at all (tun_ethtool_ops).

So, coming back to the ticket: we could add it to openvpn if there were a kernel mechanism to set and store the "virtual" link speed. But even then, since OpenVPN has no idea how fast the link really is, it would be easier to run this as part of an --up script.

So I claim it's not really feasible today, and close the ticket. But thanks for some interesting reading, learned something new today :-)

[András Korn]

OK, thanks for looking into this. I filed ​https://bugzilla.kernel.org/show_bug.cgi?id=68581 for whatever good it may do.