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 ...
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 ?
Changing to router mode is more intrusive for me, and it is not my final setup anyway.
I was just suggesting it as a test. Though if it worked, you could potentially use it. Double NAT can usually be managed.
Why would mDNS go through and not the 224.0.0.234 ?
I don't know, so there is some mystery here that needs to be sorted. Also, I dion't know why x.234 multicast would flow from ethernet->wifi clients, but not from wifi->ethernet clients (which is what I think your diagram shows)..
Note that w/o igmp snooping, the multicast traffic is supposed to be broadcast on all segments of the network. Not a problem for discovery, but it can flood the network if you are sending media.
I am wondering - are these Windows clients? If so, have you tested this with the windows firewall (and any internet security software) turned off? I believe the windows firewall allows specific multicast protocols (including mdns), but does not allow all 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.