We have reported the multicast-enhance feature broken since February. But only received generic – clear my support queue updates, like “try updating“ since the original ticket was opened (SUP-180218).
We tested the latest beta (7.21beta5) since the change log contains a note: “wifi-qcom - multicast-enhance will no longer apply for station mode configured devices;“
Thought there might have been some movement on the issue, but its still not working. We have documented the issue with minimal clean configurations and packet captures.
Broadcast and multicast in any decent size wireless network is one of those issues that can really bring a network to its knees. But searching the forum there is no mentions of users complaining, except some IPTV issues from one user.
We are doing our best to limit ingress multicast and broadcast traffic, but the amount of airtime used on this traffic is significant when the system grows to a few hundred APs.
Is this just an issue that is affecting a very small group of users? There has to be operators out there with similar issues.
I'm curious: how did you determine that multicast-enhance is not working in wifi-qcom driver?
BTW, the way I understand the beta change log you quoted ... is that the multicast-enhance "magic" will not work if interface is configured as station (which makes lots of sense to me ... station is only directly talking to single wireless peer - which is the AP ... while AP talks with multiple wireless peers where multicast-enhance makes a difference).
The update from the change log also makes perfect sense to me. I was simply noting that the part of ROS that deals with multicast enhance was being worked on.
We document the issue by setting up a minimal config on a hAP-AX2, then make IPTV streams available and have clients join the streams wired and wireless, while doing a client side capture.
At the same time we run an RF Tap capture to document the frames are transmitted at the base rate.
The captures show unaltered dst addresses and base rate when multicast-enhance=enabled. This is true for both hardware and virtual APs.
I would love this to be a configuration error on our part, but there is not alot of moving parts. Below is the minimal config and captures provided to support.
So you're saying that even though multicast-enhance is enabled, you still see single frame stream with dst-MAC set to broadcast address ... instead of seeing multiple unicast streams with individual stations' MAC addresses set as dst-MAC?
I wonder if there's a way for AP to detect a sleeping station and thus convert multicasts to unicasts only for that particular station? And if that's the case, this might never happen if all the wireless stations are awake at thime of sending each particular broadcast frame (containing multicast packet).
Yes, dst addresses are not being converted to unicast when using qcom, they are being converted when the legacy wireless package is being used. Thats what the captures below show (01005e prefix pass through on ax2, unicast mac on ac2).
I understand where you are going with the suggestion to detect sleeping clients, but if you use IGMP snooping that issue resolves itself as sleeping clients will fail to confirm their IGMP memberships.
Fundamentally, that is dealing with power savings and to me a different issue. The overarching issue is that without the conversion all multicast traffic is tx at 6Mbit/s. That consumes lots of airtime, bogs down the efficiency overall and presents issues by relying on a GTK for encryption.
I am simply wondering why this is receiving a low priority, its seems likely the Mikrotik userbase is tilted towards homes and not semi large WiFi deployments. Its a significant issue for us.
We just got our first batch of hAP ax S, running wifi-mediatek. Multicast enhance works as expected in this package. So its only wifi-qcom that is broken.
With /tool/sniffer/quick dst-ip-address=224.0.0.0/4 direction=tx (on AP) I can see quite some packets going to wifi interfaces. But it seem to be only these multicast address:
224.0.0.251:5353
This is mDNS and I am not sure if "multicast-enhance" converts these mDNS multicasts to unicast.
sends multicast and these are captured by sniffer quick, but only forwarded to "ether1" and not to any wifi interface. So does it actually work correctly?
Not sure when in the packet flow the conversion takes place. So it is possible a capture on the AP will show frames with the dst mac address from the wired interface.
Validate by running wireshark on a client and check if the dst mac address of mDNS, ARP etc is broadcast (ffffffffffff) or the client MAC address.
What model device are you on? I only updated to clarify that wifi-mediatek works as expected, if you are on e.g. ax2 that uses wifi-qcom, then multicast enhance is still broken.
Not sure if the conversion is a driver level feature, but in previous posts on this topic there are samples of multicast enhance working vs. not working. Basically you are expecting the dst mac address to be replaced on multicast and broadcast frames.
wireless and wifi-qcom and wifi-mediatek are 3 different drivers. Do we know the details? The only hint we have is the docs:
With the multicast-enhance feature enabled, an AP will convert every multicast-addressed IP or IPv6 packet into multiple unicast-addressed frames for each connected station.
This may improve link throughput and reliability since, unlike multicast frames, unicasts are acknowledged by stations and transmitted using a higher data rate.
