NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Orbi 37x and Local Network Control Block (224.0.0/24) multicast
Dear all, I have an Orbi setup (RBE371 and 2x RBE370) that is causing me headaches with LAN multicast. One of my music application leverages multicast against 224.0.0.234 for node/companion ...
Update:
Based on StephenB comment 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
Update:
Based on StephenB comment 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
KevinLiT - can you escalate this within Netgear? Seems to me that in AP mode the Orbi should not be filtering any multicast addresses.