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

• mcast flows from the WiFi to the ethernet, not the reverse. I checked the diagram and I think the arrows are correct, please confirm.
• yes, this is my expectation that w/o igmp snooping such traffic should broadcast and yes it is only for discovery.
• the hosts are RPI/LINUX. No firewall or any other network filtering involved here. When running tcpdump on each of them I can see that mcast packets are correctly sent but not received by other hosts behind Orbi kits but the ones directly plugged in the ethernet switch.

mbolo01 wrote:

mcast flows from the WiFi to the ethernet, not the reverse.

And all the ethernet hosts are connected to the GS108T?

What multicast settings are set on the switch?

Does anything change if you connect a host directly to the RBE370 LAN  port?

I have another non managed Netgear switch connected to my second satellite. I guess that I would see the same behavior. I’ll plug my Mac in it and see what mcast packets I see here.

I have no host directly connected to the Ethernet port of a satellite.

mcast IGMP snooping and IGMP snooping querier are disabled in the GS108T

testing in the non managed switch should be the same than directly connecting a host to a satellite port.

mbolo01 wrote:

testing in the non managed switch should be the same than directly connecting a host to a satellite port.

agreed

mbolo01 wrote:

mcast IGMP snooping and IGMP snooping querier are disabled in the GS108T

Which is what you want.

Also make sure "Blocking of unknown multicast addresses" is disabled.

There are some other settings (static multicast groups, etc) that also shouldn't be used.

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