kernel: bridge: Implement MLD Querier wake-up calls / Android bug workaround

[T-X]

Implement a configurable MLD Querier wake-up calls "feature" which
works around a widely spread Android bug in connection with IGMP/MLD
snooping.

Currently there are mobile devices (e.g. Android) which are not able
to receive and respond to MLD Queries reliably because the Wifi driver
filters a lot of ICMPv6 when the device is asleep - including
MLD. This in turn breaks IPv6 communication when MLD Snooping is
enabled. However there is one ICMPv6 type which is allowed to pass and
which can be used to wake up the mobile device: ICMPv6 Echo Requests.

If this bridge is the selected MLD Querier then setting
"multicast_wakeupcall" to a number n greater than 0 will send n
ICMPv6 Echo Requests to each host behind this port to wake
them up with each MLD Query. Upon receiving a matching ICMPv6 Echo
Reply an MLD Query with a unicast ethernet destination will be sent
to the specific host(s).

Link: https://issuetracker.google.com/issues/149630944
Link: #1832

Signed-off-by: Linus Lüssing <[email protected]>

[rotanid]

thanks. i've added some labels, including the "blocked" label which stays until this has been merged upstream, as we don't like to carry patches "forever" as you know

[rotanid]

@T-X have you submitted the patches upstream, maybe you can put the links in the initial text?
at least in the google thread i can't find the patches, i did not search in Linux Kernel patchwork...

[T-X]

Changelog v2:

• rebased to master
• fixed the ICMPv6 header check, was a no-op due to a typo ("if (ipv6_mc_check_icmpv6 < 0)" vs. "if (ipv6_mc_check_icmpv6(skb) < 0)" ) in br_multicast_wakeupcall_check()

[T-X]

@rotanid I've submitted the patch to the Linux kernel mailing lists as an RFC here, but no one was really happy about it.

And I couldn't really spot an alternative suggestion which everyone would be happy about either.

So not sure if that means we'd have to deal with this issue on our own for now. Or if I should retry submitting that Linux bridge patch to OpenWrt later.

[rotanid]

@T-X generally speaking we have a policy to not carry patches which aren't upstream, if we wanted to make exceptions to this i think we should allow every maintainer a veto right or at least it would need to be a majority call.

[mweinelt]

I see the usability benefit of carrying these patches, as well as the downside with having to rebase it every once in a while. I want to have it and will gladly switch to a better solution when one comes by.

[blocktrron]

I would propose to go with these patches for now, in order to give it a substantial amount of testing.

We can still drop them later on, if rebasing becomes unbearable or a better solution is worked out.

[mweinelt]

@T-X Please rebase, we have no routing patches and this series is introducing patchset 0002.
My bad, I'm wrong.

[T-X]

Rebase to current master done (no changes).