I expected CAPsMAN to become a fully-fledged "WLAN Controller".
So far - in version 6.18 - I've been missing way too many features and it really makes me sad.

• No roaming. There is no support for 802.11e, r, k or CCX. Or am I wrong?
• Other controllers take care of optimization and coordination of radio frequencies. I have never seen Cisco, HP, Ubiquiti AP's under auspices of their controllers landing at channel 8 or 9 (1-6-11 is a mantra in U.S. radio setting). Well, Mikrotik gives free rein to controlled AP's to autonomously and freely choose any channel. This is what some home Wi-Fi would do.
• Same story with radio transmit power. Set it manually or let it be.
• While other controllers take care about the firmware in AP's, this one doesn't synchronize RouterOS across the CAPs. It even doesn't report the ROS version for you.
• Adding/removing another wireless network to all CAPs isn't definitively a one-click action. You have to add individually each Virtual AP to a master interface of every AP.
• I can see and do actually less with the CAPsMAN than with The Dude. To name a few: actual map of the network, AP RouterOS version, IP address assigned to a client station by an external DHCP server. The Dude could also upgrade ROS (see above).
• It is kinda problem to physically locate an AP. You may need to maintain an extra sheet or rely on renaming the interfaces like room101:eduroam. I didn't find some easy to maintain compromise at least.
• Feedback information is inaccurate, you can learn that an AP that you've turned off from electricity more than hour ago is still marked running-ap.
• If you are trying to run some seriously secured network, you have to use either built-in EAP-TLS (which is very nice but hard to deploy) or authenticate by MAC addresses (which is just for laughs I guess). Unability to cooperate with any other EAP response from RADIUS server (assigning a VLAN) is lethal.
• Hybrid character of CAP configuration is crowned by the necessity to set antenna-gain only locally.

Some of these can be fixed easily, some of them are not bugs, they are features. But some of them are just IMHO plain wrong by design. Mikrotik should also resuscitate The Dude !

I will be more than happy to hear that I am doing something wrong and doing it another way will fix my problem.

It's version 1.0. It's prudent to wait for version 3.0.

I'll be interested to see how the product is maturing in a couple years though.

It'll get better. Keep in mind it costs about 1/8th the price of something like our meru that does what you mention.

* Currently no roaming standard added.
* Is it bad that CAPsMAN chooses a less used channel and not sticking to the 1-6-11 model?
* You can change the tx-power manually or leave it automatically
* We will add CAPs RouterOS reporting in the CAPsMAN
* If you use Provisioning with dynamic interface creation, then you can easy modify the provision rule with additional slave config and then remove all the CAPs and provision them again.
* we are planning in future to add additional features in The Dude so you could easy manage the CAPsMAN system
* The problem is to locate specific CAP in the CAPsMAN interface menu or in the building where exactly the CAP is located and how to identify it?
* CAP interface can't be in running state if the CAP is turned off for one hour. Support output file is needed from the CAPsMAN.
* We will try to implement the EAP response from RADIUS for vlan assigning in next revision of CAPsMAN
* Antenna-gain setting is taken from the CAP because it could be locked by lock package on each CAP and CAPsMAN is using that antenna-gain setting from CAP.

* Currently no roaming standard added.

Hopefully that will change?

* Is it bad that CAPsMAN chooses a less used channel and not sticking to the 1-6-11 model?

Versus the better, more modern method of sharing a single channel throughout the entire network, yes.. it is bad.

* You can change the tx-power manually or leave it automatically

This kind of ties in with the channel sharing.. APs should use management frames to talk to each other and develop a topology to put out the power they need to cover space without bleeding into other APs. IMHO.

* We will try to implement the EAP response from RADIUS for vlan assigning in next revision of CAPsMAN

Awesome!

* Currently no roaming standard added.

Honestly - if you implemented Cisco's proprietary CCX, if would be a real asset. Otherwise, the IEEE standards are not that widely implemented by manufacturers on stations yet (even after <10 years) so that is not so much painful. But that can change pretty fast, no only because of growing number of Apple devices. Google may be the accelerator. And Microsoft Windows has also suddenly brought up 802.11w...

* Is it bad that CAPsMAN chooses a less used channel and not sticking to the 1-6-11 model?
* You can change the tx-power manually or leave it automatically

Just one question: can you guarantee in a reasonable manner that your own system doesn't create frequency overlaps within your system?

* We will try to implement the EAP response from RADIUS for vlan assigning in next revision of CAPsMAN

This made me very happy!

BTW: you've probably heard that Wi-Fi manufacturers recommend to reduce/limit the number of SSID's in favor of other ways to separate users...

* We will try to implement the EAP response from RADIUS for vlan assigning in next revision of CAPsMAN

All I can see in "What's new in 6.19 (2014-Aug-26 14:05):" regarding wireless is "improvements for nv2 and 802.11ac". Without irony: are revisions of CAPsMAN intended to correlate with revisions of RouterOS itself? If not, when can we actually expect this feature?

Thank you in advance

* We will try to implement the EAP response from RADIUS for vlan assigning in next revision of CAPsMAN

All I can see in "What's new in 6.19 (2014-Aug-26 14:05):" regarding wireless is "improvements for nv2 and 802.11ac". Without irony: are revisions of CAPsMAN intended to correlate with revisions of RouterOS itself? If not, when can we actually expect this feature?

Thank you in advance

No, Uldis meant what he said, we will have an improved CAPsMAN in some future RouterOS release. Not next RouterOS version. We are already working on something much improved.

Not next RouterOS version.

Couldn't you guys do just an incremental patch? I need it urgently (for "technically political" reasons).

Not next RouterOS version.

Couldn't you guys do just an incremental patch? I need it urgently (for "technically political" reasons).

the new CAPsMAN is simply not ready.

Not next RouterOS version.

Couldn't you guys do just an incremental patch? I need it urgently (for "technically political" reasons).

the new CAPsMAN is simply not ready.

And in a standalone version?

We need CAPsMAN sooo badly.. Please make it work just a little bit better. We just need to be able to configure EAP-TLS. No new features required. I've read your posts that new CAPsMAN is not quite ready. I respect that. But can you make "develepers" edition available? We need EAP-TLS badly.

Thanks.