Wifi-qcom: selective multicast blocking between same-SSID clients (unicast must remain functional)

Is there a way to block a specific IPv4 multicast group between two wifi-qcom clients on the same SSID, while still allowing direct unicast traffic between them?

Setup: hAP ax S, RouterOS 7.23.1, wifi-qcom. Single VLAN-aware bridge, one VLAN per SSID, SSID as bridge port.

Tried so far, none give selective behavior (either nothing blocks, or unicast breaks too):

  • Bridge filter, chain=forward, dst-mac-address matching the multicast MAC (both generic range and exact group) - counters stay at 0, rule never matches

  • Bridge filter, chain=input - blocks unicast too

  • IGMP snooping + drop on ip-protocol=igmp - blocks unicast too

  • client-isolation=yes - blocks unicast too (it's all-or-nothing)

  • fast-forward=no on the bridge - no change

  • IP firewall filter on 224.0.0.0/4 - counters stay at 0, traffic never reaches L3

Looks like intra-SSID client-to-client forwarding (both unicast and multicast) happens below the bridge filter layer on wifi-qcom, so neither bridge filter nor IP firewall ever sees it.

Is this expected behavior, or is there a setting we're missing?

Is it an AI problem just sent by you?

Who uses "hypotesis" during typical conversation?

It is very obviously generated with an LLM. Just look at the emdashes the expensive next word predictors like so much.
And it is a typical example of sloppy AI bloat. The wall of text adds nothing to the question.

The post could just have been „Is there a way to block intra-SSID multicast for a specific IPv4 multicast destination?“

Writing this would have taken less time than writing the LLM prompt.

And in general: I can‘t be bothered to read something the „Author“ couldn’t be bothered to write.

it has been rhetorical question asked. Whole post looks and smells as AI generated.
As you pointed out: preparing such a post takes more time then writing it bi yourself but looks as having more "pro" or "technical style".

An of course there is no reflection on Forum rules

Fair point, original post was way too long. Edited it down to a short version above. Sorry for the noise.

So the short answer: it's not possible. Station-to-station traffic (when both stations connect to same BSSID) is handled entirely by wifi/wireless driver ... and that one has only one related setting: client isolation. Which is actually about unicast traffic.

I have been thinking it would be nice to be able to block it at the wifi level,
but be able to send received wifi traffic back to the wifi at the cpu level.
(So you can do things like clean air filters)

Actually, the old wireless driver could do this. It is the default-forwarding setting, which determines if the wireless driver forwards frames from one client to the other, or not. When not, it forwards them to the bridge where the wifi interface is a member, and you can control what happens using bridge filters.

It would be a feature request to have this capability in the qcom driver as well, but I guess MikroTik are not going to patch the driver anymore for such things and it would only be possible when the driver already has that capability but they haven't got around to allowing that setting in the UI.