Motivation

RouterOS has a reputation for having difficult-to-configure WiFi, and in comparison to the big-name home APs, this is true. MikroTik APs do not drop out of the box and present a four-screen wizard on your smartphone, then go, ”♬ Ta-da! ♪ That’s all there is to it!” In compensation, MikroTik’s home-grade WiFi APs give you a huge amount of power over competing hardware.

But what if you don’t need all that power? What if the core reasons you’re using MikroTik hardware at home do not include any love for the RouterOS WiFi feature set, and you merely wanted to get that task done in the same box as the one giving you the services that you were specifically reaching for when you selected a RouterOS box?

That’s my situation. My first several RouterOS products were wired-only devices, and when I did eventually buy a few MikroTik WiFi products to try out, they were for ancillary purposes. It was years after I began reworking my wired network in terms of RouterOS before I took the big step of replacing my home Internet gateway with a MikroTik AP, and even then, I was more motivated by getting better control over my home’s DNS setup than to improve WiFi.

With all this in mind, I present the following minimal-effort single-AP WiFi configuration for use by others like me, ones who treat WiFi as an expedience for mobile hosts, used when one cannot be bothered to drag one’s carcass over to a proper wired host, praise be Saint Metcalfe. 😜

Before I get to that, I must drop in a caveat: I make no attempt to cover pre-802.11ax hardware, since I have zero experience with it. Configuration can be quite different with it under RouterOS, I am told, owing to the multiple levels of redesign needed to track changes in the wider WiFi world. My latest setup using the following configuration uses a Chateau PRO ax, but I’ve also tested it on all three main variants of the hAP line: ax³, ax², and lite.¹

The Configuration

The basic setup divested of extras like guest networking is:

/interface wifi configuration
  add name=homeapcfg country="United States" mode=ap \
  ssid="Your SSID Goes Here" channel.skip-dfs-channels=10min-cac \
  security.authentication-types=wpa2-psk,wpa3-psk \
  .passphrase="yourPSKgoesHere" .ft=yes .ft-over-ds=yes
/interface wifi
  set [ find default-name=wifi1 ] name=wifi5 \
    configuration=homeapcfg channel.band=5ghz-ax .width=20/40/80mhz
  set [ find default-name=wifi2 ] \
    configuration=homeapcfg channel.band=2ghz-ax .width=20mhz

It may interest you that this is all in accord with Apple’s WiFi recommendations. You can find a lot of people crying online about how MikroTik WiFi is “incompatible” with Apple gear, but that is most definitely not my experience. If you are one of those having trouble, try my configuration — suitably adjusted for local conditions — before giving up and joining the carp-and-moan squad.

With that out of the way, let us now get to the broader “whys” of this configuration.

Factoring of Concerns

One of the most powerful features of RouterOS WiFi is that it allows you to factor common elements of the configuration out into a single location in accord with the DRY principle. We see that above in the named configuration section, which I then refer to by name=homeapcfg on each radio. This allows each of the following lines to configure per-radio items without repeating the elements common to both.

RouterOS also allows factoring out other configuration sections, but because this is a purposefully simple configuration, it suffices to give these directives as part of the configuration line. If we did not care about having a compact expression of our intent, we could instead have said:

/interface wifi configuration
add name=homeapcfg country="United States" mode=ap ssid="Your SSID Goes Here"

/interface wifi channel
add name=homeapchan2 skip-dfs-channels=10min-cac band=2ghz-ax width=20mhz
add name=homeapchan5 skip-dfs-channels=10min-cac band=5ghz-ax width=20/40/80mhz

/interface wifi security
add name=homeapsec authentication-types=wpa2-psk,wpa3-psk \
passphrase="yourPSKgoesHere" ft=yes ft-over-ds=yes

/interface wifi
set [ find default-name=wifi1 ] name=wifi5 \
  channel=homeapchan5 \
  configuration=homeapcfg \
  security=homeapsec
set [ find default-name=wifi2 ] \
  channel=homeapchan2 \
  configuration=homeapcfg \
  security=homeapsec

The key thing to realize is that this says precisely the same thing! It is merely more verbose, not more virtuous on any useful axis of measurement. If you happen to like this version better, please do realize that this is purely an aesthetic judgement.

For myself, the deciding aesthetic in designing the terse configuration above was that the channel and security configurations do not differ between my dual-band AP’s radios, giving me zero reason to factor them out separately. This is what leads me to judge this second version needlessly verbose.

Inversely, a good reason to use named channel and security settings is when you have to apply them in two or more locations, but not on all radios. Since this is where we get into the available complexities of RouterOS WiFi configuration, it is where we leave the topic behind, having promised above to keep things simple in this article.

Interface Naming

The RouterOS default configuration applies the wifi1 and wifi2 names according to details of hardware configuration and initialization-time contingencies. I chose to rename them in order to create a simple mnemonic: wifi2 is the 2.4 GHz radio, and wifi5 is the 5 GHz radio. This scheme is not only easy to remember months later when you need to revisit the setup, it happens to allow me to leave the default “wifi2” name untouched.

…provided, that is, that the interfaces are in the same order as on my Chateau PRO ax and ax³ units here, which they might not be, even if you happen to have the “same” AP there! I have received reliable reports that the interfaces might be swapped, requiring you to change the name parameter above accordingly.²

Transitional WPA+PSK

Since I do not yet live in a world where all of my devices are capable of speaking WPA3, but I do want that option available for the devices that can make use of it, I apply the transitional WPA2/WPA3 security profile you see above.

Because this is a “home AP” configuration, I saw no reason to step beyond basic PSK authentication. The only other security measures I take here regarding WiFi are covered in my guest WiFi setup.

Roaming

Given that this configuration is designed with a single AP in mind, you may be asking why you need to take into account roaming considerations. The answer is simple: when you give the 2.4 GHz and 5 GHz radios the same SSID and PSK like we have above, the roaming rules apply when clients transition between them, too.

This means one option you have is to give the two radios different SSIDs, delegating to the user the decision of which radio to connect to. There are points in favor of that, particularly when you find that you do not like RouterOS’s design decisions in this regard, but I choose to leave it to the AP. In the instances where I catch a client connecting to the wrong³ radio, bouncing the client’s WiFi connection fixes it.

In service of this, I choose to enable RouterOS’ recently-added “Fast Transitions” features, collectively implementing the 802.11k/r/v standards.

Channel Widths

2.4 GHz

The default RouterOS WiFi configuration sets a highly questionable default: it allows 40 MHz channel widths on the 2.4 GHz band. The only situation where that makes sense is when you’re so far out into the country that your nearest neighbors’ WiFi radios can’t even see yours. This judgement is a direct consequence of the fact that if you restrict yourself to 20 MHz of bandwidth per channel, there are only four non-overlapping channels in most countries⁴ but when you enable 40 MHz channels, you cut that in half, allowing just two channels.

Two!

This is likely to be a problem even out on a large isolated farm, where you want to have continuous coverage across the whole property, a fact you can infer from a combination of the four-color map theorem and the realization that real-world RF propagation doesn’t stop at black-line borders as on an idealized political map.⁵

Therefore, one of my key changes is to disable 40 MHz support on the 2.4 GHz radio, being always-wrong here.

5 GHz

The greater space afforded the 5 GHz bands makes for a more complicated decision. Here in the US, my Chateau PRO ax allows non-overlapping channel plans under the following scheme:⁶

Band	Bandwidth
U-NII-1	80 MHz
U-NII-2A	80 MHz
U-NII-2C	240 MHz
U-NII-3+4	160 MHz

Note that the actual bandwidths set aside by our FCC are wider, and that this hardware will not even try to use the U-NII-2B band. Other countries will have their own rules, complicating this still further.

In crowded contexts such as urban, shared-living situations, restricting channel widths can improve overall WiFi performance. If this is your situation, you owe it to yourself to try disabling 80 MHz channels at the least, and possibly 40 MHz as well. This will give a lower maximum bandwidth for each individual client, but it may at the same time make them more resilient to being bounced off the network due to neighbor interference.

As of this writing, there are only two home-style APs from MikroTik capable of 160 MHz channels: the Chateau PRO ax and the wAP ax, but even presuming they broaden their lineup with this feature, the situation will be much as with 40 MHz channels on 2.4 GHz: it’s wise to enable that only in large open areas where hogging the entire U-NII-2C or U-NII-3+4 band with a single radio is a defensible decision.

There’s one further complication: when configured as above, I have seen MikroTik APs auto-select a 5 GHz channel outside the capabilities of my WiFi clients, giving the appearance that the 5 GHz radio is dead. If you cannot get connected to the 5 GHz radio even while standing right next to the AP with a modern smartphone or laptop, try this variation:

/interface/wifi
set wifi5 channel.frequency=5150-5725

That restricts the 5 GHz radio to the U-NII-1 thru U-NII-2C bands. I have personally observed this fixing the symptom here.⁷

Alternatively, there is a settings change coming in RouterOS 7.20 to make it deprioritize the U-NII-3+4 band, which may be good enough for your purposes, but when I tried it here, I still ended up needing to force the AP not to use those bands at all before I could reliably connect to the 5 GHz radio.

DFS Channels

You may have guessed from the Motivation section above that I am not a WiFi expert. I readily acknowledge that I have no strong opinion on use of DFS channels, and even if I did, decisions made here in my home may have zero relevance to the RF situation you find yourself in. I therefore leave you with this purposefully vague advice: adjust this to match local needs. Sorry, but I can’t tell you what is best for you.

Manual Channel Selection

The configuration above purposefully leaves the RouterOS automatic channel selection behavior enabled, and it is for a very simple reason: I cannot control what my neighbors do.

I do not believe any of the few good reasons for setting channels manually apply to me:

Temporary interference testing and avoidance.
Planned multi-AP networks within a large, well-defined space.

The channel range restriction above is the closest I come to justifying fiddling with channels on a per-AP basis in a home setting. If you find yourself picking and choosing individual channels, I have to ask what basis you have for believing that the optimal channel you picked today will continue working tomorrow and indefinitely into the future. The only cases where that is likely is that you’ve got a coverage area large enough to justify manual WiFi channel planning. The classic case is a hospitality installation where you have big parking lots separating your property from the neighboring ones, and you’ve crammed so many APs into your space that you require manual fiddling to get them all to cooperate.

Conclusion

For basic home WiFi, you may find no reason to make things any more complicated than shown in the first configuration block above. Those of a mind to elaborate their configuration beyond this are nevertheless encouraged to keep the DRY principle in mind, factoring the setup for minimum redundancy.

License

^{^} In case you’re wondering why a non-fan of WiFi like me keeps buying different APs, my reasons are both complicated and barely interesting enough for a footnote. I originally had an ax³ in this role, but when it began misbehaving, I thought it might be damaged and replaced it with the present Chateau. I’m glad I did even though the ax³ turned out to be fine, because the replacement has twice the MIMO output, allowing greater range and speed. As for the smaller units, I bought them for portable use, as when on the road and needing either a “utility router” or a WAP bridge.
^{^} My current hypothesis for the reason behind this is that the US and European versions of the hardware differ in this regard, but I have yet to see enough data to accept that as proven.
^{^} read: 2.4 GHz in cases where the client is capable of 5 GHz
^{^} …three in North America!
^{^} And heaven help you if you’ve got a 3D problem, as with a multi-story hotel!
^{^} You can ask RouterOS to divulge the union set of local RF regulations and the hardware’s capabilities with the /interface/wifi/radio/reg-info command.
^{^} My current hypothesis explaining this is based on the fact that that U-NII-4 only has 75 MHz set aside for it. While U-NII-3 is adjacent and adds another 125 MHz, a client may choose to respect the divisions the FCC has defined and thus only work when a chosen 80 MHz channel is entirely in the U-NII-3 range. This may be one of the reasons that dropping to a maximum channel width of 40 MHz helps: it reduces the chance that the AP will choose a channel that spans this boundary.

MikroTik Solutions

Simple Home WiFi