hAP ax3: WiFi stopped roaming after "unset disable-pmkid"

I was playing with the config per my other thread (hAP ax3 / MBP: intermittent packet loss) and it appears I broke something and cannot quite figure out what exactly.

As can be seen in the linked post, I had disable-pmkid=yes on the WiFi interface which I set in hopes it would improve connectivity. It did not and today I wanted to revert this change by running /interface/wifi/security unset disable-pmkid .... And my 5Ghz interface stopped working (2.4Ghz still works fine).

I removed the related config, reset the interface itself, rebooted the AP then reconfigured the wifi interface. But I cannot bring it to life. None of my devices list it and I cannot connect to it by the SSID either.

Can you spot anything wrong in the config below?

/interface wifi channel
add band=5ghz-ax disabled=no name="WiFi 5" reselect-interval=2h..8h \
    skip-dfs-channels=all width=20/40/80mhz
/interface wifi security
add authentication-types=wpa2-psk connect-priority=0 disabled=no ft=no ft-over-ds=no \
    group-key-update=1d name="WiFi 5" wps=disable
/interface wifi configuration
add channel="WiFi 5" country="United States" disabled=no mode=ap multicast-enhance=\
    enabled name="WiFi 5" security="WiFi 5" security.connect-priority=0 ssid=\
    "WiFi 5" tx-power=18
/interface wifi
set [ find default-name=wifi1 ] arp=enabled configuration="WiFi 5" disabled=no name=\
    wifi-5

A peculiar thing is that under “/interface” the interface is designated as “SLAVE” while under “/interface/wifi” it’s “MASTER”.

You could remove and install the wifi-qcom package.

That’d be the last resort.

Confirmed with Wireshark in monitoring mode that the AP is not sending beacon frames using the mac address of the affected interface.

The frequency-scan and spectral-scan tools to work. I suppose the interface is not bricked.

I think I understand how and what I accidentally broke.

As I mentioned in the linked post, I disabled the DFS channels and set reselect-interval on the channel profile. This allowed AP to pick frequencies that are not supported by my devices (U-NII-4).

For a day I was lucky as the AP avoided these frequencies. But changing the disable-pmkid setting must have triggered re-selection and it happened to pick 5885.

I will borrow channel profile configuration from @mkx’s post in http://forum.mikrotik.com/t/wifi-roaming-for-wpa3-broken-again-somewhere-from-7-17-1-to-7-18beta5-edit-solved/181801/4 :slight_smile:

Main reason why I always set frequencies manually, even on capsman installations.
Then I know upfront what I should see where.

This is wise.

Nevertheless troubleshoot was difficult. Likely insurmountable to normal users. A SoHo AP needs to be friendlier.

But how could it be made friendler? Do you have suggestions? I mean, your device(s) did not support U-NII-4. So, should Winbox show a warning message like? “Beware! U-NII-4 frequency is active in use”. A regular user would not be smarter when reading this either and any other users would complain about “nagging message” they want to get rid off. Providing a config option to “disable U-NII-4 channels” is something that does not help here neither. So how could it be improved? Some toggle labelled “maximum compatibility mode” that basically disables all that could maybe incompatible with older devices? If yes, then people come here whining about even slower wifi operation - as maximum compatibility means maximum old standards and settings.

7 checkboxes for “usable channels”:
U-NII-1 5160-5240 (32-48)
U-NII-2A 5260-5340 (52-68)
U-NII-2C 5480-5700 (96-140)
U-NII-2C/3 5720 (144)
U-NII-3 5745-5825 (149-165)
U-NII-3/4 5845 (169)
U-NII-4 5865-5885 (173-177)
+1:
all of them
and a note like:
U-NII-1 up to U-NII-2C/3 are compatible with most client devices
U-NII-3 and greater are compatible only with more recent devices (typically 2016 or later)

With a default for the first 4 checked would IMHO go a long way.

Exactly. The concept of “default” / “unset” being equal to all supported by the radio is not great. To that extent I mostly dislike how “default” is implemented in RouterOS. print needs to display concrete values and use graphics / color / formatting to disambiguate user settings from default.

And it’s not impossible for an AP to keep track of channels that a given client was able to connect to. An intelligent suggestion / warning can be deduced here and you don’t need to go full OpenAI.