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