Orbi 37x and Local Network Control Block (224.0.0/24) multicast

So testing with another satellite that has a "dumb" switch connected to its eth port gives the same results than with the managed switch.

I don't have "Blocking of unknown multicast addresses" and static multicast groups, etc options in my old GS108T

Question: could "Blocking of unknown multicast addresses" be a default setup for RBS/RBR somehow? 

224.0.0.234 is part of the 224.0.0.153-224.0.0.250 block flagged "unassigned" by IANA. Just guessing here as all this does not makes sense to me from a network point of view, 224.0.0.251 (mDNS) flies properly but not 224.0.0.234 ??

mbolo01 wrote:

Question: could "Blocking of unknown multicast addresses" be a default setup for RBS/RBR somehow? 

224.0.0.234 is part of the 224.0.0.153-224.0.0.250 block flagged "unassigned" by IANA. Just guessing here as all this does not makes sense to me from a network point of view, 224.0.0.251 (mDNS) flies properly but not 224.0.0.234 ??

mDNS is a well known protocol.  The protocol your music app is using is not.

One aspect here is that the Orbi is operating at layer 2, so not looking at IP addresses at all.  But these particular addreses are also mapped to MAC addresses ( .234 maps to 01:00:5e:00:00:ea)

In general, reception requires two things:

1. the infrastructure needs to forward traffic with this range of destinations to all nodes (since no IGMP snooping is going on).
2. Each client needs to configure their NIC to receive traffic with the MAC address destination (in addition to their physical MAC address).

The Orbi could be filtering the traffic - hard to be sure, but your testing is certainly pointing in that direction.  What app are you using?  

My music app is Plexamp from Plex which offers multiroom.

Based on your comment (@StephenB) about "Blocking of unknown multicast addresses" , i ran the following test.

Setup

• Host A RPI  Debian GNU/Linux 13 (trixie) Wifi connected to RBS 1
• Host B RPI  Debian GNU/Linux 13 (trixie) wired to Netgear Switch wired to RBS 1
• iperf tool installed on both host A and host B

Test Scenario

• Join Host A to mcast group 224.0.0.252 (registered as Link-local Multicast Name Resolution) and use Host B as client to send datagrams to this group address: SUCCESS - Host A receives the datagrams
• Join Host B to mcast group 224.0.0.252 (registered as Link-local Multicast Name Resolution) and use Host A as client to send datagrams to this group address: SUCCESS - Host B receives the datagrams
• Join Host A to mcast group 224.0.0.235 (part of unassigned mcast block according to IANA) and use Host B as client to send datagrams to this group address: FAILURE - Host A DOES NOT receive datagrams
• Join Host B to mcast group 224.0.0.235 (part of unassigned mcast block according to IANA) and use Host A as client to send datagrams to this group address: SUCCESS - Host B receives  datagrams

My conclusion: 

• These test are consistent with my first observations
• When listening server is Host A and Host B is the sender, only datagrams to 224.0.0.251 and 252  groups are going through, many other mcast groups i have tested in the 224.0.0.1/24 block don't go through. Note: I have not tested all of them, but many well known, including IGMP 224.0.0.22 don't go through.
• When listening server is Host B and host A is the sender, all mcast groups I have tested are going through
• It is obvious that there is a difference between RBS/RBR ethernet port traffic management and wireless management
• All tests I have done are reproducible

mbolo01 wrote:

My music app is Plexamp from Plex which offers multiroom.

Ok.  I have plexamp on my phone, but never set up multiroom.

Only the UNIX instances of Plexamp are currently officially supporting multiroom. Plexamp on the phone can control these UNIX instances and group them in a multiroom setup, works very well