Jan EkholmApr 27

It's interesting how ass Windows is to use when it comes to low level networking. Nothing works as expected or how it works elsewhere.

In this case I'm trying to stream audio to a multicast address. Sure, the audio arrives, but it arrives in clumps every 300-1000 ms, not as a, well, smooth stream. Cue and endless search to try to find some option that would work around the idiotic Windows kernel's ideas. Still searching and hating this utter shit.

#windows #garbage #multicast #streaming

Tycoon WorldApr 8

NETGEAR Insights: The Growing Importance of AV-IT Convergence in Enterprises

#TycoonWorld #AVITConvergence #DigitalTransformation #EnterpriseTechnology #FutureReady #NetworkingSolutions #AVoverIP #AVoIP #SmartWorkspaces #DigitalInfrastructure #ITInfrastructure #UnifiedCommunications #EnterpriseNetworking #ProAV #NetworkPerformance #LowLatency #HighBandwidth #PoE #Multicast #CyberSecurity #NetworkSecurity #IPBasedSystems #ScalableSolutions

https://tycoonworld.in/netgear-insights-the-growing-importance-of-av-it-convergence-in-enterprises/

NETGEAR Insights: The Growing Importance of AV-IT Convergence in Enterprises – Tycoon World

Providers such as NETGEAR Inc are addressing these needs with dedicated Pro AV portfolios. Solutions like the M4250 series AV switches and M4350 series are

Tycoon World
Show threadT_XApr 4
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
T_XApr 4
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.
Show threadvoided warrantyApr 1

they think they found the issue.

here is their reply:

"The Problem: In many Qualcomm-based (QCA) drivers, the Multicast Snooping (MCS) module is programmed to ignore "well-known" or "permanent" multicast addresses (reserved by IANA) for snooping purposes. It floods them to all ports to ensure compatibility with network protocols that rely on these addresses. Like the one that you are choosing here is just the permanent multicast address "ff05::1234".

The Consequence: Because the system doesn't "snoop" these addresses, it never learns which specific client wants the traffic. Without this "MDB" entry, the Access Point cannot perform Multicast-to-Unicast (M2U) conversion, which is essential for stable video/data streaming over Wi-Fi.

The Solution: Moving to the ff3x::/16 range (often used for SSM - Source-Specific Multicast) or other non-permanent ranges allows the MCS to intercept the join requests and create the necessary entries for optimization."

I then tried ff35::1234 and it did not work #IPv6 #multicast #cursed

Show threadT_XMar 31
Ah, one small mystery solved, for documentational purposes! #RFC6676, "#Multicast Addresses for Documentation": https://datatracker.ietf.org/doc/rfc6676/
(though still not sure why playing with that helps me for ff12::123...)
RFC 6676: Multicast Addresses for Documentation

This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

IETF Datatracker
T_XMar 31
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
T_XMar 31
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.
T_XMar 30

My initial reflex of that thumbnail of cardboard with the words "no consent = no content" had me think about #multicast:
https://netzpolitik.org/2026/digitale-gewalt-das-lass-ich-mir-nicht-nehmen/

Especially as that's how @dentangle and @onepict have often described multicast.

Digitale Gewalt: Das lass‘ ich mir nicht nehmen

Der Fall von Collien Fernandes schockiert viele. Erschreckend sind allerdings auch die Reaktionen: Menschen verteidigen jetzt ihr vermeintliches Recht, sexualisierte Deepfakes ohne Zustimmung zu erstellen. Und sie offenbaren damit, wie hartnäckig sich alte Machtansprüche halten.

netzpolitik.org
T_XMar 21

Visited my parents today and noticed that my father uses #teletext on the TV to get live results for soccer matches. He's not using the internet for that. And I kind of like that idea, teletext is really neat, no pages cluttered with ads, dark mode by default, uniform font, no attention seeking animations.

And that made me wonder if there could be some useful protocols to proxy teletext to IP #multicast, of course :D. (afaik teletext pages are broadcasted round-robin?)

@Selfnet_eV, any ideas?