received deauth: class 3 frame received (7) -> using capsman no problem

I have an issue with several android phones where I get the following error:
@wlan2: disconnected, received deauth: class 3 frame received (7)
some of them connect immediately, some of them connect in 1/5 tries and some of them 1/10 tries with the above error.

The same AP (WAP AC v6.48.3) if I change the configuration to CAPsMAN it works immediately with the same clients. The moment their wifi is turned on they IMMEDIATELY connect fine.

If I change back to non-capsman mode the problem comes back.

I have reset the wifi interface and just added the SSID and the security profile which is wpa2-aes (like in the capsman mode) and the problem returns.

I change back to CAPsMAN mode and problem is solved.

Any ideas except moving to CAPsMAN mode?

Similar problem here.
A Xiaomi Redmi 9 tries to connect to cAP wifi AP and at 5GHz it is not possibile due to the error in the subject.
On 2.4Ghz there is no problem.

Using dynamic WPA2 key with aes only.

exactly the same problem here. Still exists in v6.49
Any suggestions?

I have a Xiaomi 11T phone and the same problem when trying to login to hAPac3 on 5GHz. I tried to activate CAPsman and the login was successful. I spent two days searching for the difference between configuration via CAPsman and without it. I found it - I guess. The problem is that by default, when configuring the WLAN Interface in menu “Advanced”, “Distance” is set to “dynamic.” After I changed it to “indoors”, the phone connects quickly and without problems. In the “dynamics” settings, the phone does not have time to “negotiate” with the MKT.
Solved for me …

Description of the item from the MKT manual:
distance (integer | dynamic | indoors; Default: dynamic)

How long to wait for confirmation of unicast frames (ACKs) before considering transmission unsuccessful, or in short ACK-Timeout. Distance value has these behaviors:

Dynamic - causes AP to detect and use the smallest timeout that works with all connected clients.
Indoor - uses the default ACK timeout value that the hardware chip manufacturer has set.
Number - uses the input value in formula: ACK-timeout = ((distance * 1000) + 299) / 300 us;

Acknowledgments are not used in Nstreme / NV2 protocols.

Thx.
Had the same problem on hap ac2 and a couple of chinese phones (Realme and Xiaomi).
Tried different settings and somehow it worked after this:
WMM support & bridge-mode: enabled–> disabled
Installation: any → indoor
Advanced: Distance: dynamic → indoors
I’ll try changing it all back to see if it is only the distance setting :slight_smile:

Thanks Benny.
I’ve noted in the other thread too. Looks like a common issue with mikrotik. Great work finding this out.

Hi,
I also used your recommended settings and combined with another which worked for me:
WMM support:enabled–> disabled
bridge-mode: enabled
Installation: any → indoor
Advanced: Distance: dynamic → indoors
Advanced: Disconnect Timeout: 00:00:03 → 00:00:15

Maybe it helps to other also too