From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: [B.A.T.M.A.N.] [PATCH 0/1] batman-adv: Always flood IGMP/MLD reports
Date: Sun, 21 Jun 2015 15:36:16 +0200 [thread overview]
Message-ID: <1434893777-17618-1-git-send-email-linus.luessing@c0d3.blue> (raw)
The last round of multicast patches send to the batman-adv mailinglist
to add support for the multicast optimizations in bridged scenarios, too,
unfortunately had one major conceptual flaw: It could lead to packet loss.
It's not sufficient to have the unicasting of reports implemented on
bridge-nodes only. Nodes without bridges need to either unicast them, too
or as done with this patch flood them uncoditionally.
The issue is described in detail here:
https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-listener-reports
This patch substitutes and greatly simplifies the following patchset:
"batman-adv: Unicasting multicast reports to querier-node only"
The reason for doing this is, that I think the disadvantages of this
simpler approach noted in the wikipage above (e.g. report overhead in
large mesh networks) can be better compensated by segmenting the
IGMP/MLD domain via ebtables (drop all queries and reports coming out
of bat0 or before entering bat0) and the "multicast_router" bridge
port flag on bat0 (flood all multicast to this bat0 port, let
batman-adv deal with the optimizations from here on). Segmenting the
IGMP/MLD domain also has the nice advantage of being able to run a
querier on every mesh node which therefore is a way more decentral
approach.
Cheers, Linus
-----
Changelog
v1:
* Removed query snooping and state
* Squashed all three patches into one
* Renamed "batadv_mcast_tvlv_ogm_handler_v1()" to *_v2()
* Added explicit icmpv6.h include
* Rebased on top of master
Old changelog of
"batman-adv: Unicasting multicast reports to querier-node only"
v6:
* compat: copied copyright headers from original upstream c files
* compat: unified ordering in compat c files:
-> copyright header, then includes, then kernel specific functions
v5:
* Removed RFC tag: Needed exports got merged to net-next and are going to
be available with Linux 4.2
* Redid compat solution - now fully backwards compatible down to 2.6.33
v4:
* excluded bridge part from this patchset, they should
hopefully be added to net-next soon
* Added a compat solution (PATCH 3/3)
* Removed Kconfig-depends as by David's suggestion the needed parsing
functions for MLD are going to be forced built-ins even if IPv6 is
going to be built as a module
* Removed unused variable 'int ret' in batadv_mcast_is_report_ipv6()
* Adjusted to new folder structure
v3:
* Adding Kconfig-depends and #if's
(so basically adding similar dependancy constraints as the bridge code
has, except that there are no depends if batman-adv gets compiled without
multicast optimizations)
-> the case of IPv6=M and batman-adv=y is still impossible if multicast
optimizations are enabled; but I don't see the practical demand for that
either - people who use IPv6 as a module will probably also want to
use batman-adv as a module
v2:
* various bugfixes (now runtime tested, too - should(tm) work)
* added netdev+bridge mailinglists
next reply other threads:[~2015-06-21 13:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-21 13:36 Linus Lüssing [this message]
2015-06-21 13:36 ` [B.A.T.M.A.N.] [PATCH 1/1] batman-adv: Always flood IGMP/MLD reports Linus Lüssing
2015-06-26 12:43 ` Simon Wunderlich
2015-06-28 1:37 ` Marek Lindner
2015-06-28 3:59 ` Linus Lüssing
2015-06-28 13:21 ` Marek Lindner
2015-06-29 2:52 ` Linus Lüssing
2015-06-29 4:42 ` Linus Lüssing
2015-06-22 17:55 ` [B.A.T.M.A.N.] [PATCH 0/1] " Linus Lüssing
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=1434893777-17618-1-git-send-email-linus.luessing@c0d3.blue \
--to=linus.luessing@c0d3.blue \
--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;
as well as URLs for NNTP newsgroup(s).