From: Jan Huwald <jh@sotun.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: [B.A.T.M.A.N.] Mangling broadcast packets
Date: Thu, 25 Jul 2013 23:12:54 +0200 [thread overview]
Message-ID: <51F194D6.3000701@sotun.de> (raw)
[-- 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 --]
next reply other threads:[~2013-07-25 21:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 21:12 Jan Huwald [this message]
2013-07-26 12:16 ` [B.A.T.M.A.N.] Mangling broadcast packets Simon Wunderlich
2013-07-27 12:14 ` Jan Huwald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F194D6.3000701@sotun.de \
--to=jh@sotun.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox