On Fri, Oct 21, 2016 at 11:53:44AM +0800, Marek Lindner wrote:
Hi,
On Thursday, October 20, 2016 11:56:14 PM HKT Linus Lüssing wrote:
First of all, just wanted to forward this awesome diagram regarding MTUs in Gluon-Setups which Freifunk Hamburg created
:D : https://twitter.com/ohrensesselnet/status/789176399655350272
this link leads to a router pic ? Found the diagram you were (probably) referring to by searching in his/her tweetface history.
Urgh, I'm very, very sorry, yes, I ment this one instead :( :
https://twitter.com/ffhhnoc/status/787771192853798915
While checking the calculations Freifunk Hamburg did, I was wondering whether the batadv_hardif_min_mtu() function should add an extra 4 bytes for VLAN tagged, encapsulated payload to the MTU calculations and the kmesg recommendations
I am wondering whether we are trying to solve a problem that isn't a batman problem. You could have any number of encapsulation interfaces on top of bat0 (QinQ, GRE, etc) adding overhead. Do we reserve space for all these headers too ?
Hm, not quite sure whether it is 100% the same. While the problem is the same, for VLANs and GRE etc., in practice they behave a little different: When you have a network card with an MTU of 1500 bytes, then it usually works both with or without VLANs. And without fragmentation.
GRE or other tunneling protocols don't have that property. And I'm wondering whether we should try to preserve such VLAN properties.