Preparations for a patchset v3 for the Linux bridge regarding #multicast has progressed, have incorporated most feedback from the mailing list now. The feedback was actually a lot more "tame" and overseeable than I'm typically used to for my typical "early" v2 PRs with such a long list of commits :D.
And it feels so much nicer to work with and restructure such patches with having done extensive test scripts for/in the Linux selftest infrastructure early on :D.

On the positive side: progress. On the "downside", I'm now motivated to continue now, to work on getting #multicast snooping to work on it - even though it's late and I really, really should go home and go to bed :D.

Patchset v2 is out for the Linux bridge, to reduce checks in the #multicast fast path, and to later propagate a safety multicast (in)active state to #switchdev/#DSA:
https://patchwork.kernel.org/project/netdevbpf/cover/20260206030123.5430-1-linus.luessing@c0d3.blue/
Includes some fixes and got some nice Linux selftests: https://patchwork.kernel.org/project/netdevbpf/patch/20260206030123.5430-3-linus.luessing@c0d3.blue/
This is also the version currently used in this OpenWrt draft PR for #realtek / #rtl83xx (v6 - v8): https://github.com/openwrt/openwrt/pull/18780

#rtldsa #rtl93xx

Today's irritation is #DNS, which can just fuck off. #Multicast can also fuck off.

One of the most unexpected but horrific quotes for me so far:

"Unfortunately, many of these worm coders were sloppy and didn't confine this random selection to unicast ranges. [...] If that host was on a multicast-enabled network, its FHR would send a PIM register for each group address to its local RP, which would then send an MSDP SA for each group to all its MSDP peers."

#multicast #PIM #MSDP #RP

Only started to read into this "new" , informational #IETF #RFC, called "#Multicast Lessons Learned from Decades of Deployment Experience", but it's already a super interesting read:
https://datatracker.ietf.org/doc/draft-ietf-pim-multicast-lessons-learned/

I also unfortunately managed to miss to talk to any @videolan devs at #FOSDEM. Would have liked to talk about our experiences with it with #multicast. Maybe next year :-)

I'm on my way to (my first!) #FOSDEM! Hopefully the bus swap in Amsterdam will work out, we're already quite delayed. Only 0.5h instead of the originally planned 1.5h stop over time.
Let me know if you're at FOSDEM, too, and would like to talk about #MeshNetworks, #multicast and/or @batadv :-).

#Mesh #MeshNetwork

v8 for the #multicast patchset for the #OpenWrt #Realtek target pushed: https://github.com/openwrt/openwrt/pull/18780#issuecomment-3808673943
Now rebased onto the v6.18 PR for #OpenWrt. And with many style changes, which were suggested in the comments of this PR.

Curiously without needing to cherry-pick the mdio_aux reset-gpio revert to fix https://github.com/openwrt/openwrt/issues/18620. Worked out-of-the-box on v6.18. Will need to dig deeper later what in OpenWrt or between 6.12->6.18 might have fixed that.

@datacop @cypherhippie following up on the off-topic discussion on Jitsi regarding overlap between @battlemesh and #Fediverse (#Fedicamp?): I'd be super interested to get a better insight into what resources a Mastodon instance needs + how its data flow looks like. How much data is sent synchronously / simultaneously / redundantly to multiple receivers, how much is sent on-demand? Could smarter routers lead to less resource requirements for an instance/server? Could (long-term) #multicast help?

(and in between was the 39c3 which led me divert to fixing #pim6sd stuff and testing on #dn42 for a while, from layer 2 to layer 3 #multicast, and working on some Gluon census stuff... maybe one day we might eventually have hackspaces and community networks connected via multicast in a plug&play fashion :D.)

Finally got a v6, of a #multicast PR for #OpenWrt for the #Realtek / #rtl83xx target out: https://github.com/openwrt/openwrt/pull/18780
The whole thing, especially for the Linux bridge + DSA got bigger than expected (from ~4 patches to now 16...). But djfe was so kind to help with rebasing to 6.12 on OpenWrt. Then also got stuck on a regression in OpenWrt, but @cuechan's impartial view and technical expertise helped with that.
Next will need to circle back to upstream Linux for a new submission (after some sleep...)

@altf4 nice, awesome weathermap! Btw., any news/progress regarding #IPv6 at @HSBXL? I think it at least was broken when I visited last year?
Also would love to add IPv6 (and one day maybe even #multicast :-) ) to our #dn42 peering between @HSBXL and @chaotikumev
https://map.iedon.net/#4242421976

Watched #HideakiYoshifuji's 2009 Linux.conf.au talk on "Evolution of #Multicast Engine on #Linux": https://www.youtube.com/watch?v=yjctk8NZjG0
And was like, "oh, that wasn't that long ago, that was around when the @batadv Linux kernel implementation was started, too."
And then I realized, oh, wait, @batadv was started quite a while ago :D.

#ipv6 #MeshNetworks

@freifunk .oO(hm, wäre irgendwie auch witzig, wenn beliebige Leute/Gruppen n' @videolan Einzeiler starten und ihr Event per #multicast streamen und dezentral teilen könnten. Sodass man sich das über eine große Wand von allen mit anschauen könnte. Und die wenigen Communities, die bis dahin noch kein multicast unterstützen, müssten dann halt zentralistisch über @freifunkMUC 's Jitsi mit reingeproxied werden :-). Der MC ansatz wäre dann aber noch etwas Arbeit, aber vll. ginge da in 1 Jahr noch was)

Yaiy, have set up a new #dn42 peering at the #39c3 with @famfo! Even with #multicast / #PIM enabled (one more issue to fix, but 95% done / works with a workaround).

Hrmpf, so there is a #PIM #multicast peering between @ffhl an the #Nobreakspace (and transitivlely to two more dn42 people) now. But the more you look the more things look broken...

Got my chrome casts working across networks VLANs again. Forgot to install UDP Broadcast Relay after firewall hardware upgrade to deal with multicast proxying.

#OPNSense #Multicast

The #PIM + #BGP configs at the @chaotikumev / #Nbsp are also currently "documented" / dumped to this page: https://wiki.chaotikum.org/infrastruktur:host:dobby-setup. And will likely get a bit more tweaking until the #39c3. Later needs to be copied to the #dn42 wiki.
I had also hacked together a watchdog script which disables route imports+exports on the BGP #multicast channel in bird if a BGP neighbor does not also run a PIM daemon. This is to work around this issue which I mentioned a few days ago: https://wiki.dn42.dev/howto/pim-multicast-vs-unicast-issue

@ffhl or more precisely the embedded RP #multicast destinations derived from the IPv6 GUA unicast prefixes were copied to embedded RP ones from the ULA.
Also two SSM (source-specific multicasr) copies were added, one with a GUA source address and the other with an ULA source one. SSM won't be fully usable in our #Freifunk network yet, though (but it should work on #dn42).