Note: CAPsMAN v2 is NOT compatible with current CAPsMAN v1 (CAPsMAN v1 CAP devices will not be able to connect to CAPsMAN v2 and CAPsMAN v2 CAP devices will not be able to connect to CAPsMAN v1). It means that both CAPsMAN and CAP devices should have wireless-cm2 package installed in order to make CAPsMAN v2 system to work.
If you want to try out the CAPsMAN v2 upgrade all the CAPs and the CAPsMAN to latest RouterOS version and install wireless-cm2 package.
CAPsMAN v2 features:
CAPsMAN automatic upgrade of all CAP clients (configurable)
improved CAP<->CAPsMAN data connection protocol
added “Name Format” and “Name Prefix” setting for Provision rules
improved logging entries when client roams between the CAPs
added L2 Path MTU discovery
Upgrade options from v1 to v2:
Option1: Install a new temporary CAPsMAN v2 router in same network where the current CAPsMAN router is and start upgrading CAPs with wireless-cm2 package. All CAPs with the v2 will connect to the new temporary CAPsMAN v2 router. After every CAP is upgraded to v2, upgrade your current CAPsMAN to v2 and then turn off the temporary CAPsMAN v2 router.
Option2: Upgrade your CAPs and then CAPsMAN to v2 at the same time. In this case you could have little more downtime unless you schedule all the CAPs to reboot/install at the same time.
Wireless-cm2 package can be downloaded from the Mikrotik download page under release candidate: http://www.mikrotik.com/download
CAPsMAN is getting better and better! We can now manage hundreds of access points with ease.
I would like to see more options available in CAPsMAN configurations like:
NV2 with encryption
Management Frame Protection
Remote Scanning, Freq. Usage, Snooper
WMM Support
Also, the interface naming format is great and I would like to suggest another field.
I think prefix identity and SSID would be awesome. What do you think?
For example specify such info: “package-path: /nova”
And then upload files to the nova folder
[uldis@CAPsMAN] /file> print
# NAME TYPE SIZE CREATION-TIME
0 nova directory nov/05/2014 12:17:47
1 nova/wireless-cm2-6... package 884.1KiB nov/05/2014 12:17:43
2 nova/routeros-mipsb... package 9.7MiB nov/05/2014 12:17:48
Also note that you will need to wait till the RouterOS v6.22rc8 till you could test the upgrade feature as to make the CAP to connect it should have v6.22rc7 already.
You will see such entrie in the log file when the client connects/roams to some other CAP:
15:20:44 caps,info 00:00:00:00:00:00@cap1 disconnected, registered to other interface
But then, if CAPsMAN v1 was, shouldn’t you perhaps call this one something different? Like “MTCAPsMAN” for example.
I mean, what if CAPWAP gets a revision (let’s call it tentatively CAPWAP.Next) that doesn’t have those limitations while still being compatible with the current CAPWAP protocol? You make CAPsMAN v3 which is not compatible with v2, but is compatible with v1, because v3 is CAPWAP.Next compliant, while v2 is not?
I have a recommendation for the next release - check provisioning configuration for corrupt or invalid settings and advise user when upgrading. I had to remove and add a provisioning rule which became corrupt, but it looked normal from the cli and winbox.
If not for upgrade, maybe a button to check for any settings marked as invalid or e.g. Rule with interface configured that does not exist any more. Important to check even the disabled settings and the entire device.
I would like to propose the following; An option in radio and an option in provisioning profile which can over-ride the main cap upgrade rule.
Two reasons for this:
Having capsman2 and cap on the same routerboard, to prevent reboot of the controller when new software is uploaded.
More granular control over software updates.
Another feature would be for setting software upgrade policy to none, but in the section that lists registered CAPs, have a button to upgrade the device. This could also be done for profiles to apply upgrade to CAPs using the profile selected, or groups of CAPs if groups get implemented.
Another feature:
The ability to have groups of radio mac address for provisioning. For example, so i can groups of radios for extension channels, some get eC eCee, some get Ce eeCe etc
For some reason, based on 6.22rc7 and 6.22final both the provisioning feature did not provision random channels, it only provision the lowest channel available of the country-settings.