gluon-ebtables-filter-multicast: relax IPv6 multicast firewall rules

[T-X]

Allow the transmission of IPv6 multicast packets as long as they are not flooded through the whole mesh.

This is achieved by adding a small "noflood mark" patch to batman-adv. With that multicast packets can be marked by iptables/ip6tables/ebtables as: "Please drop me, batman-adv, if I you'd flood me through the whole mesh."

That way it is now possible to send IPv6 packets with a link-local multicast if less than 16 nodes signed up for it (16 = batman-adv multicast fanout default).

This implements the remaining part of #1357.

[T-X]

Changelog compared to #1357:

• batman-adv:
  • removed the following patches because they were already merged upstream and are part of batman-adv v2019.2:
    • batman-adv: Avoid old nodes disabling multicast optimizations
    • batman-adv: Add multicast-to-unicast support for multiple targets
  • the "batman-adv: Introduce no noflood mark" patch was updated from sysfs to netlink and now reflects the version submitted for review here, "batctl noflood_mark" was added, as submitted here
• gluon-ebtables-filter-multicast:
  • clarified that the relaxation is for IPv6 multicast
  • removed batman-adv compat version check, as compat14 was removed in Gluon
  • Changed the marked IPv6 multicast address range from link-local IPv6 multicast to the full IPv6 multicast range: Routable IPv6 multicast address will still be dropped as before, as they are not supported in batman-adv v2019.2 yet. But once batman-adv is updated to >= v2019.3 they will then be supported automatically by Gluon
• gluon-mesh-batman-adv:
  • updated to set noflood_mark via netifd gluon_bat0 proto with batctl (instead of previously via /etc/config/batman-adv and sysfs, which is both deprecated now)

Edit: updated batman-adv noflood-mark link, was wrongly pointing to batctl, too.

[mweinelt]

the "batman-adv: Introduce no noflood mark" patch was updated from sysfs to netlink and now reflects the version submitted for review here, "batctl noflood_mark" was added, as submitted here

These versions were rejected, but I don't see the reasoning in patchwork. Does that mean we have to carry them downstream for the forseeable future?

[mweinelt]

I added this to the 2021.1 milestone, unless you want to push this back to 2021.2 because we just reenabled multicast optimiziations.

[T-X]

@mweinelt

These versions were rejected, but I don't see the reasoning in patchwork. Does that mean we have to carry them downstream for the forseeable future?

Sorry, had the wrong link for the batman-adv patch. Updated that. I think @ecsv felt it was a bit too specific for our setup. And would have preferred a solution outside of batman-adv. But I'm not quite sure how that could look like yet. For his "tc" suggestion I think there are some issues as described on the list / in patchwork.

I'm not 100% sure yet for which direction to go with upstream yet. We could add a more generic "disable broadcast flooding" patch to batman-adv, which would be easier to handle than packet marks. But then that would break respondd and alfred, which rely on flooding right now. On the other hand, there the workings of this patch a bit comparable to the "isolation mark" feature in batman-adv, so that could be a point in favor of getting it upstream in batman-adv. I'll need to talk a bit more about that with the other batman-adv developers.

Also the patch is really small and minimal invasive. So rebasing it would be no issue. And I currently like with this approach that in Gluon it only needs three lines to enable and use it.

I added this to the 2021.1 milestone

Sounds good to me. I think it'd actually be handy to have it in the same release as re-enabling multicast optimizations in batman-adv. If someone were running into issues with multicast they could then use multicast ICMPv6 echo requests to help with debugging.

[mweinelt]

Let's give this a shot.

[neocturne]

What's the upstream status of the noflood flag support? I'd really like to get rid of non-upstream patches in Gluon as far as possible.