Thisdocument applies to 7.12 and older. The WifiWave2 package contains software for managing compatible 802.11ax and 802.11ac wave 2 wireless interfaces. New versions use the new wifi package and corresponding manual.
Builds for x86, ppc, mmips and tile architectures contain the configuration utilities needed to centrally manage interfaces (as a CAPsMAN controller). Builds for arm and arm64 also contain interface drivers and firmware.
The WifiWave2 package in RouterOS adds certain Wave2 features, and 802.11ax devices require it. Some products which ship with the standard 'wireless' package, can replace it with wifiwave2, for more details, please see this section.
Configuration in the command line is done under /interface/wifiwave2/, when using a graphical configuration tool (WinBox or WebFig), wifiwave2 interfaces can be configured using either the 'Wireless' or 'QuickSet' tabs.
Opportunistic wireless encryption (OWE) allows the creation of wireless networks that do not require the knowledge of a password to connect, but still offer the benefits of traffic encryption and management frame protection. It is an improvement on regular open access points.
However, since a network cannot be simultaneously encrypted and unencrypted, 2 separate interface configurations are required to offer connectivity to older devices that do not support OWE and offer the benefits of OWE to devices that do.
Client devices that support OWE will prefer the OWE interface. If you don't see any devices in your registration table that are associating with the regular open AP, you may want to move on from running a transition mode setup to a single OWE-encrypted interface.
This optional flexibility is meant to allow each user to arrange their configuration in a way that makes the most sense for them, but it also means that each parameter may have different values assigned to it in different sections of the configuration.
If you are at any point unsure of which parameter value will be used for an interface, consult the actual-configuration menu. For an example of configuration profile usage, see the following example.
Connections, which have been accepted by an access list rule, will be periodically checked, to see if they remain within the permitted time and signal-range. If they do not, they will be terminated.
The access list has two kinds of parameters - filtering, and action. Filtering properties are only used for matching clients, to whom the access list rule should be applied to. Action parameters can change connection parameters for that specific client and potentially overriding its default connection parameters with ones specified in the access list rule.
When a client device tries to associate with an AP, which is configured to perform MAC address authentication, the AP will send an access-request message to a RADIUS server with the device's MAC address as the user name and an empty password. If the RADIUS server answers with access-accept to such a request, the AP proceeds with whatever regular authentication procedure (passphrase or EAP authentication) is configured for the interface.
Assigning a different passphrase for a specific client can be useful, if you need to provide wireless access to a client, but don't want to share your wireless password, or don't want to create a separate SSID. When the matching client will connect to this network, instead of using the password defined in the interface configuration, the access list will make that client use a different password. Just make that the specific client doesn't get matched by a more generic access list rule first.
The '/interface/wifiwave2/frequency-scan wifi1' command provides information about RF conditions on available channels that can be obtained by running the frequency-scan command. Used to approximate the spectrum usage, it can be useful to find less crowded frequencies.
The '/interface wifiwave2 scan' command will scan for access points and print out information about any APs it detects. It doesn't show the frequency usage, per channel, but it will reveal all access points that are transmitting. You can use the "connect" button, to initiate a connection to a specific AP.
The sniffer command enables monitor mode on a wireless interface. This turns the interface into a passive receiver for all WiFi transmissions.
The command continuously prints out information on received packets and can save them locally to a pcap file or stream them using the TZSP protocol.
Information about the capabilities of each radio can be gained by running the `/interface/wifiwave2/radio print detail` command. It can be useful to see what bands are supported by the interface and what channels can be selected. The country profile that is applied to the interface will influence the results.
While Radio information gives us information about supported channel width, it is also possible to deduce this information from the product page, to do so you need to check the following parameters: number of chains, max data rate. Once you know these parameters, you need to check the modulation and coding scheme (MCS) table, for example, here:
If we take hAP ax2, as an example, we can see that number of chains is 2, and the max data rate is 1200 - 1201 in the MCS table. In the MCS table we need to find entry for 2 spatial streams - chains, and the respective data rate, which in this case shows us that 80MHz is the maximum supported channel width.
More specifically, the Controlled Access Point system Manager (CAPsMAN) allows the centralization of wireless network management. 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.
CAPsMAN in WifiWave2 uses the same menu as a regular WifiWave2 interface, meaning when you pass configuration to CAPs, you have to use the same configuration, security, channel configuration, etc. as you would for regular WifiWave2 interfaces.
Installing the wifiwave2 package disables other means of configuring wireless interfaces. Before installation, make sure to back up any wireless and regular CAPsMAN configuration you may want to retain.
It is also possible to install the WifiWave2 package on other devices to use WifiWave2 CAPsMAN: builds for x86, ppc, mmips and tile architectures contain the configuration utilities needed to centrally manage interfaces (as a CAPsMAN controller). Builds for arm and arm64 also contain interface drivers and firmware.
Length of time to cache RADIUS server replies, when MAC address authentication is enabled.
This resolves issues with client device authentication timing out due to (comparatively high latency of RADIUS server replies.
With the multicast-enhance feature enabled, an AP will convert every multicast-addressed IP or IPv6 packet into multiple unicast-addressed frames for each connected station.
This may improve link throughput and reliability since, unlike multicast frames, unicasts are acknowledged by stations and transmitted using a higher data rate.
Default VLAN ID to assign to client devices connecting to this interface (only relevant to interfaces in AP mode).
When a client is assigned a VLAN ID, traffic coming from the client is automatically tagged with the ID and only packets tagged with with this ID are forwarded to the client.
Default: none
APs within the same connect group do not allow more than 1 client device with the same MAC address. This is to prevent malicious authorized users from intercepting traffic intended to other users ('MacStealer' attack) or performing a denial of service attack by spoofing the MAC address of a victim.
All client devices MUST support the group encryption cipher used by the AP to connect, and some client devices (notably, Intel 8260) will also fail to connect if the list of unicast ciphers includes any they don't support.
This parameter provides a way to mitigate such attacks by specifying a threshold of in-progress SAE authentications, at which the AP will start requesting that client devices include a cookie bound to their MAC address in their authentication requests. It will then only process authentication requests which contain valid cookies.
By default, a dynamic neighbor group is created for each set of APs with the same SSID and authentication settings.
APs operating in the 5GHz band are indicated to be preferable to ones operating in the 2.4GHz band.
If included in the string, character sequence %I will be replaced by the system identity of the cAP. %C will be replaced with the cAP's TLS certificate's Common Name.
Hello, first of all i'm completely Newbie, so i'm not sure that this answer already given or not... i tried to find the solution and tried to setup the configuration, but nothing worked... below is described my problem..
I'm using Openwrt LEDE Reboot 17.01.6 r3979-2252731af4 on my TP-Link TL-MR3420 v2 router .. I have Mikrotik Routerboard as Access Point.. But because of the poor signal i decided to use this router as Extender which will connect with my Mikrotik RouterBoard.. I want to connect my router as Extender of my main Mikrotik Router.. Also the Extender name will be different .. For example my main Router AP Name "HZ_Mikrotik" and the Openwrt Router AP Name will be "HZ_Mikrotik_Repeater"... The devices will connect to the Openwrt router , but they will take the DHCP IP from the main router(Mikrotik Routerboard)..
If i just connect my devices with my openwrt router it can't get the IP address from main router, but if i give static IP address, gateway and DNS it works and i can get reply by pinging the device's ip from my main router.. also i get the ip address from ARP list..
Want: How can i also get the DHCP list when i will connect my device via Openwrt.. The same environment works when i used my TP-Link Extender 850RE without any problem.. i didn't use any WDS system but it worked.. but i don't have the repeater no more and i just want to setp my OpenWRT Router...
3a8082e126