In this case, if you still systematically cannot get higher than MCS#1/79 Mbit/s on Tx, the issue is not that the MCS would not be permitted but rather that there is some issue in MCS negotiation between the Mikrotik and the particular device.
[quote=“, post:2, topic:116478”]
… when you set vlan-mode=> no-tag > on the wireless interface, the binding rule will ensure that tagless packets from the wireless interface wil be tagged when getting to the bridge with that rule’s pvid value;
[/quote]
With > “no-tag” > I am able to connect with my MacBook to the vAP by wireless (with “use-tag” I am not …).
To be sure, your > explanation > means: data-packets > un-tagged > sent out from my MacBook (wireless-client) through the radio to the vAP50-interface (as a kind of “access-port”) where tagless data-packets get their tags with e.g. VLAN ID 50 because of, the PVID is set to 50 … These now tagged data-packets are forwarded from these port, trough the bridge to the ether-port on which a trunk-cable is connected to … And vice-versa ?
I believe so. But what surprises me is that if you set vlan-mode=use-tag and vlan-id=N already at the wireless interface, it does not work. I admit that I use this in cAPsMAN wireless access list (where certain clients on the same AP with the same SSID get individual WPA passphrases and are placed into a “VIP” VLAN), so maybe it behaves properly in this case and weird if you set it up on a “directly controlled” wireless interface (i.e. without cAPsMAN).
The 802.11 protocol family does not support VLANs so yes, all frames coming from the air are tagless and only get tagged at the “wired side of the wireless chip”, while tagged framess coming from the wire are untagged before being forwarded to the “wireless side”.
Bridge-Port Settings of vAP …
[quote=“, post:2, topic:116478”]
****> As for the ingress filtering > etc> . settings, my > guess > is that they are only relevant for physical ports so it is > not important how you set them for wireless interfaces> .
[/quote]
If I look to the “Bridge VLAN Filtering” here:
https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_VLAN_Filtering
/interface bridge > port
pvid > means “Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to”
Doesn’t that mean, if the pvid is set to 50 on this port, that, if the > untagged > ingress traffic comes from my MacBook to the vAP50-interface (port) where pvid=50 is set to tag data-packets is not relevant … ONLY in case of wired connections ?
PVID requires a value … If I set 1 instead of 50 what does that causes or is that also irrelevant because not linked in case of wireless ports ?
Is there someone who is able to answer it by 100% ?
I think that that guy’s name is Herr Experiment 
My understanding is that if you configure “/interface bridge port”'s pvid to N, then tagless packets coming from the wireless chip are getting tagged with VLAN ID N when entering the bridge, and packets tagged with VLAN ID N are getting untagged on egress from the bridge towards the wireless chip.
The problem is that when using cAPsMAN, you choose the bridge to which the wireless chip should be connected in the cAPsMAN’s configuration for that wireless interface, so the “/interface bridge port” rule is created “autodynamically” from that configuration. When you configure wireless/virtual interfaces directly, you can choose a bridge for the WDS mode in the interface configuration, but you have to create manually the rule in “/interface bridge port” to bind the “basic” part of the interface (in your case, the AP) to a bridge.
So at least when using cAPsMAN, it is irrelevant where you set the VLAN ID you want your wireless packets to be tagged with at the ethernet trunk:
- you can set the correct ID already in the “/interface wireless” or “/interface virtual” configuration together with “vlan-mode=use-tag”, and in that case, the rule in “/interface bridge port” should have a different pvid value and the frames will be tagged/untagged by the software handling the wired side of the wireless chip (this is the way “VIP” clients are treated),
- or you can configure the “/interface wireless” or “/interface virtual” with “vlan-mode=no-tag”, and in that case, the pvid value of the rule in “/interface bridge port” decides which VLAN ID the frames coming from the wireless chip will be tagged with while entering the bridge (which is the way my “ordinary” wireless clients are treated except that the rule is created autodynamically).
But I also assume that if vlan-mode in the “/interface wireless(virtual)” configuration is set to use-tag, tagless packets coming from the bridge are ignored. So if you use vlan-mode=use-tag in the wireless configuration and set the same VLAN ID both as vlan-id in the wireless configuration and as pvid in the “/interface bridge port” rule, the frame coming from the bridge gets untagged by the bindnig rule and then ignored by the wired side of the wireless chip.
[quote=“, post:2, topic:116478”]
You’ve written somewhere that you have created an /interface vlan with vlan-id=1; I believe it is not necessary because you can use directly the /interface bridge with pvid=1. I was even not sure whether the existence of /interface vlan doesn’t cause some issue as it has the same MAC address as the brdge itself, so I’ve tested and it did make my router inaccessible.
[/quote]
You are right with the same MAC …
The vlan1 is dynamically created after Bridge Filtering is activated …
Wait, that’s another thing. There is a certain type of virtual interface called “vlan”, whose parameters are the bridge to which its tagged side is connected and the VLAN ID which it interfaces to its tagless side. And such interface is never created dynamically AFAIK. What does get created dynamically is a row in the “/interface bridge vlan” table if vlan-filtering is set to yes on the bridge and
- some “/interface bridge port” rule, static or dynamic, exists with pvid set to that VLAN ID
- or some /interface vlan exists and its configuration refers to the bridge and its vlan-id is set to that VLAN ID,
- or the bridge itself’s pvid is set to that VLAN ID
