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