On Saturday, 8 September 2018 19:38:01 CET Sven Eckelmann wrote: [... explanation why this test could create problems for other wifi connections...]
Is there anything which I missed that could ease my mind?
Beside this potential problem, there is also the problem of the interaction with the ethtool throughput gathering (brought up by Matthias Schiffer [1] and Matthias Fritzsche [2]). The ethtool code basically prevents the correct measurement in many situations. I will try to summarize it now:
* ethtool's link_ksettings is not about speed towards a neighbor behind the interface but about either
- PHY layer speed class from local ethernet port to next peer (for direct connections) - connection towards next (internal) switch - propagated value from a lower layer device (e.g for vxlan) - "random" value (e.g. tun/tap) - ...
* often connections indirect (switches, VPN, WiFi bridges, L2 firewalls, ...) * B.A.T.M.A.N. V requires a measurement for the throughput towards a neighbor and not the maximum(?) PHY layer speed of the first hop over the current medium
The proposed solution is to drop the ethtool link_ksettings usage when the tpmeter (or similar) approach for neighbor speed measurements is integrated.
Kind regards, Sven
[1] https://github.com/freifunk-gluon/gluon/pull/1872#issuecomment-55767698 [2] https://patchwork.open-mesh.org/patch/17371/#31059