@jpl @ffhl an sich nicht auf layer 2 beschränkt, deswegen hatte ich u.a. am #brmldproxy in Gluon (und #pim6sd + @batadv + Linux bridge) gearbeitet, damit man das auch geroutet mit überschaubarem extra overhead machen kann. Wurde soweit auch schon mit pim6sd zwischen @ffhl und (einer Domäne von) @Freifunk Vogtland erfolgreich getestet.
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
I'm glad that I did look into #tc this year for my #brmldproxy implementation for #Gluon / #Freifunk. And that I took a lot of wild notes during my trial & error learning of tc. As I couldn't really find any good tutorials for packet redirections with tc. And error outputs of tc or manpages, as well as the overall tc syntax is not useful as an easy, self-explanatory step-by-step guide on their own either, in my opinion. It's very powerful, but could need more, good tutorials, in my opinion.
Yaiy, it works! The full integration test for a #multicast audio stream at #Freifunk involving #Gluon, #batman_adv, @gstreamer and #brmldproxy + #pim6sd + #EmbeddedRP with routing between @ffhl and a test domain at @Freifunk Vogtland was successful (at least with pim6sd in #MLDv1 mode).
Next need to do a few, small updates to my brmldproxy integration pull-requests for Gluon. And need to look into the #MLDv2 mode issues with #pim6sd. And need to document some more stuff.
And one more update to the #brmldproxy integration in #Gluon: Added a patch to #batman_adv that avoids flooding #MLD reports when using brmldproxy in our specific scenario. Now that we got the link layer pretty quiet of broadcast flooded #IPv6 #multicast packets it was too tempting to keep it that way :D. #scalability #mesh #MeshNetwork #Freifunk
And a pull-request for adding a package to #Gluon for #brmldproxy integration is out:
https://github.com/freifunk-gluon/gluon/pull/2995
Which should allow using layer 3 #IPv6 #multicast routers again in these layer 2 #batman_adv #MeshNetwork|s at #Freifunk. #Mesh
Nice, the "#Bridge #MLD #Proxy" daemon (#brmldproxy) I stitched together with TC (#TrafficControl) generally seems work on a #Freifunk #Gluon #mesh node. In this context it is supposed to make IPv6 #multicast routers/-ing work again. Currently Gluon filters all MLD to reduce layer 2 overhead with #batman_adv
With brmldproxy it can be configured to only emit MLD reports for routable multicast addresses.
Next steps: Creating init scripts + packages. Maybe adding hotplugging support to brmldproxy
