Is this a bug？

[ggsnpdsn]

console print MTU is small： [ 31.376438] batman_adv: bat0: No MLD Querier present - multicast optimizations disabled [ 32.175666] batman_adv: bat0: Adding interface: eth0-1_279 [ 32.181394] batman_adv: bat0: The MTU of interface eth0-1_279 is too small (1496) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. [ 32.206725] batman_adv: bat0: Interface activated: eth0-1_279 [ 32.256983] batman_adv: bat0: Adding interface: eth0_279 [ 32.262527] batman_adv: bat0: The MTU of interface eth0_279 is too small (1496) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. [ 32.287672] batman_adv: bat0: Interface activated: eth0_279 [ 32.543731] batman_adv: bat0: Adding interface: eth0-2_279 [ 32.549473] batman_adv: bat0: The MTU of interface eth0-2_279 is too small (1496) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem. [ 32.574698] batman_adv: bat0: Interface activated: eth0-2_279

[ilario]

There's some discussion on this here: https://github.com/libremesh/lime-packages/pull/703 The situation more or less is:

• normal ethernet ports have a maximum MTU of 1500
• most gigabit ethernet ports can have jumbo frames of larger MTU
• wireless can always have larger MTU

and

• Batman-adv wants to use a whole interface (I'm not sure here)
• so we create VLAN interfaces for giving to Batman.adv
  • originally, this was introduced for separating Batman clouds
  • nowadays Batman broadcast domains can be separated by internal Batman VLAN mechanism, see discussion here: https://github.com/libremesh/lime-packages/issues/581 but the Batman topology will be as large as the whole network, making useless the usage of two routing protocols (Batman-adv and Babeld). Maybe is already useless, as most of the community networks are too small to have an exaggeratedly large topology. And even in this case, we could release a firmware for the border with Babeld but without Batman (and maybe with firewall rules to kill its hello packets), practically cutting the Batman domain.
• the VLAN adds a 4 bytes overhead so that from 1500 just 1496 remains

In my opinion we should reduce all the MTU of all the wireless interfaces so that no package (received from the clients) will ever be larger than 1496. Now the MTU of wireless interfaces is set to 1536 so that the incoming packages will be 1532 I suppose? I'm not sure on this at all @g10h4ck @dangowrt Decreasing the MTU would cause Batman-adv complain more but should decrease fragmentation.

[ilario]

@spiccinini do you think the proposed "solution" (to decrease the MTU of the wireless interfaces) would decrease fragmentation and improve performances? Or would it just remove the warning message without actually doing any good? Can anyone test this in a virtual environment? @germanferrero

[spiccinini]

Probably @G10h4ck or @altergui knows bettter, I never analyzed the MTU thing in libremesh in detail and I surely will miss something

[altergui]

the MTU is already lowered down on clients to 1350, not all clients obey that directive but most do. the ones that don't, would also not obey a "hard" lower MTU on wireless interfaces. and a "hard" lower MTU on wireless interfaces breaks clients which can't do proper MTU discovery (very common on ipv4)

[altergui]

so, in a nutshell, even if "in theory" a lower mtu in router interfaces would be the "right" thing to do, in practice it creates hard to debug problems that are also impossible to fix (due to buggy code in clients). so we resorted to the current design.

[ilario]

Let's close this. It is really useful that this info is here, written for future reference.