Re: [B.A.T.M.A.N.] Mangling broadcast packets

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

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

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

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