One implementation possibility I was thinking of was adding yet another ethernet device that sat like a proxy in front of bat0. It would fragment transmitted frames larger than the bat0 MTU (changing the ethernet frame type), and reassemble recieved frames. This would push the load of frame fragmentation to the edge of the network, and shouldn't add too much overhead. Does that sound like a reasonable way forward? And if so, does anyone have any pointers on how to develop fake ethernet drivers?
With the frame-combining that batman-adv now does, those extra frame fragments would be good candidates for combining to cut down on wifi overhead.
With resepect to the motivation for allowing 1500 MTU frames over a 1500 MTU intermediate network, I guess my grand vision is to borrow bits of network that are already there to get the mesh extended further. Hopping through a citywide hotspot network (conveniently all bridged together), borrowing existing ethernet segments in buildings, that sort of thing. Which means I'm also keen on some sort of integrated way to tunnel batman packets over IP without the overhead of passing them to userspace through a tun/tap but I guess that'll have to wait :-)
donald
On Tue, Nov 10, 2009 at 3:39 AM, Marek Lindner lindner_marek@yahoo.dewrote:
Nevertheless, it might be neat to have fragmentation as a fallback mechanism. Be sure we review and submit your code as soon as it is available. :)
Regards, Marek