From help.mikrotik.com:
This topic is about the "vlan-mode" and "vlan-id" parameters of the access list.
I am using this with the classic wireless driver (not wifiwave2) and RouterOS v7.9.
Wireless interface is configured with "vlan-mode: use tag" and "vlan-id: dummy value".
Observation: client that is matched in the access list and gets a valid VLAN assigned, indeed gets connected to that VLAN for directed traffic and broadcast (ARP, DHCP).
But it does NOT receive the multicast traffic on that VLAN, e.g. Chromecast or IPv6 SLAAC.

When I set the vlan-id of the wireless interface to some valid VLAN, all clients connected and matched receive the multicast traffic from THAT VLAN instead of their own.
(resulting in invalid IPv6 address being assigned)

Does anyone else have experience with dynamic VLAN assignment for wireless? I have it in place to reduce the number of WiFi SSIDs / virtual interfaces.
In fact I am not using access-list but instead use MAC authentication via RADIUS and user-manager, with settings like this in a user-manager group:
That has the same effect as setting vlan-id via an access list, and the resulting issue is exactly the same.

Only used VLAN in access lists so far. Wifi interface is set to "VLAN Mode = no tag, VLAN id=1", access list defines "use tag, VLAN id" to be used.
Never tried multicast (like Chromecast), as the VLAN in my case is different, so it would not work anyway.

One of the questions is who/what stopped the multicast? The bridge (flood multicast) , or the WLAN default setting ???
No idea. No test case here.

Does this need PIM? Like in viewtopic.php?t=158699&hilit=pim#p779888 did?
There are changes in IGMP snooping in version 7.7 ... https://help.mikrotik.com/docs/pages/vi ... d=59277403
Unknown territory.

As I mentioned, I tried it both with access-list and with radius authentication, but the result is the same. So the issue is in the handling of the assigned VLAN, not in the mechanism that assigns it.
I think no special treatment of multicast should be required.
E.g. I have a separate VLAN where my TVs are (connected wired to ports that are untagged for that VLAN), and I do a wireless connect of a phone or chromebook and assign it the same VLAN using user-manager, I expect that these devices see eachothers multicast without any PIM or similar. That should only be required when the devices are on different VLANs, which they are not.
And it all worked before I "optimized" my WiFi. Before I had 4 different SSIDs (virtual wireless interfaces) each configured with "use tag" and the proper VLAN tag, and in that case it all works as it should. But after I changed that to 1 SSID and dynamically assigned VLAN, it stopped working.
The bridge config is unchanged. It is a VLAN-filtering bridge with tagged VLAN on the wlan interfaces, and tagged and untagged VLAN on other ports.

It is also interesting to observe the behavior of the VLAN setting on the wireless interface. E.g. when setting it as you mention (no tag), the client will receive the multicasts from all VLANs, with tag. But of course it is not looking at tagged traffic (except maybe Windows, but I have no Windows machines here).
When setting it to "use tag" and then one of the existing VLANs, it will receive the multicasts from THAT VLAN, without tag. Independent of the VLAN assigned via access-list or radius.
So now I have set the wireless interface to "use tag" and an unused VLAN tag, so at least the clients to not receive wrong multicasts. But they still do not receive the multicasts belonging to their VLAN!

I think the filtering is happening in the wireless interface, not in the bridge. Because this functionality was already available BEFORE we had vlan-filtering bridges. But I may be wrong...
It looks like the wifi driver, when a client is on a dynamic VLAN, checks the MAC address and if it is the one of that client OR it is FF:FF:FF:FF:FF:FF (broadcast) it forwards the traffic. I presume that because ARP and DHCP (v4) still work.
But when the MAC is a Multicast MAC (x1:xx:xx:xx:xx:xx) some earlier shortcut is taken that only looks at the interface VLAN config and not at the dynamic clients.
When a client has a dynamic VLAN, the wireless interface should forward all traffic with a MAC with least significant bit of the first byte set. That already includes FF:FF:FF:FF:FF:FF so that will no longer be a special case.

Interesting diagnosis !

But "multicast" .... what is the wifi driver doing with this? Sending like a beacon at that low basic rate?

""Real" multicast is a form of broadcast at layer-2, and Wi-Fi can do that (send to a multicast group instead of individual unicast MAC addresses), but you are limited to the lowest available speed on the AP" https://networkengineering.stackexchang ... -over-wifi

What is the multicast helper doing with this? Default setting is equal to off, as stated in the wiki.
What happens if multicast helper set to "full" ?

Can such real multicast be used when cients are connected to different VLAN id ? Shouldn't it be converted to some filtered unicast, as real multicast would address all connected devices.

And multicast over wifi , has a performance issue: viewtopic.php?t=186859&hilit=multicast#p966494
viewtopic.php?t=186859&hilit=multicast#p966540

Nobody else using dynamic VLAN assignment for wireless?
This problem is driving me nuts... I would at least want to hear if someone can confirm this problem or if I maybe have some subtle error in my config that causes this.
Even support has not replied to my ticket SUP-114289 after a month...

It is also interesting to observe the behavior of the VLAN setting on the wireless interface. E.g. when setting it as you mention (no tag), the client will receive the multicasts from all VLANs, with tag. But of course it is not looking at tagged traffic (except maybe Windows, but I have no Windows machines here).
When setting it to "use tag" and then one of the existing VLANs, it will receive the multicasts from THAT VLAN, without tag. Independent of the VLAN assigned via access-list or radius.
So now I have set the wireless interface to "use tag" and an unused VLAN tag, so at least the clients to not receive wrong multicasts. But they still do not receive the multicasts belonging to their VLAN!

Well actually after all, some expected behaviour. My guess on what happens ....
A Wireless interface 'no tag' in the meaning of no-tag-processing and no filtering, acting just like a dumb bridge/switch (with VLAN filtering OFF), will receive and send everyting 'as is' independent of VLAN tag or missing TAG in the packet header.
This is what I use in the PtP and PtMP connections, sending all VLAN's over these links.

The access list with TAG and VLAN number set, will process the TAG in the wifi driver (filtering the packets of that VLAN, removing TAG before sending, adding TAG when receiving) based on the access list for that specified MAC (unicast) address entry.
What with multicast/broadcast for a MAC in the access list? AFAIK there is no entry for the multicast MAC address in the access list. There can be multiple access list entries with different VLAN settings for that WLAN interface and SSID for different MAC addresses.
For unicast it is clear which one in the access list to use, based on the MAC address.
For multicast/broadcast there can be multiple settings in the access list entries for different clients. How can the driver know what to use? Maybe the interface default is then the only option.
The only way the driver can pick and handle the correct VLAN, is when it is unicast. So maybe the multicast helper should always be on "full" , so that all multicasts/broadcasts are converted to unicast.
I wonder , if that multicast helper is smart enough to use the access-list VLAN settings, when splitting a multicast in multiple unicasts, which could (????) be different VLAN id's or not (??????)

The multicast helper configuration (on or off) has no effect on this problem...
Of course the handling of VLAN tags (inside the wifi driver) requires additional processing. Not by looking at the access list every time, but by registering the VLAN determined from the access list at time of connection with the connection entry, and thus keeping track of who is on which VLAN.
And it seems to be PARTLY implemented, as the broadcast traffic like ARP is correctly handled. So a copy of traffic to MAC address FF:FF:FF:FF:FF:FF is sent to all stations on that VLAN, not only to the MAC specified in the access list.
So I think the piece of code that checks for MAC address FF:FF:FF:FF:FF:FF has to be modified, and only check for the low bit in the first byte being set (or the 2 lowest bits).
That matches that broadcast traffic, and also all multicast traffic. That will fix the problem.

Don't think it is impossible or unusual. The same feature on Unifi APs works fine!

Nobody else using dynamic VLAN assignment for wireless?
This problem is driving me nuts... I would at least want to hear if someone can confirm this problem or if I maybe have some subtle error in my config that causes this.
Even support has not replied to my ticket SUP-114289 after a month...

I've been lazy and dosame today: VLAN per SSID...so I can't help. But a single SSID with dynamic VLAN is, theoretically, a better approach (per-client control + less wifi beacons). So following with interest here.

Does seem like it should work same as the "use-tag" and do same with MAC/RADIUS for multicast as all other forwarded packets... That seem like a bug. No PIM or proxy should be needed, as it should be same segment per the tagging...

Out of curiosity, anyone know if this works (or should work) in wifiwave2?

Out of curiosity, anyone know if this works (or should work) in wifiwave2?

Only have release notes info (no ax device purchased yet)
Release notes 7.7

*) wifiwave2 - added option to set per-client vlan-id in access list (only supported on 802.11ax interfaces) (CLI only);

I fully agree. I don't have any equipment capable of running wifiwave2 (I have a 4011 but cannot afford to lose 2.4GHz) so I cannot test that.
Maybe you can do an experiment
When you have several APs running on VLANs (using the vlan tag option in the Wireless interface) you can just add a single access-list item that forces a single client on to another network (assign another VLAN tag) and see if that still works OK with e.g. IPv6, chromecast and other multicast applications.
That is an easy test that does not require rebuilding the entire Wireless config as I did (and finding about the problem after it is all finished).

The multicast helper configuration (on or off) has no effect on this problem...

Well, that was wrong...
I had wrongly assumed that the setting "default" for multicast helper would be OK for typical multicasts like IPv6 RA or Chromecast, as with that setting it works OK when a single VLAN is configured for the wireless interface. I had it working all the time with that before I changed to dynamic VLAN assignment.
But now after what bpwl wrote I tested again and it turns out that with multicast-helper=full it actually works! And that the "default" setting for multicast-helper is actually the same as "disabled". Who invented that???
I had tested if disabling the multicast helper would solve the problem, and it didn't. But actually I was not changing anything by switching between "default" and "disabled".

Now, with the setting multicast-helper=full I do get a correct IPv6 address again, and also the chromecast is working (between a device on a dynamically assigned VLAN and a wired device on an untagged port on that same VLAN).

So this is a workaround. I still think it is a bug, for such low-volume "annoucement" multicast traffic it should work without a multicast helper as it also works for broadcast.

So this is a workaround.

IMO requirement for full bulticast helper in such case is understandable. What multicast helper does is to add more of awareness of wireless clients to AP ... so that broadcasts/multicasts are delivered to each of (sleeping) clients via unicast. When clients are individually cast into separate VLANs (either per manually configured ACLs or by Radius responses), AP's awareness of clients is even more important as it needs to route different broadcasts/multicasts (from different VLANs) to correct clients ... so not only translating broadcasts/multicasts to unicasts but also per client VLAN membership.

Well thinking about it more, converting multicast to unicast may indeed be the only way to get multicast working on a single WiFi SSID with dynamically assigned VLANs....
Maybe it would be better when the multicast-helper setting "default" recognized this and enabled multicast helper for those clients with dynamic VLAN.