MikroTik

Hi,

We are running CAPSMAN controllers on CCR and once in a while on a day, we are getting the messages: "max key exchange retries" in the logs of the central controller.

When this happens, the clients are disconnected and are unable to rejoin/reconnect to the wireless network.

The only workaround for the client is to disable then enable the wireless adapter again before the wireless works fine again for a few hours until this happens again.

When we run the same physical access-points in standalone modus, we do not suffer from this behavior so it must be something capsman related.

We have opened a ticket with MT support, but have not received any helpful feedback.

We've tried V6.29.1/V6.30.1-4/V6.32+V6.32.1, all having the same behavior.

Anyone seeing the same behaviour?

Hello Beone,

have you ever found a solution for this?

Regards

Hello,

Has anyone ever found a solution for this ?
Or know the root of this issue?

Regards

MikroTik's forum is where wifi related questions come to die. Rest in peace little question from a once enthusiastic MikroTik customer, in the assurance that no one will ever bother to follow up, reply or altogether try to make this forum a useful and solid knowledge base.

False. Just none was so happy to see the same behaviour. Generally only supout.rif file sent to the support can enlighten the reason of the problem and show how to correct the situation for the future version.

Cheers jarda. I might try that myself...

Definitely. And keep us informed about the results.

I want to chime in on this topic and would be grateful for a solution.

I have 14 RBcAP2n and a Groove A-52HPn connected to a CCR1009 and managed by Capsman. Firmware on all devices is atm 6.38.8.
WiFi is configured as WPA2-EAP with EAP passthrough to a Windows NPS/Radius Server.

When I try to connect a Win 10 Tablet using 802.1x PEAP, MsChapV2 User Authentication the login prompt pops up, asking the user for his credentials. If the user is slow the popup resets while the user is typing. User gets confused - phones IT. Looking at the mikrotik side of things the client disconnects with and immediately reconnects prompting the user again with the login prompt for about 40 seconds until disconnecting again. (Or the user is quicker this time, hits enter, connects and everybody is happy)

Once it's connected it stays connected. Didn't observe the problem the OT describes where it drops with this error after a while after being connected.
This problem does not occur when using Windows 7 and user authentication.
No problems with android devices or some ~50 computers authenticating over 802.1x with their machine accounts.

No packet is sent to the radius server while the user types his credentials.
I can only assume that the CCR or the RBcAP2n on initial connect presents itself as a 802.1x authenticator to the client (Win10) and waits a preset amount of time for an EAP packet to come in. When the user is not quick enough to type, hit enter and send the packet, the RBcAP resets some session and Win10 starts the login process all over again.

Anyone else got this problem? Is there a hidden timeout to be increased either on mikrotik side or in Win 10?

As said, no problem with Android, Apple, Win7 or 802.1x at all except for this specific use case.

Any hints?

TIA
Christian

Edit: Verified the problem on Win 7. Connection gets also reset with "max key exchange retries" while being in the login prompt. Windows 7 doesn't blank the prompt on reset so the user doesn't notice. Once he hit's enter the EAP packet is sent to the authenticator and discarded with an "EAP failure" (I assume because the RBcAP has opened a new EAP session with the client and the client sends an expired session id).

So please, where can I increase the "EAP handshake timeout" on mikrotik for those extra slow users?

i have the same scenario and the same problem.
Our version is 6.43.6 in CHR and CAPS
Any solution or work around?

thanks,

Sorry for resurrecting this zombie topic, but hopefully it might help someone: got to the Security Cfg. and set the "Group Key Update" to 1 hour or so.