On Wednesday 11 November 2009 11:17:22 Donald Gordon wrote:
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?
If you look for simple interfaces then just dive into the bat0 code - it is exactly that. But at that point I doubt you would need yet another interface to achieve your goal. If you wanted your fragmentation happening at each beginning and ending of the mesh you easily could do that inside of the batman-adv code. The data will go in and out via bat0 ...
Besides, I'm not sure your approach will make everyone happy as you might have different MTUs throughout the network (e.g. see you batman over IP suggestion). The endpoints might have a higher MTU than a segment inbetween. In that case the fragmentation could not help.
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 :-)
Well, if static tunneling solves the problem you easily could use GRE or similar techniques.
Regards, Marek