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

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
😒 😤

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

Neither #switchdev nor #DSA really check if an IGMP/MLD querier exists. So if you enable #multicast snooping on these you currently also need to make sure to have an #IGMP / #MLD querier somewhere. Which is different to a classic Linux bridge, which will stop snooping optimizations if there is none, to avoid packet loss. Only for Marvell Prestera I found some mrouter-exists check via an according switchdev event. Which no other driver uses. And...

Had found an issue with the #DSA #rtl83xx #IGMP / #MLD snooping code in #OpenWrt, it would always flood snoopable IP #multicast payload with no MDB entry, instead of dropping. Finally got some clue how this chip gets configured, it's a bit confusing with all these tables and how they point to each other :D. And these magic shifting numbers, instead abstracting them... Also found one bug in one shift value, I think.
And could get things to drop! Now need to drop more selectively.

Next PoE capable switch arrived from kleinanzeigen.de. This one hopefully supports #OpenWrt and #DSA out-of-the-box and has some progress towards #IGMP / #MLD snooping support. Hoping that it might be the pick to get #multicast running in our hackspace at the #Nobreakspace. There's still work on multicast router ports needed though.
But before I get started on this one, need to document+upload my previous progress on getting #OpenWrt running on the #Dlink DGS-1210-10P **B1** to the OpenWrt wiki.

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

and Jan's reply on the #OpenWrt forum also lead me to this observation, that several #switchdev drivers seem to try to emulate a multicast router port by mirroring all known #multicast listener entries onto these mc router ports... https://patchwork.ozlabs.org/project/openwrt/cover/20230303214846.410414-1-jan@3e8.eu/#3074983
Which makes me scream, this is broken in so many scenarios... like when you use multiple #IGMP / #MLD snooping switches. Or if you don't have a listener for that group, only a sender, whose packets still need to go to multicast routers.

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.

So, coding session 2 of trying to get #OpenWrt running on this D-Link DGS-1210-10P B1 switch (which I hoped it would before buying it for 40€ on kleinanzeigen.de - but of course only variant F1 is supported by OpenWrt...). Last time I got at least an OpenWrt initramfs booted (without any networking or flash). And still hoping that it might be #DSA capable and would do #IGMP / #MLD snooping in kernelspace with hardware #multicast forwarding support.

Can anyone recommend any #switchdev capable switches? Doesn't have to be crazy fast, 1 Gbit/s ports would be fine. I'd mostly be interested in using it for #multicast, so that the #IGMP / #MLD snooping would be performed by the #Linux bridge. Is there anything that would be affordable for a #hackspace?

Has anyone ever build some testing suite to check if an #IGMP / #MLD snooping switch behaves properly? Especially if it follows #RFC4541?
We have some old, donated switches here in our hackspace and I'm afraid that they might be too old to do this correctly. Also does #OPNSense / #FreeBSD have some working IGMP/MLD snooping feature? So far, from experience and code reviewing/debugging/fixing, I'm only fully trusting the Linux bridge's implementation of this.

#multicast

v7 for the #brmldproxy patchset for #Gluon is out. Restructured a few things to automize and ease the #MLD querier setup inside the mesh. Basically the Gluon package now takes care of the querier part, too. No need to manually configure them on gateways for example. Also added many of @neocturne's suggestions. Hoping to see #IPv6 #multicast routing between Gluon domains or even #Freifunk communities soon.
#pim #pim6sd

So implemented some bits to also #proxy #MLD queries, not just MLD reports in #brmldproxy. This should avoid having to do any special configs on gateways / dealing with querier configs with #Gluon and #Freifunk / should ease its usage. #IPv6 #multicast routers can then be placed behind any Gluon node with this daemon. "Only" should have an up-to-date @batadv on all Gluon nodes in the #MeshNetwork. Will do a little bit more testing and then update commit messages + PRs.
#Mesh #PIM #pim6sd

v6 of the #brmldproxy pull request for #Gluon for #Freifunk is out. Replaced a not yet upstream @batadv patch with some more #tc hacks for now: https://github.com/freifunk-gluon/gluon/pull/2995#issuecomment-2544909542
Let's see if something gets merged into Gluon (or at least its community repository) in time for the #38c3 :-).
#multicast #mld #mesh #meshnetwork #ipv6

@mherrb for NDP I would check if the multicast destination, the solicited-node multicast address, in the ICMPv6 Neighbor Solicitation message is shown for the correct port in "bridge -s -d mdb show". Or alternatively if there is a multicast router listed for that port (as you mentioned #RFC4541 in your summary, that specifies that both all #MLD reports and all multicast traffic needs to go to the multicast router - which is a workaround for the MLDv1 report suppression...)

@goetz @ffhl I needed a while to figure out what practical benefit we would have. One thing that came to my mind: Avoiding #ARP on supporting devices completely if I understand #ipv6mostly correctly. We do have a DHT for ARP in #batman_adv. And could reduce broadcasts a lot with it. But it's still not zero. #IPv6 is so much smarter for Neighbor Discovery as it uses #multicast properly with its solicited mcast addresses and not like broadcasts. And we have #MLD snooping in our #mesh.

Hm, isn't it a bit weird/inconvenient that with #IPv6 when creating a #UDP socket by default I can receive packets from any interface. But a setsockopt() to join a #multicast group, via IPV6_JOIN_GROUP, can only join a specific or a default interface?
Is that a bug or a feature?
Wouldn't it be more convenient if an IPV6_JOIN_GROUP with a zero interface index were joining with #MLD on all interfaces (that work with the given scope)? #RFC2553