I've come across a very specific, but possibly quite critical problem with MacBooks connected as clients to Mikrotik APs with WMM enabled/required, running the latest ROS 6.41 (stable). The problem seems to be located somewhere in the interplay of the Mikrotik WMM implementation using priorities and Mac OS. If I have the firewall set specific priorities (strangely enough only with 1, 3, 4, or 6) on packets that go out to the MacBook, the MacBook doesn't seem to be able to make sense of them. I can see them go through the sniffer on the AP, but either they don't reach the MacBook correctly or they get discarded there.

Now that I've written them down, there seems to be a pattern with the strange specificity of the numbers, though. 1, 3, 4 and 6 are precisely those numbers where the queue changes. At 1 (from 0) from best effort to low priority queue, at 3 back to best effort again, then at 4 to high prio, finally at 6 to top prio. It's too specific to be mere coincidence, I guess.

It should be possible to reproduce this behavior simply by setting up an AP with WMM enabled/required, bridge settings "Use IP Firewall" and "...For VLAN" both active, and a single firewall rule like:

/ip firewall mangle action=set-priority chain=postrouting new-priority=3 passthrough=yes

Test with all eight priorities (0-7), and the described pattern should emerge. By the way, iOS seems to be unaffected! I also don't think it depends on the Routerboard hardware, as for me the same problem exists on a hAP ac, a hAP ac lite and a wAP ac. I have also tested with two seperate MacBooks, both same behavior.

Maybe we have a real generic problem here and not some even more specific thing with my network. It seems so random. Maybe someone could try and reproduce this with their devices?

Did some more tests on a different device in a whole separate network. Same thing happens generally.

I have some new observations to share, though. There seems to be some variability on which specific priorities cause problems. When AMPDU functionality is disabled, prios 1 and 3 seem to not work at all, no matter what I try. 0, 2 and 5 always do work. 6 and 7 are outliers. Sometimes they'll start to work right away, sometimes it takes a while after which they will begin and continue working.

Interestingly, with AMPDU active for all priorities, the behavior changes somewhat. Now, for some reason, prios 1,4, and 6 work without problem. 3 will not work at all. For the others, the process becomes more unpredictable as it will begin and stop working several times (not working most of the time).

An Android device I have here seems to be, again like iOS, completely unaffected.

Add: Windows also unaffected. It really seems to be only Mac OS.

Would that not be a Mac OS problem you need to take up with Apple?
Try on another network with WMM...

Well who am I to talk to Apple? I wouldn't even know where to write to. On the other hand, if MT could identify a problem here, they could either fix a potential bug if it's on their side, or they could maybe interact with Apple in order to get something going there.

That said, I'm looking to try the same thing later with an OpenWRT/LEDE device as AP. If it persists there, it could be a Linux thing.

Just tried on current LEDE (former OpenWRT) release 17.01.4. The Linux kernel in there is of version 4.4.92. I have set up separate networks to route through, so that firewall gets active. WMM is enabled on WiFi and the following firewall rule is running on all packets: iptables -t mangle -A POSTROUTING -j DSCP --set-dscp 24. This maps to priority 3, which never worked with RouterOS. The firewall packet counter tracks the data transmitted, so I think it actually does classify packets.

This works! So I still think we really have a problem here specifically between Mikrotik and Mac OS devices.