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

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Hey,

On Tue, Nov 10, 2009 at 06:34:41PM +0800, Marek Lindner wrote:
> > The motivation of using a higher MTU of 1524 at the beginning was
> > the rumour, that there might be some client devices (which we
> > would get into the network by bridging bat0 wifi wlan0 for
> > instance) not able to handle any MTU smaller than 1500. But in
> > fact it turned out, that in our days basically all devices are
> > able to do both IPv4 and IPv6 PMTU discovery on layer 3. So tests
> > showed, that if all BATMAN nodes are using an MTU of 1476 on bat0
> > (or the overlaying bridge) everything seems to work fine.
> 
> Sorry, I can't follow you here. If the whole network is a switch environment 
> how could the clients perform a working PMTU ? Sure, all clients are able to 
> do PMTU (I don't think somebody doubted that) but it won't work.  :)
> Client sends 1500 bytes -> router receives the frame (no IP!) and drops the 
> packet. Where should the "fragmentation needed" packet come from ? That only 
> works if you route packets instead of switching them.
> 

Maybe most clients support that, but consider the way back. E.g. in TU-Chemnitz
and many other corporate or university network firewalls, ICMP messages 
including PMTU packets are blocked. This means Wifi client A may send correctly 
the smaller packets to server B, but B might send a big packet back as
the PMTU messages are blocked at the firwall and then get dropped in the 
mesh network.

This might be considered as problem of the servers network firewall, but 
unfortunately things like these exist. There are also misconfigured desktop 
firewalls which block ICMP packets. Its more a question of configuration than
support.

regards,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]