The #rtl9300 datasheets also read as if they had planned to provide some easy, built-in trapping options for #IGMP / #MLD reports, as they had for #rtl83xx, based on their new ACL / packet inspection engine. But that they had scraped that and postponed that to their bigger #rtl9310 chips.
#multicast
For the #Realtek #rtl9300 (excluding #rtl9310) switch chips for #OpenWrt further datasheet readings and bit fumbling brought me to the conclusion (for now) that it seems that there is no easy way for #IGMP / #MLD report trapping anymore. Hence #multicast snooping support for #rtl9300 on OpenWrt will be more tricky...
For #rtl93xx they introduced a new, powerful ACL / packet inspection system. And trapping has been changed quite a bit compared to #rtl83xx.
Also this datasheet has a field called IP6_MLD_ACT_0_x_x and one called IP6_MLD_ACT_db8_x_x. Acc. to the datasheet to configure forwarding/trapping/copying/dropping settings. The former for #IPv6 #MLD packets with an FF0X::X:X address, and the latter for FF0X::DB8:X:X. And only the latter seems to help with trapping. Even though I'm sending an MLDv1 report for/to ff12::123...
What on earth is this "DB8" about?
#multicast
Also finally found some combination of register setups and diffs for this #Xikestor #Realtek #rtl9300 based chip which correctly traps #MLD packets to the CPU / Linux kernel/bridge, which is necessary to fix #multicast snooping with it.
The combination doesn't fully make sense to me yet though, will need to play around a little more to hopefully get a better understanding. But at least that seems like some progress. Will also need to check #IGMP later.
În contra biserichi ortodoxă/catolică din Basarabia, statul capitalist care se fabrică in ziua de azi şi socialişti care murdăresc comunismul. Naționalişti sunt nişte chiori care cred minchiunile statuli şi vind libertatea individuală şi colectivă. Armata ieste un baligar de vacă şi poliţia nişte paraziți. Anarhia nu e caos şi desorden. E orden, autogestiune şi organizaţie. Solidaritatea e instrumentul nostru pentru a să facem o schimbare. Hai să ne ridicăm şi să luptam în contra statului! #MLD

Yaiy... looks like I might have found another bug which isn't in #pim6sd, but in the #Linux kernel instead... It seems like for a veth pair the recvmsg() call returns an #IPv6 sockaddr with a scope-id from the wrong side of a veth pair for #MLD v2 reports. Which pim6sd does not like, it will ignore the join then. MLDv1 reports work as expected though, there the scope id looks correct.

#multicast

How I now imagine it when my laptop sends an #MLD report to leave a specific #multicast group:
https://www.youtube.com/watch?v=jmzdObf3FtA
"We're Not Gonna Take It (#MTG Parody)"
#MulticastTheGathering #MagicTheGathering
We're Not Gonna Take It (MTG Parody)

YouTube

Use #BSD for good networking, nuff said... Use #OPNsense for a firewall/router, nuff said...

Me trying to use #multicast snooping with this in our hackspace: After several hours of debugging, realizing it's not bc. of the #OpenWrt powered, #rtl83xx based switch I've added, nor the new patches I've made and added to it. But because of this two years old, ignored #OPNsense (or #FreeBSD?) bug with #MLD: https://github.com/opnsense/core/issues/6247
😒 😤

IPv6 MLD listener report going to wrong interface · Issue #6247 · opnsense/core

Important notices Before you add a new report, we ask you kindly to acknowledge the following: I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING....

GitHub
In the classic, non-DSA #Linux bridge the philosophy so far is: No matter in what combination you enable/disable multicast_snooping+ multicast_querier: The bridge ensures you don't break any network protocol, it detects per protocol family if #multicast snooping is applicable. That together with #RFC4541 I think is the only way to regain trust for #IGMP / #MLD snooping imo.
And now things like #DSA or #switchdev come along with non-foolproof solutions, diverging between each driver...
...and even this mrouter exists #switchdev event is a quite incomplete approach. What if you multicast router somehow #IGMP / #MLD querying disabled -> would break any #IPv6, even if you're not using multicast routing. What if you only have an IGMP querier? Would notify an mrouter-exists, but there's no MLD querier, so again IPv6 would be broken...