Enable bridge multicast snooping

[T-X]

This would for one thing spare us a bunch of multicast packets with no listener in the mesh in general. Secondly, it'll spare us some more multicast packets to be broadcasted on the slow, 1MBit/s wifi AP interfaces.

To do:

• Update to recent barrier breaker (see & close: ebtables: misses MLD Queries #191)
• Enable bridge multicast snooping again (while leaving the broken multicast-to-unicast feature disabled)
• Increase "/sys/class/net/$br0/bridge/hash_max" (and maybe hash_elasticity, too? maybe hash_max = 2048 and hash_elasticity = 8?)

UPDATE: Strategy change: Instead of increasing hash_max, let's segment the IGMP/MLD broadcast domains with ip(6)tables: Filter IGMP/MLD packets from and to bat0 and set /sys/class/net/bat0/brport/multicast_router to 1.

The advantage of this is that we'd spare IGMP/MLD overhead over the VPN. And every node could/would run a querier on br-client, making multicast snooping work in a decentral way without relying on the gateways (where we'd have otherwise had to place the querier).

New ToDos:

• Fix multicast-to-unicast configuration in OpenWRT (e.g. enable ap-isolation + bridge-hairpinning). See: https://lists.openwrt.org/pipermail/openwrt-devel/2015-June/033398.html
• Implement filter rules (also set /proc/sys/net/bridge/bridge-nf-call-ip{6,}tables)
• Set multicast_router to 1 for bat0
• Reenable multicast-snooping, including querier

(Optional/later: Implement Multicast-Router-Discovery in the bridge and send MRD-RAs on AP interface and LAN-Ports to 100% support scenarios with multicast-snooping switches / multicast routers behind the LAN-Ports, too)

[neocturne]

I've submitted this patch for netifd: https://lists.openwrt.org/pipermail/openwrt-devel/2015-January/030864.html

[T-X]

Hm, is the intention to have the querier enabled on all nodes? That won't work nicely, otherwise there'd be one poor node chosen as the selected querier which would get taken down by multicast traffic. In my opinion the querier should be enabled on gateways only.

Instead it would be nice to have hash_max configurable and setting it to 8192. Each hash entry should take less than 100KB, so it'd take about 800KB max. I thought about hash_elasticity again and I think we can leave that one unchanged.

PS: Later, if batman-adv were forwarding IGMP/MLD reports to queriers (so to gateway(s)) only, these would be the only ones needing an increased hash_max.

EDIT: Actually the poor node wouldn't be taken down. It'd receive all the multicast traffic over the VPN right now, no matter if being the selected querier or not. But still I have a bad feeling about a small node with probably flacky connectivity becoming the selected querier for the whole mesh.

[neocturne]

@T-X, you didn't read the commit message correctly. My patch has the intention to allow exactly that: to enable multicast snooping while keeping the multicast querier disabled.

[T-X]

@NeoRaider: Aiy, thanks & sry!

[neocturne]

Well, my netifd patch has been accepted upstream, but...

As we're having bridge troubles on the WAN bridge which seem to be related to the multicast snooping in some way, @tcatm and I think it would be best to postpone enabling it on the client bridge until that is definitely sorted out (i.e. after Gluon 2015.1). @T-X, your opinion?

[T-X]

Yes, agreed. We should only enable such a feature once we are pretty sure it's stable enough. So issues like in #322 are a show-stopper and for now and need to be resolved first. So yes, let's move that to the 2015.2 milestone.

Btw. is there also a patch to increase the hash_max value via netifd yet? The default hash_max of 512 entries is too little for the number of clients we already have in our meshes. Like I said above, I'd suggest 8192 (and we can leave hash_elasticity as is).

[T-X]

Okay, update:

Got this patch ready for netifd: https://www.metameute.de/~tux/Freifunk/0001-bridge-allow-setting-hash_max-value.patch

Unfortunately, I figured out that it won't work yet :(. So I had to make this second patch for the Linux kernel which just got accepted and applied to the Linux net-next branch (so should get into Linux 4.2): https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=6ae4ae8e512bd229f806c22f8a2cd751e4f987c2

The patch in the kernel is fairly small and had been looked over and commented on by three other people on the netdev mailing list. What do you think, should we include it in the current experimental branch? I also couldn't quite decide on whether I should submit it to openwrt-devel for Chaos Calmer inclusion yet (- maybe I'll just ask on the openwrt-devel list directly soon).

[T-X]

And one more, new task for this feature request to get resolved:

Backporting the following fix which had just hit the Linux net branch (and is queued for stable kernels) to Chaos Calmer and Barrier Breaker: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=47cc84ce0c2fe75c99ea5963c4b5704dd78ead54

[neocturne]

@T-X, I think we should propose those patches for inclusion in the OpenWrt upstream, as we're currently in the lucky situation of tracking the OpenWrt trunk with Gluon.

[neocturne]

See also: https://bugzilla.kernel.org/show_bug.cgi?id=99081

[T-X]

New strategy, ticket description updated.

[T-X]

Update: Two pull-requests (#674, #675) for initial preparations. Adjusting the querier interval as proposed in #402 will have another pull-request once the according netifd patches got accepted ("[PATCH netifd] bridge: multicast: Export some parameters RFCs suggest to be tunable": https://lists.openwrt.org/pipermail/openwrt-devel/2016-March/040163.html).

Once all these are merged, I'd make the final pull-request to re-enable bridge multicast snooping again.

[rotanid]

update: everything has been merged already, only step missing is enabling via #688