Wireless Interface

Overview

Standards: 
Package: wireless

RouterOS wireless comply with IEEE 802.11 standards, it provides complete support for 802.11a, 802.11b, 802.11g, 802.11n and 802.11ac as long as additional features like WPA, WEP, AES encryption, Wireless Distribution System (WDS), Dynamic Frequency selection (DFS), Virtual Access Point, Nstreme and NV2 proprietary protocols and many more. Wireless features compatibility table for different wireless protocols.

Wireless can operate in several modes: client (station), access point, wireless bridge etc. Client/station also can operate in different modes, a complete list of supported modes can be found here.

General interface properties

Sub-menu: /interface wireless

gg

802.11n wireless chipsets represent power per chain and the 802.11ac

wireless chipsets represent the total power, for reference see the table below:Transmit Power representation on 802.11n and 802.11ac

Basic and MCS Rate table

Used settings when rate-set=configured

Settings independent from rate-set:

1. allowed mcs depending on number of chains:
   • 1 chain: 0-7
   • 2 chains: 0-15
   • 3 chains: 0-23
2. if standard channel width (20Mhz) is not used, then 2ghz modes (except 2.4ghz-b) are not using b rates (1-11)

Frame protection support (RTS/CTS)

802.11 standard provides means to protect transmission against other device transmission by using RTS/CTS protocol. Frame protection helps to fight "hidden node" problem. There are several types of protection:

• RTS/CTS based protection - device willing to send frame at first sends RequestToSend frame and waits for ClearToSend frame from intended destination. By "seeing" RTS or CTS frame 802.11 compliant devices know that somebody is about to transmit and therefore do not initiate transmission themselves
• "CTS to self" based protection - device willing to send frame sends CTS frame "to itself". As in RTS/CTS protocol every 802.11 compliant device receiving this frame know not to transmit. "CTS to self" based protection has less overhead, but it must be taken into account that this only protects against devices receiving CTS frame (e.g. if there are 2 "hidden" stations, there is no use for them to use "CTS to self" protection, because they will not be able to receive CTS sent by other station - in this case stations must use RTS/CTS so that other station knows not to transmit by seeing CTS transmitted by AP).

Protection mode is controlled by hw-protection-mode setting of wireless interface. Possible values: none - for no protection (default), rts-cts for RTS/CTS based protection or cts-to-self for "CTS to self" based protection.

Frame size threshold at which protection should be used is controlled by hw-protection-threshold setting of wireless interface.

For example, to enable "CTS-to-self" based frame protection on AP for all frames, not depending on size, use command:

[admin@MikroTik] /interface wireless> set 0 hw-protection-mode=cts-to-self hw-protection-threshold=0

To enable RTS/CTS based protection on client use command:

[admin@MikroTik] /interface wireless> set 0 hw-protection-mode=rts-cts hw-protection-threshold=0

Nv2

MikroTik has developed a new wireless protocol based on TDMA technology (Time Division Multiple Access) - (Nstreme version 2). See the Nv2 documentation: NV2

TDMA is a channel access method for shared medium networks. It allows several users to share the same frequency channel by dividing the signal into different time slots. The users transmit in rapid succession, one after the other, each using his own time slot. This allows multiple stations to share the same transmission medium (e.g. radio frequency channel) while using only a part of its channel capacity.

The most important benefits of Nv2 are:

• Increased speed
• More client connections in PTM environments
• Lower latency
• No distance limitations
• No penalty for long distances

Starting from RouterOS v5.0beta5 you can configure Nv2 in the Wireless menu. Please take a look at the NV2 protocol implementation status. Nv2 protocol limit is 511 clients.

Warning: Nv2 doesn't have support for Virtual AP

Nv2 Troubleshooting

Increase throughput on long distance with tdma-period-size. In Every "period", the Access Point leaves part of the time unused for data transmission (which is equal to round trip time - the time in which the frame can be sent and received from the client), it is used to ensure that client could receive the last frame from Access Point, before sending its own packets to it. The longer the distance, the longer the period is unused.

For example, the distance between Access Point and client is 30km. Frame is sent in 100us one direction, respectively round-trip-time is ~200us. tdma-period-size default value is 2ms, it means 10% of the time is unused. When tdma-period-size is increased to 4ms, only 5% of time is unused. For 60km wireless link, round-trip-time is 400ms, unused time is 20% for default tdma-period-size 2ms, and 10% for 4ms. Bigger tdma-period-size value increases latency on the link.

Access List

Sub-menu: /interface wireless access-list

Access list is used by access point to restrict allowed connections from other devices, and to control connection parameters.

Operation:

• Access list rules are checked sequentially.
• Disabled rules are always ignored.
• Only the first matching rule is applied.
• If there are no matching rules for the remote connection, then the default values from the wireless interface configuration are used.
• If remote device is matched by rule that has authentication=no value, the connection from that remote device is rejected.

Warning: If there is no entry in ACL about client which connects to AP (wireless,debug wlan2: A0:0B:BA:D7:4D:B2 not in local ACL, by default accept), then ACL for this client is ignored during all connection time.

For example, if client's signal during connection is -41 and we have ACL rule

/interface wireless access-list
add authentication=yes forwarding=yes interface=wlan2 signal-range=-55..0

Then connection is not matched to any ACL rule and if signal drops to -70..-80, client will not be disconnected.

To make it work correctly it is required that client is matched by any of ACL rules.

If we modify ACL rules in previous example to:

/interface wireless access-list
add interface=wlan2 signal-range=-55
add authentication=no forwarding=no interface=wlan2 signal-range=-120..-56

Then if signal drops to -56, client will be disconnected.

Properties

Align

Sub-menu: /interface wireless align

Align tool is used to help in alignment devices running this tool.

Menu Specific Commands

Connect List

Sub-menu: /interface wireless connect-list

connect-list is used to assign priority and security settings to connections with remote access points, and to restrict allowed connections. connect-list is an ordered list of rules. Each rule in connect-list is attached to specific wireless interface, specified in the interfaceproperty of that rule (this is unlike access-list, where rules can apply to all interfaces). Rule can match MAC address of remote access point, it's signal strength and many other parameters.

Operation:

• connect-list rules are always checked sequentially, starting from the first.
• disabled rules are always ignored.
• Only the first matching rule is applied.
• If SSID or exact wireless protocol is provided in the wireless interface configuration Connect List SSIDs or wireless protocols not covered by wireless interface configuration are ignored.
• If connect-list does not have any rule that matches remote access point, then the default values from the wireless interface configuration are used.
• If access point is matched by rule that has connect=no value, connection with this access point will not be attempted.
• If access point is matched by rule that has connect=yes value, connection with this access point will be attempted.
  • In station mode, if several remote access points are matched by connect list rules with connect=yes value, connection will be attempted with access point that is matched by rule higher in the connect-list.
  • If no remote access points are matched by connect-list rules with connect=yes value, then value of default-authentication interface property determines whether station will attempt to connect to any access point. If default-authentication=yes, station will choose access point with best signal and compatible security.
• In access point mode, connect-list is checked before establishing WDS link with remote device. If access point is not matched by any rule in the connect list, then the value of default-authentication determines whether WDS link will be established.

Properties

Usage

Restrict station connections only to specific access points

• Set value of default-authentication interface property to no.

/interface wireless set station-wlan default-authentication=no

• Create rules that matches allowed access points. These rules must have connect=yes and interface equal to the name of station wireless interface.

/interface wireless connect-list add interface=station-wlan connect=yes mac-address=00:11:22:33:00:01/interface wireless connect-list add interface=station-wlan connect=yes mac-address=00:11:22:33:00:02

Disallow connections to specific access points

• Set value of default-authentication interface property to yes.

/interface wireless set station-wlan default-authentication=yes

• Create connect=no rules that match those access points that station should not connect to. These rules must have connect=no and interface equal to the name of station wireless interface.

/interface wireless connect-list add interface=station-wlan connect=no mac-address=00:11:22:33:44:55

Select preferred access points

• Create rules that match preferred access points. These rules must have connect=yes and interface equal to the name of station wireless interface.
• Put rules that match preferred access points higher in the connect-list, in the order of preference.

Restrict WDS link establishment

• Place rules that match allowed access points at the top.
• Add deny-all rule at the end of connect list.

Info

Sub-menu: /interface wireless info

Manual TX Power Table

Sub-menu: /interface wireless manual-tx-power-table

Wireless hardware table

Warning: You must follow to regulatory domain requirements in your country. If you are allowed to use other frequencies, note that Antenna Gain and Transmit Power may decrease depending on board and frequency. Devices are calibrated only for regulatory frequencies, use non standard frequencies at your own risk. The list only specifies frequencies accepted by the wireless chip, these frequencies might not always work due to antenna that is built into the product, device design, filters and other factors. USE STRICTLY AT YOUR OWN RISK

Integrated wireless interface frequency table

NOTES:

1. - Only in 802.11a/n standard

Overview

Advanced Channels feature provides extended opportunities in wireless interface configuration:

• scan-list that covers multiple bands and channel widths;
• non-standard channel center frequencies (specified with KHz granularity) for hardware that allows that;
• non-standard channel widths (specified with KHz granularity) for hardware that allows that.

Hardware support

Non standard center frequency and width channels can only be used with interfaces that support it.

Currently only Atheros AR92xx based chips support non-standard center frequencies and widths with the following ranges:

• center frequency range: 2200MHz-2500MHz with step 0.5MHz (500KHz), width range: 2.5MHz-30MHz width step 0.5MHz (500KHz);
• center frequency range: 4800MHz-6100MHz with step 0.5MHz (500KHz), width range: 2.5MHz-30MHz width step 0.5MHz (500KHz);

AR93xx doesn't support this feature

Configuring Advanced Channels

Advanced Channels are configured in interface wireless channels menu. This menu contains ordered list of user-defined channels that can be grouped by means of list property. Channels have the following properties:

• name - name by which this channel can be referred to. If name is not specified when adding channel, it will be automatically generated from channel frequency and width;
• list - name of list this channel is part of. Lists can be used to group channels;
• frequency - channel center frequency in MHz, allowing to specify fractional MHz part, e.g. 5181.5;
• width - channel width in MHz, allowing to specify fractional MHz part, e.g. 14.5;
• band - defines default set of data rates when using this channel;
• extension-channel - specifies placement of 11n extension channel.

Using Advanced Channels

In order to use Advanced Channels in wireless interface configuration, several interface settings accept channel names or list names as arguments. It is possible to configure interface with channel that interface does not support. In this case interface will not become operational. It is sole responsibility of administrator to configure channels in proper way.

frequency

To use particular Advanced Channel for wireless interface (applies to modes that make use of interface frequency setting) specify channel name in interface frequency setting. For example, to configure interface to operate with center frequency 5500MHz and channel width 14MHz, use the following commands:

[admin@MikroTik] /interface wireless> channels add name=MYCHAN frequency=5500 width=14 band=5ghz-onlyn
 list=MYLIST
[admin@MikroTik] /interface wireless> set wlan1 frequency=MYCHAN 

scan-list

Interface scan-list is used in multiple modes that either gather information for list of channels (like interactive scan command) or selects channel to work on (like any of station modes or AP modes performing DFS). Interface scan-list can be configured with comma-separated list of the following items:

• default - default .11 channel list for given country and interface band and channel width;
• numeric frequency ranges in MHz;
• Advanced Channel, referred to by name;
• Advanced Channel list, referred to by list name.

For example, to configure interface to scan 5180MHz, 5200MHz and 5220MHz at first using channel width 20MHz and then using channel width 10MHz, the following commands can be issued:

[admin@MikroTik] /interface wireless> channels add frequency=5180 width=20 band=5ghz-a list=20MHz-list
[admin@MikroTik] /interface wireless> channels add frequency=5200 width=20 band=5ghz-a list=20MHz-list
[admin@MikroTik] /interface wireless> channels add frequency=5220 width=20 band=5ghz-a list=20MHz-list
[admin@MikroTik] /interface wireless> channels add frequency=5180 width=10 band=5ghz-a list=10MHz-list
[admin@MikroTik] /interface wireless> channels add frequency=5200 width=10 band=5ghz-a list=10MHz-list
[admin@MikroTik] /interface wireless> channels add frequency=5220 width=10 band=5ghz-a list=10MHz-list
[admin@MikroTik] /interface wireless> set wlan1 scan-list=20MHz-list,10MHz-list

Nstreme

Sub-menu: /interface wireless nstreme

This menu allows to switch a wireless card to the nstreme mode. In this case the card will work only with nstreme clients.

Note: The settings here (except for enabling nstreme) are relevant only on Access Point, they are ignored for client devices! The client automatically adapts to the AP settings.
WDS for Nstreme protocol requires using station-wds mode on one of the peers. Configurations with WDS between AP modes (bridge and ap-bridge) will not work.

Nstreme Dual

Sub-menu: /interface wireless nstreme-dual

Two radios in nstreme-dual-slave mode can be grouped together to make nstreme2 Point-to-Point connection. To put wireless interfaces into a nstreme2 group, you should set their mode to nstreme-dual-slave. Many parameters from /interface wireless menu are ignored, using the nstreme2, except:

• frequency-mode
• country
• antenna-gain
• tx-power
• tx-power-mode
• antenna-mode

Warning: WDS cannot be used on Nstreme-dual links.

Note: The difference between tx-freq and rx-freq should be about 200MHz (more is recommended) because of the interference that may occur!

Note: You can use different bands for rx and tx links. For example, transmit in 2ghz-g and receive data, using 2ghz-b band.

Registration Table

Sub-menu: /interface wireless registration-table

In the registration table, you can see various information about currently connected clients. It is used only for Access Points.

All properties are read-only.

Security Profiles

Sub-menu: /interface wireless security-profiles

Security profiles are configured under the /interface wireless security-profiles path in the console, or in the "Security Profiles" tab of the "Wireless" window in the WinBox. Security profiles are referenced by the Wireless interface security-profile property and security-profile property of Connect Lists.

Basic properties

WPA properties

These properties have effect only when mode is set to dynamic-keys.

Note: RouterOS also allows to override pre-shared key value for specific clients, using either the private-pre-shared-key property, or the Mikrotik-Wireless-Psk attribute in the RADIUS MAC authentication response. This is an extension.

WPA EAP properties

These properties have effect only when authentication-types contains wpa-eap or wpa2-eap, and mode is set to dynamic-keys.

Note: The order of allowed authentication methods in eap-methods is important, the same order is going to be used to send authentication method offers to the Station. Example: Access Point uses security-profile where eap-methods is set to eap-tls,passthrough; 1) Access Point offers EAP-TLS method to the client; 2) Client refuses; 3) Access Point starts relaying EAP communication to the radius server.

Note: When the AP is used for passthrough it is not required to add certificates on the AP itself, the AP device works as a transparent bridge and forwards the EAP-TLS association data from RADIUS server to the end client.

Note: When tls-mode is using either verify-certificate or dont-verify-certificate, then the remote device has to support one of the RC4-MD5, RC4-SHA or DES-CBC3-SHA TLS cipher suites. When using no-certificates mode, then the remote device must support "ADH-DES-CBC3-SHA" cipher suite.

RADIUS properties

WEP properties

These properties have effect only when mode is set to static-keys-required or static-keys-optional.

Management frame protection

Used for: Deauthentication attack prevention, MAC address cloning issue.

RouterOS implements proprietary management frame protection algorithm based on shared secret. Management frame protection means that RouterOS wireless device is able to verify source of management frame and confirm that particular frame is not malicious. This feature allows to withstand deauthentication and disassociation attacks on RouterOS based wireless devices.

Management protection mode is configured in security-profile with management-protection setting. Possible values are: disabled - management protection is disabled (default), allowed - use management protection if supported by remote party (for AP - allow both, non-management protection and management protection clients, for client - connect both to APs with and without management protection), required - establish association only with remote devices that support management protection (for AP - accept only clients that support management protection, for client - connect only to APs that support management protection).

Management protection shared secret is configured with security-profile management-protection-key setting.

When interface is in AP mode, default management protection key (configured in security-profile) can be overridden by key specified in access-list or RADIUS attribute.

[admin@mikrotik] /interface wireless security-profiles> print 
 0 name="default" mode=none authentication-types="" unicast-ciphers="" 
  group-ciphers="" wpa-pre-shared-key="" wpa2-pre-shared-key="" 
  supplicant-identity="n-str-p46" eap-methods=passthrough 
  tls-mode=no-certificates tls-certificate=none static-algo-0=none 
  static-key-0="" static-algo-1=none static-key-1="" static-algo-2=none 
  static-key-2="" static-algo-3=none static-key-3="" 
  static-transmit-key=key-0 static-sta-private-algo=none 
  static-sta-private-key="" radius-mac-authentication=no 
  radius-mac-accounting=no radius-eap-accounting=no interim-update=0s 
  radius-mac-format=XX:XX:XX:XX:XX:XX radius-mac-mode=as-username 
  radius-mac-caching=disabled group-key-update=5m 
  management-protection=disabled management-protection-key=""  

[admin@mikrotik] /interface wireless security-profiles> set default management-protection=    
                                                        allowed  disabled  required  

Operation details

RADIUS MAC authentication

Note: RAIDUS MAC authentication is used by access point for clients that are not found in the access-list, similarly to the default-authentication property of the wireless interface. It controls whether client is allowed to proceed with authentication, or is rejected immediately.

When radius-mac-authentication=yes, access point queries RADIUS server by sending Access-Request with the following attributes:

• User-Name - Client MAC address. This is encoded as specified by the radius-mac-format setting. Default encoding is "XX:XX:XX:XX:XX:XX".
• Nas-Port-Id - name of wireless interface.
• User-Password - When radius-mac-mode=as-username-and-password this is set to the same value as User-Name. Otherwise this attribute is empty.
• Calling-Station-Id - Client MAC address, encoded as "XX-XX-XX-XX-XX-XX".
• Called-Station-Id - MAC address and SSID of the access point, encoded as "XX-XX-XX-XX-XX-XX:SSID" (minus separated pairs of MAC address digits, followed by colon, followed by SSID value).
• Acct-Session-Id - Added when radius-mac-accounting=yes.

When access point receives Access-Accept or Access-Reject response from the RADIUS server, it stores the response and either allows or rejects client. Access point uses following RADIUS attributes from the Access-Accept response:

• Ascend-Data-Rate
• Ascend-Xmit-Rate
• Mikrotik-Wireless-Forward - Same as access-list forwarding.
• Mikrotik-Wireless-Enc-Algo - Same as access-list private-algo.
• Mikrotik-Wireless-Enc-Key - Same as access-list private-key.
• Mikrotik-Wireless-Psk - Same as access-list private-pre-shared-key.
• Mikrotik-Wireless-Mpkey - Same as Management-protection-key in Access list
• Session-Timeout - Time, after which client will be disconnected.
• Acct-Interim-Interval - Overrides value of interim-update.
• Class - If present, value of this attribute is saved and included in Accounting-Request messages.

Caching

Caching of RADIUS MAC authentication was added to support RADIUS authentication for clients that require from the access point very quick response to the association request. Such clients time out before response from RADIUS server is received. Access point caches authentication response for some time and can immediately reply to the repeated association request from the same client.

RADIUS EAP pass-through authentication

When using WPA EAP authentication type, clients that have passed MAC authentication are required to perform EAP authentication before being authorized to pass data on wireless network. With pass-through EAP method the access point will relay authentication to RADIUS server, and use following attributes in the Access-Request RADIUS message:

• User-Name - EAP supplicant identity. This value is configured in the supplicant-identity property of the client security profile.
• Nas-Port-Id - name of wireless interface.
• Calling-Station-Id - Client MAC address, encoded as "XX-XX-XX-XX-XX-XX".
• Called-Station-Id - MAC address and SSID of the access point, encoded as "XX-XX-XX-XX-XX-XX:SSID" (pairs of MAC address digits separated by minus sign, followed by colon, followed by SSID value).
• Acct-Session-Id - Added when radius-eap-accounting=yes.
• Acct-Multi-Session-Id - MAC address of access point and client, and unique 8 byte value, that is shared for all accounting sessions that share single EAP authentication. Encoded as AA-AA-AA-AA-AA-AA-CC-CC-CC-CC-CC-CC-XX-XX-XX-XX-XX-XX-XX-XX.

Added when radius-eap-accounting=yes.

Access point uses following RADIUS attributes from the Access-Accept server response:

• Class - If present, value of this attribute is saved and included in Accounting-Request messages.
• Session-Timeout - Time, after which client will be disconnected. Additionally, access point will remember authentication result, and if during this time client reconnects, it will be authorized immediately, without repeating EAP authentication.
• Acct-Interim-Interval - Overrides value of interim-update.

Statically configured WEP keys

Different algorithms require different length of keys:

• 40bit-wep - 10 hexadecimal digits (40 bits). If key is longer, only first 40 bits are used.
• 104bit-wep - 26 hexadecimal digits (104 bits). If key is longer, only first 104 bits are used.
• tkip - At least 64 hexadecimal digits (256 bits).
• aes-ccm - At least 32 hexadecimal digits (128 bits).

Key must contain even number of hexadecimal digits.

WDS security configuration

WDS links can use all available security features. However, they require careful configuration of security parameters.

It is possible to use one security profile for all clients, and different security profiles for WDS links. Security profile for WDS link is specified in connect-list. Access point always checks connect list before establishing WDS link with another access point, and used security settings from matching connect list entry. WDS link will work when each access point will have connect list entry that matches the other device, has connect=yes and specifies compatible security-profile.

WDS and WPA/WPA2

If access point uses security profile with mode=dynamic-keys, then encryption will be used for all WDS links. Since WPA authentication and key exchange is not symmetrical, one of the access points will act as a client for the purpose of establishing secure connection. This is similar to how static-mesh and dynamic-mesh WDS modes work. Some problems, like single sided WDS link between two incorrectly configured access points that use non-mesh mode, is not possible if WPA encryption is enabled. However, non-mesh modes with WPA still have other issues (like constant reconnection attempts in case of configuration mismatch) that are solved by use of the -mesh WDS modes.

In general, WPA properties on both access points that establish WPA protected WDS link have to match. These properties are authentication-types, unicast-ciphers, group-ciphers. For non-mesh WDS mode these properties need to have the same values on both devices. In mesh WDS mode each access point has to support the other one as a client.

Theoretically it is possible to use RADIUS MAC authentication and other RADIUS services with WDS links. However, only one access point will interact with the RADIUS server, the other access point will behave as a client.

Implementation of eap-tls EAP method in RouterOS is particularly well suited for WDS link encryption. tls-mode=no-certificates requires no additional configuration, and provides very strong encryption.

WDS and WEP

mode, static-sta-private-key and static-sta-private-algo parameters in the security profile assigned to the WDS link need to have the same values on both access points that establish WDS link with WPA encryption.

Security profile and access point matching in the connect list

Client uses value of connect-list security-profile property to match only those access points that support necessary security.

• mode=static-keys-required and mode=static-keys-optional matches only access points with the same mode in interface security-profile.
• If mode=dynamic-keys, then connect list entry matches if all of the authentication-types, unicast-ciphers and group-ciphers contain at least one value that is advertised by access point.

Virtual interfaces

VirtualAP

It is possible to create virtual access points using the add command in the wireless menu. You must specify the master-interface which the virtual interface will belong to. If "master-interface" mode is "station", Virtual AP will work only when "master-interface" will be active. The Virtual AP can have it's own SSID and Security Profile.

Virtual AP interface will only work if master interface is in ap-bridge, bridge, station or wds-slave mode. It works only with 802.11 protocol, Nv2 is not supported.

This feature is useful for separating access for different types of users. You can assign different bandwidth levels and passwords and instruct users to connect to the specific virtual network, it will appear to wireless clients as a different SSID or a different device. For example, when using QuickSet to configure a guest network, the VirtualAP feature is used in the background.

To create a new virtual-ap: /interface> wireless add mode=ap-bridge master-interface=wlan1 ssid=guests security-profile=guests (such security profile first needs to be created)

Note: you can create up to 127 virtual interfaces per physical interface. It is not recommended to create more 30, since the performance will start to degrade.

Virtual Clients

Note: Starting from 6.35 only in wireless-rep or wireless-cm2 package

It is also possible to create virtual clients and have both an AP and a Client on the same physical interface. This allows to make a repeater setup with only using one hardware card. The process of configuration is exacly the same as above, but use mode station:

To create a new virtual-client: /interface> wireless add mode=station master-interface=wlan1 ssid=where-to-connect security-profile=your-profile (such security profile first needs to be created)

Note: Virtual interfaces will always use the Master interface wireless frequency. If the Master interface has 'auto' frequency enabled it will use the wireless frequency that the Master interface selected.

Sniffer

Sub-menu: /interface wireless sniffer

Wireless sniffer allows to capture frames including Radio header, 802.11 header and other wireless related information.

Packets

Sub-menu: /interface wireless sniffer packet

Sub-menu shows captured packets.

Scan

Scan command allows to see available AP in the frequency range defined in the scan-list. Using scan command the interface operation is disabled (wireless link is disconnected during the scan operation) Since RouterOS v6.35 (wireless-rep) background scan is supported which can be used during the wireless interface operation without disconnecting the wireless link. Background scan is supported only using 802.11 wireless protocol.

Scan tool will continue scanning for AP until user stops the scan process. It is possible to use 'rounds' setting for the scan tool to do scan through the scan-list entries specific times. It is useful when running scan tool using scripts. Example of scan command for one round:

/interface wireless scan wlan1 rounds=1

'save-file' option allows to do scripted/scheduled scans and save the results in file for future analysis. Also this feature together with rounds setting allows to get scan results from the remote wireless clients - executing that command will start the scan tool which disconnect the wireless link, does the scan through the scan-list frequencies and saves the results to file, exits the scan and connects the wireless link back. Example:

/interface wireless scan wlan1 rounds=1 save-file=scan1

To use background wireless scan the 'background=yes' setting should be provided. Example:

/interface wireless scan wlan1 background=yes

Background scan feature is working in such conditions:

• Wireless interface should be enabled
• For wireless interface in AP mode - when it is operating in 802.11 protocol mode and is on fixed channel (that is - channel selection and initial radar checking is over)
• For wireless interface in Station mode - when it is connected to 802.11 protocol AP.

Scan command is supported also on the Virtual wireless interfaces with such limitations:

• It is possible when virtual interface and its master is fixed on channel (master AP is running or master station is connected to AP).
• Scan is only performed in channel master interface is on.
• It does not matter if background=yes|no - on virtual interface scan does not disconnect clients/AP, so it is always "background".

Snooper

This tool monitors surrounding frequency usage, and displays which devices occupy each frequency. It's available both in console, and also in Winbox.

Sub-menu: /interface wireless snooper

Settings

Spectral scan

• See separate document Manual:Spectral_scan

WDS

Sub-menu: /interface wireless wds

Properties:

Read-only properties:

WPS

Wireless interface supports WPS Server and also WPS Client (supported by wireless-rep package starting from RouterOS v6.35).

WPS Server

WPS Server allows to connect wireless clients that support WPS to AP protected with the Pre-Shared Key without specifying that key in the clients configuration.

WPS Server can be enabled by changing the WPS Mode setting for the wireless interface. Example:

 /interface wireless set wlan1 wps-mode=push-button

Wps-mode has 3 options

• disabled
• push-button - WPS is activated by pushing physical button on the board (few boards has such button marked on the board case/label)
• push-button-virtual-only - WPS is activated by pushing "WPS Accept" button from the RouterOS wireless interface menu

By pushing the WPS physical/virtual button the AP enables the WPS functionality. If within 2 minutes the WPS process isn't initiated the WPS Accept Function is stopped.

WPS Server is enabled by default on few boards that has physical WPS button marked. For example, hap lite, hap, hap ac lite, hap ac, map lite

WPS Server is active only when wireless AP interface has Pre-Shared Key Authentication (PSK) enabled. It is possible to configure this mode for the Virtual AP interfaces as well.

WPS Client

WPS Client function allows the wireless client to get the Pre-Shared Key configuration of the AP that has WPS Server enabled. WPS Client can be enabled by such command:

 /interface wireless wps-client wlan1

WPS Client command outputs all the information of the WPS Enabled AP on the screen. Example:

[admin@MikroTik] /interface wireless> wps-client wlan1
          status: disconnected, success
            ssid: MikroTik
     mac-address: E4:8D:8C:D6:E0:AC
      passphrase: presharedkey
  authentication: wpa2-psk
      encryption: aes-ccm

It is possible to specify additional settings for the WPS-Client command:

• create-profile - creates wireless security profile with the specified name, configures it with security details received from the WPS AP, specifies the wireless interface to use the new created security profile
• ssid - get WPS information only from AP with specified SSID
• mac-address - get WPS information only from AP with specified mac-address

Repeater

Wireless repeater will allow to receive the signal from the AP and repeat the signal using the same physical interface locally for connecting other clients. This will allow to extend the wireless service for the wireless clients. Wireless repeater function will configure the wireless interface to connect to the AP with station-bridge or station-pseudobridge option, create a virtual AP interface, create a bridge interface and add both (main and the virtual) interfaces to the bridge ports.

If your AP supports button-enabled WPS mode, you can use the automatic setup command:

/interface wireless setup-repeater wlan1

The setup-repeater does the following steps:

• searches for WPS AP with button pushed
• acquires SSID, key, channel from AP
• resets main master interface config (same as reset-configuration)
• removes all bridge ports that were added for virtual interfaces added to this master (so there are no dangling invalid bridge ports later)
• removes all virtual interfaces added to this master
• creates security profile with name "<interfacename>-<ssid>-repeater", if such security profile already exists does not create new, just updates settings
• configures master interface, interface mode is selected like this: if AP supports bridge mode, use station-bridge, else if AP supports WDS, use station-wds, else use station-pseudobridge
• creates virtual AP interface with same SSID and security profile as master
• if master interface is not in some bridge, creates new bridge interface and adds master interface to it
• adds virtual AP interface to the same bridge master interface is in.

If your AP does not support WPS, it is possible to specify the settings manually, using these parameters:

• address - MAC address of AP to setup repeater for (optional)
• ssid - SSID of AP to setup repeater for (optional)
• passphrase - key to use for AP - if this IS specified, command will just scan for AP and create security profile based on info in beacon and with this passphrase. If this IS NOT specified, command will do WPS to find out passphrase.

The same options are available in the GUI:

Roaming

Station Roaming

Station Roaming feature is available only for 802.11 wireless protocol and only for station modes. When RouterOS wireless client is connected to the AP using 802.11 wireless protocol it will periodically perform the background scan with specific time intervals. When the background scan will find an AP with better signal it will try to roam to that AP. The time intervals between the background scans will become shorter when the wireless signal becomes worse and the background scan interval will become longer when the wireless client signal will get better.

VLAN tagging

Sub-menu: /interface wireless

With VLAN tagging it is possible to separate Virtual AP traffic on Ethernet side of "locally forwarding" AP (the one on which wireless interfaces are bridged with Ethernet). This is necessary to separate e.g. "management" and "guest" network traffic of Ethernet side of APs.

VLAN is assigned for wireless interface and as a result all data coming from wireless gets tagged with this tag and only data with this tag will send out over wireless. This works for all wireless protocols except that on Nv2 there's no Virtual AP support.

You can configure your RADIUS authentication server to assign users or groups of users to a specific VLAN when they authenticate to the network. To use this option you will need to use RADIUS attributes.

Note: In case to use this option you must enable wireless-fp or wireless-cm2 package for RouterOS version up to 6.37. Starting from RouterOS v6.37 you can do that with regular wireless package.

Vlan tag override

Per-interface VLAN tag can be overridden on per-client basis by means of access-list and RADIUS attributes (for both - regular wireless and wireless controller).

This way traffic can be separated between wireless clients even on the same interface, but must be used with care - only "interface VLAN" broadcast/multicast traffic will be sent out. If working broadcast/multicast is necessary for other (overridden) VLANs as well, multicast-helper can be used for now (this changes every multicast packet to unicast and then it is only sent to clients with matching VLAN ids).

Winbox

Winbox is a small utility that allows administration of Mikrotik RouterOS using a fast and simple GUI.

Note: Current Tx Power gives you information about transmit power currently used at specific data rate. Currently not supported for Atheros 802.11ac chips (e.g. QCA98xx).

Interworking Realms setting

Starting from RouterOS v6.42rc27 we have added such feature:

realms-raw - list of strings with hex values. Each string specifies contents of "NAI Realm Tuple", excluding "NAI Realm Data Field Length" field.

Each hex encoded string must consist of the following fields:

- NAI Realm Encoding (1 byte)
- NAI Realm Length (1 byte)
- NAI Realm (variable)
- EAP Method Count (1 byte)
- EAP Method Tuples (variable)

For example, value "00045465737401020d00" decodes as:

- NAI Realm Encoding: 0 (rfc4282)
- NAI Realm Length: 4
- NAI Realm: Test
- EAP Method Count: 1
- EAP Method Length: 2
- EAP Method Tuple: TLS, no EAP method parameters

Note, that setting "realms-raw=00045465737401020d00" produces the same advertisement contents as setting "realms=Test:eap-tls".

Refer to 802.11-2016, section 9.4.5.10 for full NAI Realm encoding.