kernel: bridge: readding MLD wakeup call feature

[T-X]

With the update to OpenWrt 21.02 the bridge MLD wakeup call feature was
removed. However the issue with Android devices and MLD is still
present. Therefore readding the bridge MLD wakeup call patch and porting
it to Linux 5.10 / OpenWrt 22.03.

Link: https://issuetracker.google.com/issues/149630944
Fixes: aab2b91 ("modules: switch to OpenWrt 21.02")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

[T-X]

Changelog v2:

• renamed 0008-kernel-bridge-Implement-MLD-Querier-wake-up-calls-Android-bug-workaround.patch to 0007 -> fixes a CI check failure

[neocturne]

As we have switched to 22.03, this needs another rebase now.

[T-X]

As we have switched to 22.03, this needs another rebase now.

I'm working on it. Mostly straight forward, but in Linux 5.10 there were some larger changes to the bridge multicast code to add MLDv2/IGMPv3 support. MLDv2/IGMPv3 is nice, but also a lot more complex than MLDv1/IGMPv2...

For our current configuration should not matter too much as the default for the Linux bridge and therefore for us too is still MLDv1/IGMPv2. But I would still like to get the rebased wakeupcall feature in a shape so that it should(tm) work, too, when setting the bridge to MLDv2/IGMPv3 (querier).

What I'm still trying to wrap my head around is retransmissions of multicast address specific or multicast address + source specific queries and the new suppress flag in MLDv2/IGMPv3. More precisely in which of these cases to send a wake-up call or not.

---

PS/Edit: net/bridge/br_multicast.c increased from ~2500 lines of code in Linux 5.9 to ~4000 in Linux 5.10. Should mostly be unused when using the default MLDv1/IGMPv2 mode. But still worth to keep an eye on for potential regressions in tests and in the field in general.

[T-X]

Changelog v3:

• updated to Linux 5.10 / OpenWrt 22.03

[T-X]

Changelog v4:

• rebased to current Gluon master: moved patch from 0004-... to 0007-...

[neocturne]

How confident are we that the rebase didn't break anything? Is it a good idea to merge this when we're fairly close to a release?

[T-X]

How confident are we that the rebase didn't break anything? Is it a good idea to merge this when we're fairly close to a release?

I have it running on this node here, without any issues so far: https://vogtland.freifunk.net/map/#!/en/graph/e4956e440db5

And I see the ICMPv6 Echo Request / MLD exchange in Wireshark when connecting to it. So this feature is active on it.

I haven't changed anything in the parsing and packet allocation code. Only had to update a few variable names and the entry points in the end as some function parameters got changed with the MLDv2 addition in the Linux bridge. So to me compared to the previous version for OpenWrt 19.07 this shouldn't (tm) be that different / fragile.

But as earlier this gets merged the earlier others will test and verify it as well ;-).

[neocturne]

Potential future cleanup (for the next big rebase?):

Moving all these enum fields by 1 seems unnecessary. Maybe add the new flag at 1ULL << 63 instead?