I've recently decided to take advantage of the new wifi-qcom-ac package and upgrade my home network (consisting of two hAP ac^2s and one Audience) from RouterOS 6.49.10 to RouterOS 7.13, since they're all ARM devices. I was running CAPsMAN before, and after some fumblings with new configuration options, I seem to have all but restored my old CAPsMAN configuration in the new CAPsMAN configuration menu. However, there are two things that are still unclear to me, and I can't seem to find documentation, or any sort of reliable information on these issues.

1. What is going on with the bands? First of all, when you open the WiFi > Channel menu and go to add a channel, there's a 'band' option, which lists not frequency bands, but wifi standards, such as 2GHz G, 2GHz N, 5GHz AC, etc., but that, I suppose, is a carry-over from RouterOS 6.

What is not a carry-over from RouterOS 6, however, is how limited those options seem to be. There is no '2GHz B/G/N' option. Not even a G/N one. You can choose only G, N or AX for 2GHz. And it wouldn't be confusing at all if you could select multiple. But you can't.


Some little experimenting shows that: (1) if you select AX and assign the channel to a non-AX-capable interface, it will not start, saying "no supported channels", (2) if you select, say, 2GHz N and assign it to a 2GHz interface, it will start and say "Channel: 24..../n" in the Status tab and (3) if you instead select 2GHz G, it will start and say "Channel: 24..../g". There's also such a "band" as '5GHz A/N'. If you select it while also setting channel width to either '20MHz' or '20/40MHz', the Status tab will show "Channel: 5....../n[/....]". Furthermore, if you log into a different router running 6.49.10 for a minute, you'll see that an active 2GHz interface with the band set to '2GHz-B/G/N' and channel width set to 20MHz will show "Channel: 24..../20/gn(....dBm)" in the Status tab. A 5GHz interface will then show "Channel: 5....../20/ac(....dBm)" in the Status tab in A/N/AC mode and "Channel: 5....../20/an(....dBm)" in A/N mode.

So, my question is, does wifi-qcom-ac support 2GHz G/N operation mode, and how can I set it to operate in it, and be sure that it is really operating it? Similarly, does it support A/N/AC? I want my WiFi network to be backwards-compatible with all this stuff. And how do bands work in RouterOS 7, anyway?

2. Where is the rate configuration? In RouterOS 6.49, there was an option in CAPsMAN to configure basic and supported rates, so that the AP wouldn't be trying to send a beacon and 802.11b 1Mbps basic rate. This is obviously a non-issue if ROS 7 doesn't even support 802.11b in the first place, but if it somehow does (again, I'm not sure what the bands mean nowadays), how can I make sure that the AP doesn't decide to use 802.11b basic rates?

(on the screenshot are rate configuration options from CAPsMAN on RouterOS 6.49.10)


P.S. On the subject of deep 802.11 configuration options, props to MikroTik for finally adding DTIM and beacon interval configuration options.

P.P.S. I'm asking all of this because neither the absence of 2GHz-B/G/N, 2GHz-G/N and 5GHz-A/N/AC modes nor the absence of rate configuration, which, from my point of view, are pretty important features, aren't mentioned in the 'Cons' section of wifi-qcom-ac package in the docs. Could it be that my package is just somehow borked?

1. I think the only reasonable channel band setting is leaving it unset. Unless you have compatibility issues, defining this setting will only make things worse.
2. Unfortunately rates currently cannot be customized in new wifi drivers.

I think the only reasonable channel band setting is leaving it unset.

Ah. Please pardon me, in trying to remember and do everything, I forgot to mention, that's exactly what I did.

I manually assigned channel configurations to static cap and local interfaces, and the channel configurations have no set bands. In the Status tab 2GHz interfaces have "Channel: 24..../n" and 5GHz interfaces "Channel: 5....../ac[/........]".

And now I am confused as to whether this means that they run in B/G/N and A/N/AC modes respectively, or just in N and AC.

The lower standards (at least G/A and newer) are still included. I don't know if this also includes B, I hope not.

Well, I think this more or less answers my questions then. Thank you.

It'd be nice if MikroTik came out with a more definitive statement on how radios behave with regards to bands with wifi-qcom-ac on ROS 7.13. And whether or not 802.11b is supported and if you can turn it off, along with its basic rates.

It'd also be nice to have configuration options for all of this, but at the end of the day, if the default is optimal, they have many other things to work on.

Have some 802.11b only device lying around? The ultimative test.

Have some 802.11b only device lying around?

I thought I didn't. But then I thought to myself "wait, new devices still support 802.11b, maybe I can force a wifi card into 802.11b mode". And I also thought "but this is gonna be hard, isn't it?" And I also also thought "Linux is generally better for that, I'm gonna go try to do that with Linux". And then I proceeded to spend an entire hour trying to do that with Linux. Failing that, I rebooted back into Windows, went into Device Manager as a last-ditch effort, and there it was, literally the first setting, wireless mode.


Armed with this marvelous tool which you apparently have to be a Microsoft employee to develop, I started testing. And what I found shook me to my core...


"Now that", I thought, "is an image, that will instantly persuade anyone to switch to MikroTik". Okay, not really. But at least I can blackmail MikroTik into giving me vast sums of wealth by threatening to release this image publicly.

Okay, jokes aside, I then proceeded to test all modes with all band settings. I'll spare you the dramatic writing, selecting '2GHz-N' makes the AP work with B/G/N, and '5GHz-AC' with A/N/AC, and selecting '2GHz-G' does appear to remove N support.

So there we have it. The 'band' setting sets the maximum supported WiFi 802.11 standard, with all standards below it always supported. And if the interface doesn't support set band, it fails with the 'no supported channels' message.

Which then makes the "where are my basic rates?" question kind of more of a pressing matter. Because they went away after installing wifi-qcom-ac, and personally I'd like to have them back. And please, at least give me the option to disable 802.11b entirely. It's old. It's slow. Just give it something for the pain and let it die.

Summing up all the exploratory endeavors, the answers are:

1. The 'band' setting sets the maximum supported WiFi 802.11 standard, with all standards below it always supported. And if the interface doesn't support set band, it fails with the 'no supported channels' message. If the 'band' setting is unset, the interface will operate as if the 'band' setting was set to the most recent 802.11 standard that is also supported by the interface. All in all, leaving it unset seems to be the best option with RouterOS 7.13, especially in mixed ac/ax CAPsMAN-controlled networks.

1.1. No, you cannot turn off 802.11b.

2. The rate configuration went out to get the milk, and didn't come back in wifi-qcom-ac. (i.e. it is currently unavailable with new wifi drivers)

Thanks to @whatever, @infabo and @mkx for helping solve this case.

1. The 'band' setting sets the maximum supported WiFi 802.11 standard ...

... and as @whatever already mentioned in his post #2 above, if it's unset, then device will assume its highest supported standard.

Not a big issue if configuring local interfaces (one can always set this property to whatever valid for a particular radio), but when configuring capsman-managed network of caps of different generations (i.e. ac vs. ax) it is mostly better to leave it unset ... so that caps can operate up to hardware-supported standard (you don't want to limit your ax devices to ac standard, do you?).

... and as @whatever already mentioned in his post #2 above, if it's unset, then device will assume its highest supported standard.

Thank you. This is indeed quite important.

I've edited the summary thingamajig, it's now there.

This with supported-bands not matching in provisioning rules of Capsman might be also connected to all this mess with the bands. And this with the bands is what I was wondering for few days until I hit this topic.