Hello Jan,

On Thu, Jul 25, 2013 at 11:12:54PM +0200, Jan Huwald wrote:

Hi,

I am currently redesigning hbbp and p2ptbl[1,2]. p2ptbl is a distributed key-value database build on top of HBBP link-local UDP broadcasts. Both are used in some Freifunk communities and elsewhere.

To reduce the bandwidth demand of the employed gossip protocol I would like to use something that behaves like a link-local broadcast packet in a batman-adv mesh every respect - except that any mesh node on it's route may decide to drop it or change it's UDP data.

Right now only approaches that are ugly or don't work come to my mind.

Ugly:

• using NFQUEUE on all enslaved interfaces to mangle packets before they are seen by batman; requires out-of-kernel parsing of batman-adv packets and watching enslaved interfaces

out-of-kernel parsing of batman-adv packets will kill you performance completely.

• add a custom broadcast TVLV; requires kernel code and either bloats OGMs are requires non-OGM broadcast TVLV packets

We will most probably not accept this upstream. User payload data should be sent within custom batman packets. You can have your private batman-patch though, but this leaves the maintainance burden to you.

Don't work:

• using NFQUEUE on bcast payload (without batman header); does not work because they are not exposed to the iptables

Plus batman-adv decides on it's own whether to forward broadcasts. Also modifying the content may break a few things (e.g. bridge loop avoidance), which do CRC on the broadcasts content.

• send link-local UDP on all enslaved interfaces; requires to reimplement all the loop-avoidance / routing / resending logic that already exists in batman-adv

At least this gives you the "only next hop" feature you wanted.

If you see a smarter way or a reason why manipulating broadcast packets is utter nonsene: please let me know.

Personally I think tinkering with batman-adv packets for this is not a good thing - and we will not support transporting this kind random user payload inside of batman-adv packets (unless it's our 'normal' Ethernet traffic). What you could do:

* send unicast to each neighbor instead of sending broadcast (find out who is a neighbor by reading originator tables) --> using unicast might be faster than using broadcast too, which is usually fixed to a lower mcast rate. alfred [1], which servers a similar purpose (at least i think so) does the same. * create a batman patch for private use * don't send so much stuff. :D

I think doing the unicast approach and sending only to neighbors or designated hosts is not too bad.

Cheers, Simon

[1] http://www.open-mesh.org/projects/open-mesh/wiki/2013-05-19-alfred-open-beta