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...

for the former case it is broken when you have devices/listeners with #IGMP v1/v2 or #MLD v1, instead of IGMPv3 / MLDv2. The issue you'll then potentially run into is IGMP / MLD report suppression. The big thing which #RFC4541 specifies an ugly workaround for... this whole report suppression has lead to so many hard to debug, subtle breakages for decades and now seems to continue with #Linux #DSA / #switchdev...
#multicast #igmpsnooping #mldsnooping

on the other hand, unfortunately, it seems that #DSA in #Linux (and by that this downstream #rtl83xx driver) so far seems to repeat the mistakes we did in the Linux #bridge and fixed during the last decade... it's not following #RFC4541, DSA does not seem to have an option to set multicast router ports yet... which overall breaks #IGMP / #MLD snooping and by that #multicast in many scenarios... will be interesting if that is fixable or a limitation of #rtl83xx based #switch chips.

@awlnx oh, spannend! Was ich nervig fand, dass viele Geräte #IGMP / #MLD snooping kaputt implementieren, sich nicht an #RFC4541 halten. Bei Switches mit offloading dafür kann man das "Feature" in der Regel gleich wieder abstellen. Hat auch ca. 4 Jahre gebraucht, bis es die Linux bridge ordentlich gemacht hatte... #pim6sd macht bei mir für MLDv2 auch noch Probleme, nur MLDv1 scheint damit zur Zeit ordentlich zu gehen. Und dieser Android MLD Bug war extrem nervig... Was hattet ihr so für Probleme?

@T_X #lcsync sends MLD Queries, so hopefully that will stop any #RFC4541 switches from getting confused. MLDv1 makes a real mess of this - be nice to get rid of it. The very idea of a switch trying to guess what is a router is madness, when the simple answer in IPV6+MLD2 terms is does this port listen to ff02::16 ?

@dentangle the world would be so much nicer without MLDv1 and esp. MLDv1 report suppression... Then we wouldn't need most of #RFC4541. And wouldn't need to come up with workarounds for workarounds... And in an MLDv2 only world and without #RFC4541 an lcsync server could have just listened to ff02::16 to receive all MLDv2 reports...

@dentangle and unfortunately this #RFC4541 imposed tree forwarding in networks with snooping switches is a) widely implemented. And b) kind of necessary, because this in turn works around the super annoying MLDv1 report suppression... which would otherwise turn "duplicate" listeners on the link invisible for the snooping switches, leading to multicast packet loss. We also had to work around this in batman-adv... https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-report-suppresion