Manual:CAPsMAN

Overview

Controlled Access Point system Manager (CAPsMAN) allows centralization of wireless network management and if necessary, data processing. When using the CAPsMAN feature, the network will consist of a number of 'Controlled Access Points' (CAP) that provide wireless connectivity and a 'system Manager' (CAPsMAN) that manages the configuration of the APs, it also takes care of client authentication and optionally, data forwarding.

When a CAP is controlled by CAPsMAN it only requires the minimum configuration required to allow it to establish connection with CAPsMAN. Functions that were conventionally executed by an AP (like access control, client authentication) are now executed by CAPsMAN. The CAP device now only has to provide the wireless link layer encryption/decryption.

Depending on configuration, data is either forwarded to CAPsMAN for centralized processing (default) or forwarded locally at the CAP itself (#Local_Forwarding_Mode).

CAPsMAN features

• RADIUS MAC authentication
• WPA/WPA2 security
• TBA

MISSING CAPsMAN features

• Nstreme AP support
• Nv2 AP support
• TBA

CAPsMAN v2

We have CAPsMAN v2 ready for testing.

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.

Requirements

CAPsMAN works on any RouterOS device from v6.11, wireless interfaces are not required (since it manages the wireless interfaces of CAPs)

CAPsMAN v2 is working starting from RouterOS v6.22rc7.

CAP device should have at least Level4 RouterOS license

CAP to CAPsMAN Connection

For the CAPsMAN system to function and provide wireless connectivity, a CAP must establish management connection with CAPsMAN. A management connection can be established using MAC or IP layer protocols and is secured using 'DTLS'.

A CAP can also pass the client data connection to the Manager, but the data connection is not secured. If this is deemed necessary, then other means of data security needs to be used, e.g. IPSec or encrypted tunnels.

CAP to CAPsMAN connection can be established using 2 transport protocols (via Layer 2 and Layer3).

• MAC layer connection features:
  • no IP configuration necessary on CAP
  • CAP and CAPsMAN must be on the same Layer 2 segment - either physical or virtual (by means of L2 tunnels)
• IP layer (UDP) connection features:
  • can traverse NAT if necessary
  • CAP must be able to reach CAPsMAN using IP protocol
  • if the CAP is not on the same L2 segment as CAPsMAN, it must be provisioned with the CAPsMAN IP address, because IP multicast based discovery does not work over Layer3

In order to establish connection with CAPsMAN, CAP executes a discovery process. During discovery, CAP attempts to contact CAPsMAN and builds an available CAPsMANs list. CAP attempts to contact to an available CAPsMAN using:

• configured list of Manager IP addresses
• list of CAPsMAN IP addresses obtained from DHCP server
• broadcasting on configured interfaces using both - IP and MAC layer protocols.

When the list of available CAPsMANs is built, CAP selects a CAPsMAN based on the following rules:

• if caps-man-names parameter specifies allowed manager names (/system identity of CAPsMAN), CAP will prefer the CAPsMAN that is earlier in the list, if list is empty it will connect to any available Manager
• suitable Manager with MAC layer connectivity is preferred to Manager with IP connectivity

After Manager is selected, CAP attempts to establish DTLS connection. There are the following authentication modes possible:

• no certificates on CAP and CAPsMAN - no authentication
• only Manager is configured with certificate - CAP checks CAPsMAN certificate, but does not fail if it does not have appropriate trusted CA certificate, CAPsMAN must be configured with require-peer-certificate=no in order to establish connection with CAP that does not possess certificate
• CAP and CAPsMAN are configured with certificates - mutual authentication

After DTLS connection is established, CAP can optionally check CommonName field of certificate provided by CAPsMAN. caps-man-certificate-common-names parameter contains list of allowed CommonName values. If this list is not empty, CAPsMAN must be configured with certificate. If this list is empty, CAP does not check CommonName field.

CAP Auto Locking to CAPsMAN

CAP can be configured to automatically lock to particular CAPsMAN. Locking is implemented by recording certificate CommonName of CAPsMAN that CAP is locked to and checking this CommonName for all subsequent connections. As this feature is implemented using certificate CommonName, use of certificates is mandatory for locking to work.

Locking is enabled by the following command:

[admin@CAP] > /interface wireless cap set lock-to-caps-man=yes

Once CAP connects to suitable CAPsMAN and locks to it, it is reflected like this:

[admin@wtp] > /interface wireless cap print
...
        locked-caps-man-common-name: CAPsMAN-000C424C30F3

From now on CAP will only connect to CAPsMAN with this CommonName, until locking requirement is cleared, by setting lock-to-caps-man=no. This approach needs to be used if it is necessary to force CAP to lock to another CAPsMAN - by at first setting lock-to-caps-man=no followed by lock-to-caps-man=yes.

Note that CAP can be manually "locked" to CAPsMAN by setting caps-man-certificate-common-names.

Auto Certificates

To simplify CAPsMAN and CAP configuration when certificates are required (e.g. for automatic locking feature), CAPsMAN can be configured to generate necessary certificates automatically and CAP can be configured to request certificate from CAPsMAN.

Automatic certificates do not provide full public key infrastructure and are provided for simple setups. If more complicated PKI is necessary - supporting proper certificate validity periods, multiple-level CA certificates, certificate renewal - other means must be used, such as manual certificate distribution or SCEP.

CAPsMAN has the following certificate settings:

• certificate - this is CAPsMAN certificate, private key must be available for this certificate. If set to none, CAPsMAN will operate in no-certificate mode and none of certificate requiring features will work. If set to auto, CAPsMAN will attempt to issue certificate to itself using CA certificate (see ca-certificate description). Note that CommonName automatically issued certificate will be "CAPsMAN-<mac address>" and validity period for will be the same as for CA certificate.
• ca-certificate - this is CA certificate that CAPsMAN will use when issuing certificate for itself if necessary (see certificate description) and when signing certificate requests from CAPs. If set to none, CAPsMAN will not be able to issue certificate to itself or sign certificate requests from CAPs. If set to auto, CAPsMAN will generate self-signed CA certificate to use as CA certificate. CommonName for this certificate will take form "CAPsMAN-CA-<mac address>" and validity period will be from jan/01/1970 until jan/18/2038.

When CAPsMAN will auto-generate certificates, this will be reflected like this:

[admin@CM] /caps-man manager> pr
                   enabled: yes
               certificate: auto
            ca-certificate: auto
  require-peer-certificate: no
     generated-certificate: CAPsMAN-000C424C30F3
  generated-ca-certificate: CAPsMAN-CA-000C424C30F3

And certificates:

[admin@CM] /certificate> print detail
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, 
A - authority, I - issued, R - revoked, E - expired, T - trusted 
 0 K   A T name="CAPsMAN-CA-000C424C30F3" common-name="CAPsMAN-CA-000C424C30F3" key-size=2048 
           days-valid=24854 trusted=yes 
           key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign 
           serial-number="1" fingerprint="69d77bbb45c50afd2d6c1785c2a3d72596b8a5f6" 
           invalid-before=jan/01/1970 00:00:01 invalid-after=jan/18/2038 03:14:07 

 1 K   I   name="CAPsMAN-000C424C30F3" common-name="CAPsMAN-000C424C30F3" key-size=2048 
           days-valid=24854 trusted=no key-usage=digital-signature,key-encipherment 
           ca=CAPsMAN-CA-000C424C30F3 serial-number="1" 
           fingerprint="e853ddb9d41fc139083a176ab164331bc24bc5ed" 
           invalid-before=jan/01/1970 00:00:01 invalid-after=jan/18/2038 03:14:07 

CAP can be configured to request certificate from CAPsMAN. In order for this to work, CAP must be configured with setting certificate=request and CAPsMAN must have CA certificate available (either specified in ca-certificate setting or auto-generated).

CAP will initially generate private key and certificate request with CommonName of form "CAP-<mac address>". When CAP will establish connection with CAPsMAN, CAP will request CAPsMAN to sign its certificate request. If this will succeed, CAPsMAN will send CA certificate and newly issued certificate to CAP. CAP will import these certificates in its certificate store:

[admin@CAP] > /interface wireless cap print
...
              requested-certificate: cert_2
        locked-caps-man-common-name: CAPsMAN-000C424C30F3
[admin@CAP] > /certificate print detail 
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, 
A - authority, I - issued, R - revoked, E - expired, T - trusted 
 0       T name="cert_1" issuer=CN=CAPsMAN-CA-000C424C30F3 common-name="CAPsMAN-CA-000C424C30F3" 
           key-size=2048 days-valid=24837 trusted=yes 
           key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign 
           serial-number="1" fingerprint="69d77bbb45c50afd2d6c1785c2a3d72596b8a5f6" 
           invalid-before=jan/01/1970 00:00:01 invalid-after=jan/01/2038 03:14:07 

 1 K     T name="cert_2" issuer=CN=CAPsMAN-CA-000C424C30F3 common-name="CAP-000C4200C032" 
           key-size=2048 days-valid=24837 trusted=yes 
           key-usage=digital-signature,key-encipherment serial-number="2" 
           fingerprint="2c85bf2fbc9fc0832e47cd2773a6f4b6af35ef65" 
           invalid-before=jan/01/1970 00:00:01 invalid-after=jan/01/2038 03:14:07 

On subsequent connections to CAPsMAN, CAP will use generated certificate.

CAP Configuration

When an AP is configured to be controlled by CAPsMAN, configuration of the managed wireless interfaces on the AP is ignored (exceptions: antenna gain). Instead, AP accepts configuration for the managed interfaces from CAPsMAN.

Note: The CAP wireless interfaces that are managed by CAPsMAN and whose traffic is being forwarded to CAPsMAN (ie. they are not in local forwarding mode), are shown as disabled, with the note Managed by CAPsMAN. Those interfaces that are in local forwarding mode (traffic is locally managed by CAP, and only management is done by CAPsMAN) are not shown disabled, but the note Managed by CAPsMAN is shown

CAP behaviour of AP is configured in /interface wireless cap menu. It contains the following settings:

Property	Description
enabled (yes | no; Default: no)	Disable or enable CAP feature
interfaces (list of interfaces; Default: empty)	List of wireless interfaces to be controlled by Manager
certificate (certificate name | none; Default: none)	Certificate to use for authenticating
discovery-interfaces (list of interfaces; Default: empty)	List of interfaces over which CAP should attempt to discover Manager
caps-man-addresses (list of IP addresses; Default: empty)	List of Manager IP addresses that CAP will attempt to contact during discovery
caps-man-names (list of allowed CAPs Manager names; Default: empty)	List of Manager names that CAP will attempt to connect, if empty - CAP does not check Manager name
caps-man-certificate-common-names (list of allowed CAPs Manager CommonNames; Default: empty)	List of Manager certificate CommonNames that CAP will connect to, if empty - CAP does not check Manager certificate CommonName
bridge (bridge interface; Default: none)	Bridge to which interfaces should be added when local forwarding mode is used

CAPsMAN Configuration Concepts

Each wireless interface on a CAP that is under CAPsMAN control appears as a virtual interface on the CAPsMAN. This provides maximum flexibility in data forwarding control using regular RouterOS features, such as routing, bridging, firewall, etc.

Many wireless interface settings are able to be grouped together into named groups ('profiles') that simplifies the reuse of configuration - for example, common configuration settings can be configured in a 'configuration profile' and multiple interfaces can then refer to that profile. At the same time any profile setting can be overridden directly in an interface configuration for maximum flexibility.

Currently there are the following setting groups:

• channel - channel related settings, such as frequency and width
• datapath - data forwarding related settings, such as bridge to which particular interface should be automatically added as port
• interworking - IEEE 802.11u, Hotspot 2.0 related settings
• security - security related settings, such as allowed authentication types or passphrase
• configuration - main wireless settings group, includes settings such as SSID, and additionally binds together other setting groups - that is, configuration profile can refer to channel, security, etc. named setting groups. Additionally any setting can be overridden directly in configuration profile.

Interface settings bind together all setting groups, but additionally any setting can be overridden directly in interface settings.

By means of setting groups, configuration is organized in hierarchical structure with interface (actual user of configuration) as the root. In order to figure out the effective value of some setting this structure is consulted in a fashion where a higher level setting value overrides a lower level value.

For example, when WPA2 passphrase to be used by a particular interface needs to be found, the following places are consulted and the first place with WPA2 passphrase configured specifies effective passphrase. "->" denotes referring to setting profile (if configured):

• interface passphrase
• interface->security passphrase
• interface->configuration passphrase
• interface->configuration->security passphrase

There are 2 types of interfaces on CAPsMAN - "master" and "slave". The master interface holds the configuration for an actual wireless interface (radio), while a slave interface links to the master interface and is intended to hold the configuration for a Virtual-AP (multiple SSID support). There are settings that are meaningful only for master interface, i.e. mainly hardware setup related settings such as radio channel settings. Note that in order for a radio to accept clients, it's master interface needs to be enabled. Slave interfaces will become operational only if enabled and the master interface is enabled.

Interfaces on CAPsMAN can be static or dynamic. Static interfaces are stored in RouterOS configuration and will persist across reboots. Dynamic interfaces exist only while a particular CAP is connected to CAPsMAN.

CAPsMAN Global Configuration

Settings to enable CAPsMAN functionality are found in /caps-man manager menu:

Property	Description
enabled (yes | no; Default: no)	Disable or enable CAPsMAN functionality
certificate (auto | certificate name | none; Default: none)	Device certificate
ca-certificate (auto | certificate name | none; Default: none)	Device CA certificate
require-peer-certificate (yes | no; Default: no)	Require all connecting CAPs to have a valid certificate
package-path (string |; Default: )	Folder location for the RouterOS packages
upgrade-policy (none | require-same-version | suggest-same-upgrade; Default: none)	Upgrade policy options none - do not perform upgrade require-same-version - CAPsMAN suggest to upgrade the CAP RouterOS version and if it fails it will not provision the CAP. (Manual provision is still possible) suggest-same-version - CAPsMAN suggests to upgrade the CAP RouterOS version and if it fails it will still be provisioned

Radio Provisioning

CAPsMAN distinguishes between CAPs based on an identifier. The identifier is generated based on the following rules:

• if CAP provided a certificate, identifier is set to the Common Name field in the certificate
• otherwise identifier is based on Base-MAC provided by CAP in the form: '[XX:XX:XX:XX:XX:XX]'.

When the DTLS connection with CAP is successfully established (which means that CAP identifier is known and valid), CAPsMAN makes sure there is no stale connection with CAP using the same identifier. Currently connected CAPs are listed in /caps-man remote-cap menu:

[admin@CM] /caps-man> remote-cap print
 # ADDRESS                                    IDENT           STATE               RADIOS
 0 00:0C:42:00:C0:32/27044                    MT-000C4200C032 Run                      1

CAPsMAN distinguishes between actual wireless interfaces (radios) based on their builtin MAC address (radio-mac). This implies that it is impossible to manage two radios with the same MAC address on one CAPsMAN. Radios currently managed by CAPsMAN (provided by connected CAPs) are listed in /caps-man radio menu:

[admin@CM] /caps-man> radio print
Flags: L - local, P - provisioned 
 #    RADIO-MAC         INTERFACE                               REMOTE-AP-IDENT
 0  P 00:03:7F:48:CC:07 cap1                                    MT-000C4200C032

When CAP connects, CAPsMAN at first tries to bind each CAP radio to CAPsMAN master interface based on radio-mac. If an appropriate interface is found, radio gets set up using master interface configuration and configuration of slave interfaces that refer to particular master interface. At this moment interfaces (both master and slaves) are considered bound to radio and radio is considered provisioned.

If no matching master interface for radio is found, CAPsMAN executes 'provisioning rules'. Provisioning rules is an ordered list of rules that contain settings that specify which radio to match and settings that specify what action to take if a radio matches.

Provisioning rules for matching radios are configured in /caps-man provisioning menu:

Property	Description
action (create-disabled | create-enabled | create-dynamic-enabled | none; Default: none)	Action to take if rule matches are specified by the following settings: create-disabled - create disabled static interfaces for radio. I.e., the interfaces will be bound to the radio, but the radio will not be operational until the interface is manually enabled; create-enabled - create enabled static interfaces. I.e., the interfaces will be bound to the radio and the radio will be operational; create-dynamic-enabled - create enabled dynamic interfaces. I.e., the interfaces will be bound to the radio, and the radio will be operational; none - do nothing, leaves radio in non-provisioned state;
comment (string; Default: )	Short description of the Provisioning rule
master-configuration (; Default: )	If action specifies to create interfaces, then a new master interface with its configuration set to this configuration profile will be created
name-format (; Default: cap)	specify the syntax of the CAP interface name creation cap - default name identity - CAP boards system identity name prefix - name from the name-prefix value prefix-identity - name from the name-prefix value and the CAP boards system identity name
name-prefix (string; Default: )	name prefix which can be used in the name-format for creating the CAP interface names
radio-mac (MAC address; Default: 00:00:00:00:00:00)	MAC address of radio to be matched, empty MAC (00:00:00:00:00:00) means match all MAC addresses
slave-configurations (; Default: )	If action specifies to create interfaces, then a new slave interface for each configuration profile in this list is created.

Note: If no rule matches radio, then implicit default rule with action create-enabled and no configurations set is executed.

To get the active provisioning matchers:

[admin@CM] /caps-man provisioning> print
Flags: X - disabled 
 0   radio-mac=00:00:00:00:00:00 action=create-enabled master-configuration=main-cfg 
     slave-configurations=virtual-ap-cfg name-prefix=""

For user's convenience there are commands that allow the re-execution of the provisioning process for some radio or all radios provided by some AP:

[admin@CM] > caps-man radio provision 0

and

[admin@CM] > caps-man remote-cap provision 0

Interface Configuration

CAPsMAN interfaces are managed in /caps-man interface menu:

[admin@CM] > /caps-man interface print          
Flags: M - master, D - dynamic, B - bound, X - disabled, I - inactive, R - running 
 #      NAME                                 RADIO-MAC         MASTER-INTERFACE                               
 0 M BR cap2                                 00:0C:42:1B:4E:F5 none                                           
 1   B  cap3                                 00:00:00:00:00:00 cap2                   

Master Configuration Profiles

Configuration profiles permit pre-defined 'top level' master settings to be applied to CAP radios being provisioned.

Configuration Profiles are configured in /caps-man configuration menu:

Property	Description
channel (list; Default: )	User defined list taken from Channel names (/caps-man channels)
channel.band (2ghz-b | 2ghz-b/g | 2ghz-b/g/n | 2ghz-onlyg | 2ghz-onlyn | 5ghz-a | 5ghz-a/n | 5ghz-onlyn; Default: )	Define operational radio frequency band and mode taken from hardware capability of wireless card
channel.extension-channel (Ce | Ceee | eC | eCee | eeCe | eeeC | disabled; Default: )	Extension channel configuration. (E.g. Ce = extension channel is above Control channel, eC = extension channel is below Control channel)
channel.frequency (integer [0..4294967295]; Default: )	Channel frequency value in MHz on which AP will operate. If left blank, CAPsMAN will automatically determine the best frequency that is least occupied.
channel.tx-power (integer [-30..40]; Default: )	Set TX Power for Card (in Dbm)
channel.width (; Default: )	Sets Channel Width in MHz. (E.g. 20, 40)
comment (string; Default: )	Short description of the Configuration profile
country (name of the country | no_country_set; Default: no_country_set)	Limits available bands, frequencies and maximum transmit power for each frequency. Also specifies default value of scan-list. Value no_country_set is an FCC compliant set of channels.
datapath (list; Default: )	User defined list taken from Datapath names (/caps-man datapath)
datapath.bridge (list; Default: )	Bridge to which particular interface should be automatically added as port
datapath.bridge-cost (integer [0..4294967295]; Default: )	bridge port cost to use when adding as bridge port
datapath.bridge-horizon (integer [0..4294967295]; Default: )	bridge horizon to use when adding as bridge port
datapath.client-to-client-forwarding (yes | no; Default: )	controls if client-to-client forwarding between wireless clients connected to interface should be allowed, in local forwarding mode this function is performed by CAP, otherwise it is performed by CAPsMAN
datapath.local-forwarding (yes | no; Default: )	controls forwarding mode
datapath.openflow-switch (; Default: )	OpenFlow switch port (when enabled) to add interface to
datapath.vlan-id (integer [1..4095]; Default: )	VLAN ID to assign to interface if vlan-mode enables use of VLAN tagging
datapath.vlan-mode (use-service-tag | use-tag; Default: )	Enables and specifies type of VLAN tag to be assigned to interface (causes all received data to get tagged with VLAN tag and allows interface to only send out data tagged with given tag)
guard-interval (any | long; Default: any)	Whether to allow use of short guard interval (refer to 802.11n MCS specification to see how this may affect throughput). "any" will use either short or long, depending on data rate, "long" will use long only.
hide-ssid (yes | no; Default: )	. yes - AP does not include SSID in the beacon frames and does not reply to probe requests that have broadcast SSID. no - AP includes SSID in the beacon frames and replies to probe requests that have broadcast SSID. This property has effect only in AP mode. Setting it to yes can remove this network from the list of wireless networks that are shown by some client software. Changing this setting does not improve security of the wireless network, because SSID is included in other frames sent by the AP.
interworking (; Default: )	IEEE 802.11u, Hotspot 2.0 related settings
load-balancing-group (string; Default: )	Interface belonging to the load balance group accepts new clients only if amount of already connected clients is less than on the rest of interfaces from the same group.
max-sta-count (integer [1..2007]; Default: )	Maximum number of associated clients.
mode (; Default: ap)	Set operational mode. Only ap currently supported.
multicast-helper (default | disabled | full; Default: default)	When set to full multicast packets will be sent with unicast destination MAC address, resolving multicast problem on wireless link. This option should be enabled only on access point, clients should be configured in station-bridge mode. Available starting from v5.15. disabled - disables the helper and sends multicast packets with multicast destination MAC addresses full - all multicast packet mac address are changed to unicast mac addresses prior sending them out default - default choice that currently is set to disabled. Value can be changed in future releases.
name (string; Default: )	Descriptive name for the Configuration Profile
rx-chains (list of integer [0..2]; Default: 0)	Which antennas to use for receive.
security (string; Default: none)	Name of security configuration from /caps-man security
security.authentication-types (list of string; Default: none)	Specify the type of Authentication from wpa-psk, wpa2-psk, wpa-eap or wpa2-eap
security.eap-methods (eap-tls | passthrough; Default: none)	. eap-tls - Use built-in EAP TLS authentication. passthrough - Access point will relay authentication process to the RADIUS server.
security.encryption (aes-ccm | tkip; Default: )	Set type of unicast encryption algorithm used
security.group-encryption (aes-ccm | tkip; Default: )	Set type of group encryption algorithm used
security.passphrase (string; Default: )	WPA or WPA2 pre-shared key
ssid (string (0..32 chars); Default: )	SSID (service set identifier) is a name broadcast in the beacons that identifies wireless network.
tx-chains (list of integer [0..2]; Default: 0)	Which antennas to use for transmit.

Channel Groups

Channel group settings allows for the configuration of lists of radio channel related settings, such as radio band, frequency, Tx Power extension channel and width.

Channel group settings are configured in the Channels profile menu /caps-man channels

Property	Description
band (2ghz-b | 2ghz-b/g | 2ghz-b/g/n | 2ghz-onlyg | 2ghz-onlyn | 5ghz-a | 5ghz-a/n | 5ghz-onlyn; Default: )	Define operational radio frequency band and mode taken from hardware capability of wireless card
comment (string; Default: )	Short description of the Channel Group profile
extension-channel (Ce | Ceee | eC | eCee | eeCe | eeeC | disabled; Default: )	Extension channel configuration. (E.g. Ce = extension channel is above Control channel, eC = extension channel is below Control channel)
frequency (integer [0..4294967295]; Default: )	Channel frequency value in MHz on which AP will operate.
name (string; Default: )	Descriptive name for the Channel Group Profile
tx-power (integer [-30..40]; Default: )	Set TX Power for Card (in Dbm)
width (; Default: )	Sets Channel Width in MHz. (E.g. 20, 40)

Datapath Configuration

Datapath settings control data forwarding related aspects. On CAPsMAN datapath settings are configured in datapath profile menu /caps-man datapath or directly in a configuration profile or interface menu as settings with datapath. prefix.

There are 2 major forwarding modes:

• local forwarding mode, where CAP is locally forwarding data to and from wireless interface
• manager forwarding mode, where CAP sends to CAPsMAN all data received over wireless and only sends out the wireless data received from CAPsMAN. In this mode even client-to-client forwarding is controlled and performed by CAPsMAN.

Forwarding mode is configured on a per-interface basis - so if one CAP provides 2 radio interfaces, one can be configured to operate in local forwarding mode and the other in manager forwarding mode. The same applies to Virtual-AP interfaces - each can have different forwarding mode from master interface or other Virtual-AP interfaces.

Most of the datapath settings are used only when in manager forwarding mode, because in local forwarding mode CAPsMAN does not have control over data forwarding.

There are the following datapath settings:

• bridge -- bridge interface to add interface to, as a bridge port, when enabled
• bridge-cost -- bridge port cost to use when adding as bridge port
• bridge-horizon -- bridge horizon to use when adding as bridge port
• client-to-client-forwarding -- controls if client-to-client forwarding between wireless clients connected to interface should be allowed, in local forwarding mode this function is performed by CAP, otherwise it is performed by CAPsMAN.
• local-forwarding -- controls forwarding mode
• openflow-switch -- OpenFlow switch to add interface to, as port when enabled
• vlan-id -- VLAN ID to assign to interface if vlan-mode enables use of VLAN tagging
• vlan-mode -- VLAN tagging mode specifies if VLAN tag should be assigned to interface (causes all received data to get tagged with VLAN tag and allows interface to only send out data tagged with given tag)

Local Forwarding Mode

In this mode wireless interface on CAP behaves as a normal interface and takes part in normal data forwarding. Wireless interface will accept/pass data to networking stack on CAP. CAPsMAN will not participate in data forwarding and will not process any of data frames, it will only control interface configuration and client association process.

Wireless interface on CAP will change its configuration to 'enabled' and its state and some relevant parameters (e.g. mac-address, arp, mtu) will reflect that of the interface on CAPsMAN. Note that wireless related configuration will not reflect actual interface configuration as applied by CAPsMAN:

[admin@CAP] /interface wireless> pr
Flags: X - disabled, R - running 
 0  R ;;; managed by CAPsMAN
      ;;; channel: 5180/20-Ceee/ac, SSID: master, local forwarding
      name="wlan2" mtu=1500 mac-address=00:03:7F:48:CC:07 arp=enabled 
      interface-type=Atheros AR9888 mode=ap-bridge ssid="merlin" 
      frequency=5240 band=5ghz-a/n channel-width=20/40mhz-eC scan-list=default
      ...

Virtual-AP interfaces in local forwarding mode will appear as enabled and dynamic Virtual-AP interfaces:

[admin@CAP] /interface> pr
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                TYPE         MTU L2MTU  MAX-L2MTU
 ...
 2  RS ;;; managed by CAPsMAN
       ;;; channel: 5180/20-Ceee/ac, SSID: master, local forwarding
       wlan2                               wlan        1500  1600
 3 DRS ;;; managed by CAPsMAN
       ;;; SSID: slave, local forwarding
       wlan6                               wlan        1500  1600
 ...
[admin@CAP] /interface> wireless pr   
Flags: X - disabled, R - running 
 ...
 2  R ;;; managed by CAPsMAN
      ;;; SSID: slave, local forwarding
      name="wlan6" mtu=1500 mac-address=00:00:00:00:00:00 arp=enabled 
      interface-type=virtual-AP master-interface=wlan2 

The fact that Virtual-AP interfaces are added as dynamic, somewhat limits static configuration possibilities on CAP for data forwarding, such as assigning addresses to Virtual-AP interface. This does not apply to master wireless interface.

To facilitate data forwarding configuration, CAP can be configured with bridge to which interfaces are automatically added as ports when interfaces are enabled by CAPsMAN. This can be done in /interface wireless cap menu.

Manager Forwarding Mode

In this mode CAP sends all data received over wireless to CAPsMAN and only sends out over wireless, data received from CAPsMAN. CAPsMAN has full control over data forwarding including client-to-client forwarding. Wireless interface on CAP is disabled and does not participate in networking:

 ...
 1 X  ;;; managed by CAPsMAN
      ;;; channel: 5180/20-Ceee/ac, SSID: master, manager forwarding
      name="wlan2" mtu=1500 mac-address=00:03:7F:48:CC:07 arp=enabled 
      interface-type=Atheros AR9888 mode=ap-bridge ssid="merlin" 
 ...

Virtual-AP interfaces are also created as 'disabled' and do not take part in data forwarding on CAP.

Access List

Access list on CAPsMAN is an ordered list of rules that is used to allow/deny clients to connect to any CAP under CAPsMAN control. When client attempts to connect to a CAP that is controlled by CAPsMAN, CAP forwards that request to CAPsMAN. As a part of registration process, CAPsMAN consults access list to determine if client should be allowed to connect.

Access list rules are processed one by one until matching rule is found. Then the action in the matching rule is executed. If action specifies that client should be accepted, client is accepted, potentially overriding it's default connection parameters with ones specified in access list rule.

Access list is configured in /caps-man access-list menu. There are the following parameters for access list rules:

• client matching parameters:
  • address - MAC address of client
  • mask - MAC address mask to apply when comparing client address
  • interface - optional interface to compare with interface to which client actually connects to
  • time - time of day and days when rule matches
  • signal-range - range in which client signal must fit for rule to match
• action parameter - specifies action to take when client matches:
  • accept - accept client
  • reject - reject client
  • query-radius - query RADIUS server if particular client is allowed to connect
• connection parameters:
  • ap-tx-limit - tx speed limit in direction to client
  • client-tx-limit - tx speed limit in direction to AP (applies to RouterOS clients only)
  • client-to-client-forwarding - specifies whether to allow forwarding data received from this client to other clients connected to the same interface
  • private-passphrase - PSK passphrase to use for this client if some PSK authentication algorithm is used
  • radius-accounting - specifies if RADIUS traffic accounting should be used if RADIUS authentication gets done for this client
  • vlan-mode - VLAN tagging mode specifies if traffic coming from client should get tagged (and untagged when going to client).
  • vlan-id - VLAN ID to use if doing VLAN tagging.

Registration Table

Registration table contains a list of clients that are connected to radios controlled by CAPsMAN and is available in /caps-man registration-table menu:

[admin@CM] /caps-man> registration-table print
 # INTERFACE                   MAC-ADDRESS       UPTIME                RX-SIGNAL
 0 cap1                        00:03:7F:48:CC:0B 1h38m9s210ms                -36

Examples

Create security profile for WPA2 PSK, without specifying passphrase:

[admin@CM] /caps-man security>add name="wpa2psk" authentication-types=wpa2-psk encryption=aes-ccm

Create configuration profile to be used by master interface

• specify WPA2 passphrase in configuration
• specify channel settings in configuration:

[admin@CM] /caps-man configuration> add name=master-cfg ssid=master security=wpa2psk
security.passphrase=12345678 channel.frequency=5180 channel.width=20 channel.band=5ghz-a

Create configuration profile to be used by virtual AP interface

• specify different WPA2 passphrase in configuration:

[admin@CM] /caps-man configuration> add name=slave-cfg ssid=slave security=wpa2psk
security.passphrase=87654321

Create provisioning rule that matches any radio and creates dynamic interfaces using master-cfg and slave-cfg:

[admin@CM] /caps-man provisioning> add action=create-dynamic-enabled master-configuration=master-cfg
slave-configurations=slave-cfg

Now when AP connects and is provisioned 2 dynamic interfaces (one master and one slave) will get created:

[admin@CM] /caps-man interface> print detail 
Flags: M - master, D - dynamic, B - bound, X - disabled, I - inactive, R - running 
 0 MDB  name="cap1" mtu=1500 l2mtu=2300 radio-mac=00:0C:42:1B:4E:F5 master-interface=none 
        configuration=master-cfg 

 1  DB  name="cap2" mtu=1500 l2mtu=2300 radio-mac=00:00:00:00:00:00 master-interface=cap1 
        configuration=slave-cfg 

Consider an AP, that does not support configured frequency connects and can not become operational:

[admin@CM] /caps-man interface> pr
Flags: M - master, D - dynamic, B - bound, X - disabled, I - inactive, R - running 
 #      NAME                                 RADIO-MAC         MASTER-INTERFACE                               
 0 MDB  ;;; unsupported band or channel
        cap3                                 00:0C:42:1B:4E:FF none    
 ...

We can override channel settings for this particular radio in interface settings, without affecting master-cfg profile:

[admin@CM] /caps-man interface> set cap3 channel.frequency=2142 channel.band=2ghz-b/g

Allow Specific MAC address range to match the Access-list, for example, match all the Apple devices:

[admin@CM] /caps-man access-list> add mac-address=18:34:51:00:00:00 mac-address-mask=FF:FF:FF:FF:00:00:00 action=accept