On 22/01/14 07:04, Russell Senior wrote:
>>>>>> "Russell" == Russell Senior <russell@personaltelco.net> writes:
> 
>>>>>> "Antonio" == Antonio Quartulli <antonio@meshcoding.com> writes:
> Antonio> The current MTU computation always returns a value smaller
> Antonio> than 1500bytes even if the real interfaces have an MTU large
> Antonio> enough to compensate the batman-adv overhead.
> 
> Antonio> Fix the computation by properly returning the highest
> Antonio> admitted value.
> 
> Antonio> Signed-off-by: Antonio Quartulli <antonio@meshcoding.com> ---
> 
> Russell> This seems to fix the bat0-MTU-unnecessarily-small problem I
> Russell> observed last night and reported on the IRC channel.  I
> Russell> haven't actually passed any traffic over it yet, but the
> Russell> interface is up with the expected MTU value with the patch.
> 
> Antonio> This patch is missing a Reported-by clause because I did not
> Antonio> have "russell"'s email address at hand.
> 
> Russell> Reported-by: Russell Senior <russell@personaltelco.net>
> 
> Followup, as requested, I tried setting a smaller MTU (1400) on the
> adhoc0 interface.  When fragmentation was enabled, this resulted in no
> change to MTU (still 1500) for bat0.  When I disabled fragmentation,
> the bat0 MTU dropped, as expected, to 1368.  Interestingly, the MTU on
> the bridge that bat0 was a member of remained 1500 despite the lower
> bat0 MTU.  Should that be?
> 

I don't really know how the bridge code behaves. As far as I remember it
should adapt to the smallest MTU.

But thanks for testing! This shows that the patch is working fine ;)


-- 
Antonio Quartulli