Re: [B.A.T.M.A.N.] BATMAN-Adv and MTU handling

[Marek Lindner <lindner_marek@yahoo.de>]

On Thursday 12 November 2009 08:51:49 Linus Lüssing wrote:
> Ah, wait, I forgot one thing: It worked for our hotspots because
> the coovachili internet gateway had an MTU equal to the PMTU all
> the way through the mesh. But you are right, we are probably
> having some trouble when having too mesh clients which are bridged
> to each other and have an MTU set to 1500...

Ok, then we are on the same page.  :)


> I'm wondering what you think of how tinc is handling this at the
> moment in switch mode: It just "fakes" an ICMPv4/6 message with
> the address of the destination if such a hop is getting an
> IP-packet bigger than the link MTU. This might sound like a good
> idea at first sight, but the disadvantage is, that you're getting
> trouble in IPSec-only networks (which are quite rare at the
> moment, yes :) ).

This sounds rather hacky - I can think of more scenarios in which that 
approach will fail (encryption being one of them). The compression idea Andrew 
was talking about sounds much more promissing.


> Nope, tinc is able to create a TUN (router mode) and TAP (switch
> mode) network adapter, so it is able to actually transport the
> original ethernet frame as well:
> [ETHER][IP][UDP/TCP][ETHER][BATMAN-HDR][PAYLOAD]

That is besides the point.
Tinc is able to let the kernel handle the fragmentation because it forwards 
packets on layer 3 and not on layer 2 (even if it can encapsulate layer 2 
packets). Batman-adv forwards on layer 2 ...

Regards,
Marek