the main go "mad" and do not work as expected
Some strong statements here on TKIP, and difficult to verify what of these are relevant with a specific (MT) implementation.
It feels unpleasant as RouterOS lets you tick TKIP and AES, and also WPA and WPA2, and the ac models support different encodings (DSSS, OFDM) and rates (1-54,HT0-7, VHT0-9) for 802.11a,b,g,n,ac.
What is compatible with what? And what are the consequences of a choice on the other fields? Using TKIP with n or ac is a problem mitigated in different ways.(Like automatic fall back to g, in Intel 2.4 GHz chipset) (
https://www.intel.com/content/www/us/en ... eless.html).
There are issues with coexistence in the encoding, like 802.11n-greenfield and 802.11n-mixedmode. Where documents say "greenfield" mode will not be recognized by b and g, and as such require rts/cts for a graceful coexistence. Other documents say manufacturers have given up on "greenfield" and always set "mixedmode" because of too many complaints. The effect in transmissions of just one b client transmitting on an AP is documented as well.
Effects of coexisting encryption is not that clear. (Didn't find it documented). We know that WEP and TKIP does not handle fast transmissions (or is even prohibited in the standards). But what happens if 802.11g and 802.11n and TKIP and AES (and WPA and WPA2) is ticked in the configuration? MT is not clear on this, and shows odd behaviour (e.g. they set support for b rate for n-only, and set no support for g/n !? in the wiki, they corrected the basic rate already there for n-only)
2.4ghz-onlyn, 2.4ghz-b/g/n basic-b, supported-b, basic-a/g, supported-a/g, ht-basic-mcs, ht-supported-mcs
2.4ghz-g/n basic-a/g,supported-a/g,ht-basic-mcs,ht-supported-mcs
.
So it is unclear what to expect, unclear on what to set. Too many combinations, even with the b-encoding out of scope. Other brands .... e.g. set TKIP on WPA and AES on WPA2 with such a multiple selection. What is the MT implementation? ("Registration table" shows the interface rate and what encryption and what authentication type is actually used). The encoding standard (a,b,g,n,ac) is not in that table (didn't find it). Can the used encryption influence the encoding of the radio ???? I don't know. At least I see no relation with the special and very old 802.11b. I expect no "mad" behavior, but can be wrong.
The client device preferring TKIP if enabled but able to use AES is not what we want to see as outcome. Using different security profiles to limit the mixing up seems a very good idea. (I do use a virtual AP for creating a WPA2/PSK exception for old Windows 7 laptops (limited on MAC in an access list), where the main SSID is WPA2/EAP. Customer ('s guest) is king).
Calling a printer that supports only TKIP just crap, is not given for everyone, and depends on the budget/lifestyle of owner and possible unique features of the device. I would not throw it out, and add a hAP Lite as wifi interface if TKIP is a real problem for the regular AP. Or if the printer is wifi only, use the hAP Lite to deliver the TKIP encryption.