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

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

[Jan Huwald]

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

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
* add a custom broadcast TVLV; requires kernel code and either bloats
  OGMs are requires non-OGM broadcast TVLV packets

Don't work:
* using NFQUEUE on bcast payload (without batman header); does not work
  because they are not exposed to the iptables
* send link-local UDP on all enslaved interfaces; requires to
  reimplement all the loop-avoidance / routing / resending logic that
  already exists in batman-adv

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

With best regards,
Jan Huwald

[1] http://code.sotun.de/git/hbbp/
[2] http://code.sotun.de/git/wrt/p2ptbl/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Simon Wunderlich]

[-- 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 --]

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

[Jan Huwald]

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

Hi Simon,

thanks for your advice.


On 07/26/2013 02:16 PM, Simon Wunderlich wrote:
> * 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.

I had not considered the mcast rate issue. Given the typical low degree
topology that is probably the most efficient way to go. Even more so
given that bcast-packets are send several times. (I just discovered this
in the batman srcs.)


> alfred, which servers a similar purpose (at least i think so) does
> the same.

We had a look at alfred, but unfortunately it is no replacement for us.
But hopefully I can copy your neighbourhood discovery code :-)


Nitpicking part:

>> * 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.

By filtering with U32 and friends only packets that are scheduled for
local delievery anyway would be processed in userspace. That _should_
have only a minor performance impact. (And only be ugly^10.)

With best regards,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]