Thanks for the replies so far.
Yes, for AX devices only, VLAN ID’s can be defined in the datapath and automatically propagated, but for AC devices and also if VLAN filtering is enabled on the CAP bridge, it does not seem to work. If no management VLAN is configured and VLAN filtering disabled, the automatic way works as you described.
The official Wifi documentation from Mikrotik has a sample under https://help.mikrotik.com/docs/display/ROS/WiFi#WiFi-CAPsMAN-CAPVLANconfigurationexample: for the “wifi-qcom-ac” driver. They state, that the automatic VLAN assignment does in this case not (yet?) work and you have to configure the VLAN assignment of the CAP radios manually, which I did in this example also for the “wifi-qcom” driver. The official example only uses two VLANs. A LAN and one for GUEST. In the provisioning rules in CAPsMAN, you can set a config for the master and for slaves, where multiple slaves are possible to pass on as a list. That the master config is assigned to the master Wifi interface is kind of logic. What I do not get so far is, how the right slave configuration is passed to the right manually created slave interface on the CAP. In my case it must assign the SSID “wt-iot” to “wifi-iot-24” and “wt-guest” to the interface “wifi-guest-24” and “wifi-guest-50”. It works reliably but in the CAPsMAN datapath we only define the bridge as copied from the mentioned example in the Mikrotik documentation. In my case the datapath is just named “DP_MANUAL” with the “bridge1” as it’s bridge and that is reference in the config under datapath. No VLAN ID allowed. Documentation says even: “Passing datapaths “MAIN/GUEST” from the start of the example to “wifi-qcom-ac” CAP would be misconfiguration, make sure to use datapath without “vlan-id” specified to such devices.”
By pressing the mentioned “Provisioning” button, the CAP configured and worked always successful. Did some reboots anyway.
To the Fast Transition topic. I half read the IEEE standard. The main use case for the feature seems to be, when IEEE 802.1x (RADIUS) is enabled, since authentication can take ages. In this case, the system (CAPsMAN) shall be configured to use “FT over DS” (Distributed System), the handover process goes over the backhaul ethernet and passes the authentication info over to the new AP as I assume. The device itself does then not need to re-authenticate on the new AP. In my WPA2 and WPA3 PSK scheme, I explicitly disabled “FT over DS”. This way the client has to ask around, if there is an access point with the same SSID and same “ft mobility domain” is present. If a better AP is found, the login info will be send “over the air” not over DS to the new access point which then can take the connection. From my view, it is not 100% necessary to have CAPsMAN in this special case, but have not the time to really dig that deep to verify. May it be a packet routing or ARP thing?