Multicast-enhance not working in wifi-qcom package

[merlinthemagic7]

HI,

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.

IPTV cuts and pixelations with Movistar Spain and HAP ax3/ax2

@jfim88 The update frequency of the UI is not going to be able to keep up as the radio will switch back and forth between lowest rate for broadcast and multicast and the max rate for unicast traffic. If you have another MT unit sniff the channel traffic while streaming and you will see each frame with multicast traffic having a tx bitrate 6Mbit/s in the radio TAP header. (Edit: added 2x frames from an AX2 for referance) @itimo01 Attached are client captures from right now (Expanded DST MAC ob…

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.

[mkx]

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).

[merlinthemagic7]

@mkx

wireless

Hi,

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.

mc-enhance.zip (4.1 KB)

Edit: We did the same on a hAP-AC2 using Multicast Helper=full and that works as expected.

[mkx]

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).

[merlinthemagic7]

Hi,

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.

[merlinthemagic7]

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.

[infabo]

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.

I downloaded mcjoin (GitHub - troglobit/mcjoin: Simple multicast testing application) for testing.

mcjoin -s on a linux wireless client

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?

[merlinthemagic7]

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.

[infabo]

As expected from sniffer: wireshark mdns packet (filter: udp.port eq 5353) destination is "01:00:5E:00:00:FB" (=multicast).

[merlinthemagic7]

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.

[infabo]

I am on wifi-qcom-ac. Do we actually know what Qualcomm driver does (or should do) when multicast-enhance is enabled?

[merlinthemagic7]

@merlinthemagic7

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).

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.

[infabo]

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.

see WiFi - RouterOS - MikroTik Documentation

[ferferga]

Although they are diifferent drivers, this is not working as the docs describe for qcom drivers according to @merlinthemagic7 captures.

[infabo]

I have nothing to compare against, I only have wifi-qcom-ac.

At least I see these mdns multicast frames.

[erodriguez]

Adding a data point that may help narrow this down: on wifi-qcom the
multicast-enhance conversion appears to be HALF-working — it converts
IPv6 group traffic but not IPv4.

Setup: hAP ax2 (wifi-qcom) as WiFi CAPsMAN controller + AP, RouterOS
7.21.5 (LTS), multicast-enhance=enabled on all AP configurations.
Capture taken client-side (Wireshark/Npcap on a WiFi laptop, managed
mode, filter: udp.port == 5353) while opening the cast device list on
another client to trigger mDNS activity. Several distinct source
devices on the network (Android TV box, smart speaker, IoT, iPhone).

Result, consistent across every frame and every source device:

• IPv4 mDNS (dst 224.0.0.251): 26/26 frames arrive with
  dst MAC = 01:00:5E:00:00:FB → NOT converted. Matches the earlier
  captures in this thread.
• IPv6 mDNS (dst ff02::fb): 20/20 frames arrive with
  dst MAC = the receiving station's own unicast MAC, while the
  destination IP remains ff02::fb → genuine L2 multicast-to-unicast
  conversion IS happening for IPv6.

Since the destination IP stays multicast, this is not the mDNS QU-bit
unicast-response mechanism — it's the AP rewriting the L2 destination,
i.e. the m2u machinery exists and runs on wifi-qcom, but only the IPv4
branch is broken. Hopefully that narrows the search for whoever picks
up SUP-180218.

Repro: enable multicast-enhance on a wifi-qcom AP, associate two WiFi
clients, run Wireshark on client A (udp.port == 5353), generate mDNS
from client B or any cast/IoT device, inspect Ethernet dst of incoming
frames: 01:00:5E:00:00:FB / 33:33:xx = not converted; your own NIC
MAC = converted. On my capture IPv6 comes back converted, IPv4 never.

Sanitized capture can not be attached sin I am "new", anyways relevant captures are. (MACs/IPs/hostnames/device IDs anonymized;
multicast dst MACs and the IPv4-vs-IPv6 asymmetry preserved).

[merlinthemagic7]

@erodriguez that is a great datapoint, thank you for adding it. Goes to show I should not be making assumptions.

[pe1chl]

@erodriguez

multicast-enhance conversion appears to be HALF-working — it converts
IPv6 group traffic but not IPv4.

You tested with 224.0.0.x which is a special case. Try with another 224.x.x.x multicast address outside that range.

[erodriguez]

Follow-up on the "224.0.0.x is a special case" point — retested with a
group outside the Local Network Control Block, and it makes no difference.

Test traffic: organic SSDP/SmartThings discovery to 239.255.255.250:15600
(admin-scoped range, regular IGMP-managed group), source on the LAN,
receiver = WiFi client on a wifi-qcom AP (RouterOS 7.21.5, bridge with
igmp-snooping=yes and multicast-querier=yes, multicast-enhance=enabled).

Receiver membership confirmed on BOTH ends before capturing:

Windows client (SSDP service joins this group by default):

>netsh interface ip show joins

Interface 15: WiFi
Scope References Last Address
---
0 0 No 224.0.0.1
0 4 Yes 224.0.0.251
0 1 Yes 224.0.0.252
0 3 No 239.255.255.250

Router (IGMP snooping learned the group on the client's wifi port):

Result: frames to 239.255.255.250 still arrive at the WiFi client with
dst MAC 01:00:5e:7f:ff:fa — NOT converted to unicast. So the missing
conversion is not a 224.0.0.0/24 special-case artifact: it also affects
a registered, admin-scoped group with IGMP membership confirmed both at
the OS and at the bridge MDB level. Meanwhile IPv6 group traffic on the
same AP does get converted per-station (dst MAC rewritten to each
client's unicast MAC, dst IP still ff02::fb), as posted earlier.

Worth noting the documentation makes no exception either:

"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."

No carve-out for the link-local control block, no membership condition.
So on wifi-qcom, either the implementation is broken or the docs don't
describe the actual behavior. Summary of observed behavior:

IPv4 224.0.0.0/24 (mDNS etc.) -> not converted
IPv4 admin-scoped, IGMP-registered -> not converted
IPv6 ff02::fb -> converted per-station

Hope this helps narrow down SUP-180218.

[merlinthemagic7]

@erodriguez i have updated the ticket (SUP-180218) with your findings and a link to this post. Hopefully this adds momentum as we have been updating the ticket roughly every 2 months, but last response from MT was over a year ago (22/Jul/25).