Mangling broadcast packets
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/
Hello Jan,
Quoted 11 lines · Jan Huwald
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.
Quoted 6 lines
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.
Quoted 2 lines
* 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.
Quoted 4 lines
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.
Quoted 3 lines
* 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.
Quoted 3 lines
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
Hi Simon,
thanks for your advice.
Quoted 4 lines · Simon Wunderlich
* 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.)
Quoted 2 lines
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:
Quoted 6 lines
Quoted 3 lines
* 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