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 ...
Repeating my initial reply as some text had been cut (timeout i guess) - This one is the good one:
- Test machines are not connected to both Ethernet and Wifi at the same time.
- I used a Netgear Switch for the Ethernet test (GS108T) to ensure that both nodes were effectively sending/receiving these multicast packets. This switch has IGMP Snooping and Snooping Quering are disabled.
- When both connected to the same Orbi Unit via WiFi, multicast to 224.0.0.234 fails.
- What is interesting (I just discovered that) is that these multicast packets are received by a host connected to the Netgear Ethernet Switch that is itslef wired to the RBS, but the multicast packets sent from the device connected to the Netgear Ethernet switch are not received by the hosts wifi connected to the same (and other) satellite or router.
- I have used tcpdump and Wireshark to witness this traffic from both side.
Attached is a drawing of my setup (I'm still not able to attach the drawing)
(I'm still not able to attach the drawing)
Forum bug - not clear when/if Netgear will fix it.
You can put it into cloud storage and include a link. (if the link has the file extension, you can also directly add the graphic or pdf from the cloud storage URL).
I need to set my FAI router with IGMP features which does not make sense for this address block.
Although it doesn't seem to make sense, I suggest that you try it anyway.
The Orbi isn't routing, but is instead operating at layer 2 (since you have it set up as an access point). Are the multicast packets that aren't getting through sending to the layer-2 broadcast (Mac address ff:ff:ff:ff:ff:ff)?
I wish I could play with IGMP settings in my FAI router, at least to park this possible root cause even if it does not makes sense, but I cannot act on any IGMP settings.
Yep, Orbi devices in my setup are supposed to operate at layer 2, reason why I don't get why these mcast packets don't go through, or partially go through, like in the ethernet switch acting at layer 2 too.
According to Wireshark capture, the mcast packets to 224.0.0.234 that aren't going through are using dst mac address 01:00:5e:00:00:ea
Note: other mcast packets such as MDNS (224.0.0.251) are going through well and are using the same dst mac root address, i.e. 01:00:5e:00:00:fb
According to Wireshark capture, the mcast packets to 224.0.0.234 that aren't going through are using dst mac address 01:00:5e:00:00:ea
ok, so that is the correct multicast mac for 224.0.0.234.
What is supposed to happen is that the receivers subscribe to the multicast address using IGMP. Then the mesh uses IGMP snooping to forward the multicast only to the correct receivers.
Can you try changing the Orbi from AP mode to Router mode and see if that makes any difference?
Changing to router mode is more intrusive for me, and it is not my final setup anyway. I'll see what I can do on this front, but I cannot consider such temporary change in the short term.
Why would mDNS go through and not the 224.0.0.234 ?
link to the drawing:
https://transfert.free.fr/bbNbdES
Thank you for posting drawing.
Have you sent NG support this drawing for review?
Yes, I made this drawing to document my support case.
The only difference with the one I sent them is that I didn't find first place that mcast traffic from a host connected to a satellite, or the router, was reaching the hosts plugged into the ethernet switch while the reverse was wrong. Initially I thought that nothing was reaching the hosts connected to the ethernet switch coming from any Orbi device
