but that is not about drivers. that is about passing from CAPSMAN to CAP short message about PVID and dynamic appyling “add bridge=bridgeLocal interface=wifiX pvid=Y” on CAP. no drivers stuff here.
That’s not true, because this is already happening (dont believe me? Check for yourself)
But this interface also tries to dynamically assign VLAN to the client. ← Here’s the problem 
The driver doesnt support this.
This is NOT a capsman fix
We been here already quite a few times, I believe ?
Let's be happy we got wave2 drivers for otherwise potentially-to-be-abandonded AC gear.
And live with the quirks it comes with ...
4 Likes
As a heads-up.
It seems that the configless Huawei E3372h LTE Modem doesnt work in this release (it does work in 7.21rc6)
It does get setup. The MTU is wrong and there’s no incoming traffic at all.
ive already opened a ticket.
Also it seems like downgrading from 7.22beta1 to 7.21rc6 with rose breaks the partition table of my attached SSD.
There is a issue with e-mail sending with attachment(file).
When attaching file is sending empty e-mail, or like in the picture:
Non-abandoning gear is actually part of brand I think. Question which should be asked is completely different: why in first place Mikrotik was selling AC and XL AC with shitty drivers?
Dude, Mikrotik wrote in manual:
“Check the dynamically created interface and assign the PVID to the appropriate one”
example in manual (so-called Mikrotik handjob):
add bridge=bridgeLocal interface=wifi1 pvid=10
add bridge=bridgeLocal interface=wifi21 pvid=20
add bridge=bridgeLocal interface=wifi2 pvid=10
add bridge=bridgeLocal interface=wifi22 pvid=20
Once again: CAP part can be easily fixed to read PVID of DYNAMICALLY created interface from CAPSMAN and accordingly execute DYNAMICALLY and AUTOMATICALLY:
add bridge=bridgeLocal interface=wifi1 pvid=10
add bridge=bridgeLocal interface=wifi21 pvid=20
add bridge=bridgeLocal interface=wifi2 pvid=10
add bridge=bridgeLocal interface=wifi22 pvid=20
and later accordingly execute remove or sth like that (opposition of “add”) if needed. No rocket science. Once again: current state of affair is an abomination of the very idea of CAPSMAN. Imagine that for some reason you have a huge network, like 20 APs, and now you a huge pleasure in so-called Mikrotik hand-job if for some reason to need to change VLAN ids. You need to login to each CAP and CHANGE PVIDs manually. That is not how CAPSMAN was supposed to work.
4 Likes
I think that putting here output file ofexport
/export file=conf_file
backup is not easily readable
So please put here /export output of capsman and cap ac/ac xl
Now I see that: WiFi - RouterOS - MikroTik Documentation
Yet another minor one in non-existent /ip/reverse-proxy, in "SNI Rules" it should allow a comment= field:
Note the lack of a "Comment" field
well
looks like every version
LTS, RC, Beta have same SNMP problem
MIKROTIK-MIB::mtxrScriptRunOutput\[1\] = No Such Object available on this agent at this OID
I think you got something mixed up here.
Dynamic entries dont show up on an export.
Next time please check for yourself first
19 is the VLAN ID
I do not mix anything. Please paste here export output from AC/XL AC.
then explain to me:
What does an export have to do with dynamic assignment?
P.s. Im not saying it currently works. IT DOESNT.
But im saying it does require work on wifi-qcom-ac NOT capsman
And that is the problem. Thank you! CAP supposed to be dump device taking WHOLE configuration automatically from CAPSMAN. In case of CAPs AC/XL AC that is not case. We have to do mikrotik hand-job.
They weren’t. AC devices were still supported with the original drivers, but optional drivers were released (wifi-qcom-ac) that users could install when they wanted new WiFi features like fast roaming to be supported on the old AC equipment that did not support these in the old drivers.
With that new wifi-qcom-ac driver some modern features were added, but also some existing features were dropped.
Not really something you can complain about, because you can always go back to the original driver. It becomes worse with the new AX devices, because the original driver is no longer an option. But then, that full driver (wifi-qcom) has some of the features that the wifi-qcom-ac driver dropped.
Dude, Mikrotik wrote in manual:
“Check the dynamically created interface and assign the PVID to the appropriate one”
example in manual (so-called Mikrotik handjob):
add bridge=bridgeLocal interface=wifi1 pvid=10
add bridge=bridgeLocal interface=wifi21 pvid=20
add bridge=bridgeLocal interface=wifi2 pvid=10
add bridge=bridgeLocal interface=wifi22 pvid=20
Once again: CAP part can be easily fixed to read PVID of DYNAMICALLY created interface from CAPSMAN and accordingly execute DYNAMICALLY and AUTOMATICALLY:
add bridge=bridgeLocal interface=wifi1 pvid=10
add bridge=bridgeLocal interface=wifi21 pvid=20
add bridge=bridgeLocal interface=wifi2 pvid=10
add bridge=bridgeLocal interface=wifi22 pvid=20
and later accordingly execute remove or sth like that (opposition of “add”) if needed. No rocket science. Once again: current state of affair is an abomination of the very idea of CAPSMAN. Imagine that for some reason you have a huge network, like 20 APs, and now you a huge pleasure in so-called Mikrotik hand-job if for some reason to need to change VLAN ids. You need to login to each CAP and CHANGE PVIDs manually. That is not how CAPSMAN was supposed to work.
That is not about drivers, that is not about kernel-hardware interaction. That is about code in wifi-qcom-ac performing bunch of “add bridge=bridgeLocal interface=wifi22 pvid=20” and bunch of remove. That’s all.
i do agree on this part.
Its a little bit annoying to configure at the moment, but It's something i can live with for now 
(p.s. i did open a ticket about it recently)
1 Like
I wouldn’t call 20 APs a “huge” network but anyway, if they all have the same config (as they should, except identity), you can automate any number APs and chages via a simple bash script and a “for” or “while read” loop and some ssh - been there, done that for about 150 Mikrotiks spread around the coutry in one go 
Bigger problem IMO is that those AC devices are not very stable in some cases (https://forum.mikrotik.com/t/access-points-with-kernel-failure-im-going-crazy/). Btw, with 7.22beta1 I saw 3 reboots of a hap ac3 that I have upgraded for testing. Most stable version is still 7.13.5 but even with that there are kernel failures, only not so often.
I have only Mikrotik AC/XL AC and they work just fine – but what you say it seems that Mikrotik is not as good as it was in the past.