Client Disconnect Issues

RouterOS Wireless Networking
1

Hello there, we recently installed an RB333 running RouterOS V4 3.0RC14 + XR2 card for PtMP operation. We have about 30 clients, mostly Tranzeo CPQ clients. We use WPA/AES encryption. All clients have the newest firmware installed.

Everything was working great with the new system for almost 5 days without a hiccup, then suddenly, all but one or two clients disassociated and are now showing the following errors while they try to re-associate:

echo: wireless,debug WFCB-EAST: 00:60:B3:5D:5B:FD not in local ACL, by default accept
echo: wireless,debug WFCB-EAST: 00:60:B3:28:7C:F5 attempts to associate
echo: wireless,debug WFCB-EAST: 00:60:B3:28:7C:F5 not in local ACL, by default accept
echo: wireless,debug WFCB-EAST: 00:60:B3:39:30:41 attempts to associate
echo: wireless,debug WFCB-EAST: 00:60:B3:39:30:41 not in local ACL, by default accept
echo: wireless,debug WFCB-EAST: 00:60:B3:28:6C:D1 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:28:6C:D1, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:3D:97:3F attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:3D:97:3F, banned (last failure - unicast key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:30:9F:DC attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:30:9F:DC, banned (last failure - received deauth: 4-way handshake timeout (15))
echo: wireless,debug WFCB-EAST: 00:60:B3:45:32:DC attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:45:32:DC, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:01:F9:53 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:01:F9:53, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:28:6C:D1 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:28:6C:D1, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:3D:97:3F attempts to associate
echo: wireless,debug WFCB-EAST: 00:60:B3:3D:97:3F not in local ACL, by default accept
echo: wireless,debug WFCB-EAST: 00:60:B3:30:9F:DC attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:30:9F:DC, banned (last failure - received deauth: 4-way handshake timeout (15))
echo: wireless,debug WFCB-EAST: 00:60:B3:5D:5B:FD attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:5D:5B:FD, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:28:7C:F5 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:28:7C:F5, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:39:30:41 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:39:30:41, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:45:32:DC attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:45:32:DC, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:01:F9:53 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:01:F9:53, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:28:6C:D1 attempts to associate
echo: wireless,debug WFCB-EAST: 00:60:B3:28:6C:D1 not in local ACL, by default accept
echo: wireless,debug WFCB-EAST: 00:60:B3:30:9F:DC attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:30:9F:DC, banned (last failure - received deauth: 4-way handshake timeout (15))
echo: wireless,debug WFCB-EAST: 00:60:B3:5D:5B:FD attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:5D:5B:FD, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:28:7C:F5 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:28:7C:F5, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:39:30:41 attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:39:30:41, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:45:32:DC attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:45:32:DC, banned (last failure - group key exchange timeout)
echo: wireless,debug WFCB-EAST: 00:60:B3:3D:97:3F attempts to associate
echo: wireless,debug WFCB-EAST: reject 00:60:B3:3D:97:3F, banned (last failure - group key exchange timeout)

The list goes on and on with the majority of clients attempting to associate, then being dropped due to the following errors:
exchange timeout or received deauth:
4-way handshake timeout (15) error.
group key exchange timeout
unicast key exchange timeout

We’ve tried a number of things like adding some of the clients that won’t associate to an ACL (we have not been using one), changing preamble type, allow both tkip and/or AES cypers with WPA, TKIP only, turning WMM off; none of these changes worked in getting any more people associated. We ended up changing back to all of our original settings.

We’ve also tried changing the channels with limited results. Originally we were seeing a -95 noise floor on CH5, we then changed to CH9 (-92 noise). After changing to CH9 we saw a few more people associate, we then changed back to CH5 and even more people were able to associate. Then again within about 10 minutes of changing back to CH5, almost everyone had disassociated again. We noticed that right after everyone disassociates, the noise floor goes to -89. Also, during these “storms”, the TX CCQ on the AP goes down below 20%; during normal operation it typically is around 70-80%.

We’ve also checked the list of MAC’s trying to associate and there are no anomalies there. All MAC’s trying to associate are known, working good clients. No new clients have been installed, or changed. Before the Mikrotik we had a Tranzeo AP at this site for over a year with none of these types of issues.

Any ideas? Thanks in advance!

2

Change your hardware retries to 4 and upgrade to 3.0 full version.

3

Thanks for the reply. The hardware retries are currently set to 8. I’m not sure what you mean by upgrade to 3.0 full version? I believe I have the latest and greatest installed @ 3.0rc14. Any other ideas?

4

You are using rc14. The full release of 3.0 not beta is now available for download.

5

Downloaded and updated Mikrotik to 3.1. Clients still are showing the same association issues in the log file after rebooting the AP. We discovered that if the clients having issues power cycle their systems they seem to associate correctly. I hope the recent updates fix whatever caused this mystery issue. My guess is that there’s some sort of WPA-PSK synchronization issue between the AP and the clients.

6

Set your hardware retries to 4.

7

Can you explain why?

8

Hai frens
i am so sorry, my suggestion is seven, in javanese Seven=PITU same PITULUNGAN or an english is "Will make help you" :wink:
all my roamimg machine set it to seven, and unitl now great.... and nice maybe since 8 months ago.
again, thanks Mikrotik and Team we stay on v2....49.
also, a week ago i have success to made link by wds to next 4th AP will supply my custome far far ways....

regaard
Hasbullah.com

9

4 is Mikrotik’s suggestion for disconnect issues…

10

yes,
cause mikrotik in Latvia, and my suggestion in JAVANESE.
oh....my god. thanks for your help me to make nice sleep until now.... :wink:

regards
Hasbullah.com

11

The original issues went away after we updated ROS, and had the clients power cycle. Now we’re having these issues again with a different, newly installed base station. Exact same configuration as in my first post, except now we’re running ROS 3.6. I’ve tried upgrading to 3.7, and tried tweaking settings with no fix yet. The difference is that roughly 50% of the clients are disassociating after approx. 24 hours, and do not reconnect until they’re power cycled. The same errors listed in my first post are being displayed in the log for the clients that cannot re-associate unless they power cycle. Could this be some sort of Tranzeo CPQ + WPA1/AES + Mikrotik/XR2 issue?

12

Yes, change your hardware retries to 4 and you should be fine.

13

They are, and always have been set to 4. I double checked just to make sure :slight_smile:

14

So change back to 15 :-p

15

Not sure what you mean by ‘change back to 15’. I tried upping the hardware retries to 5-10 without any positive results. It seems as though additional hardware retries do not fix the issue, and the few clients that are able to associate do so much slower compared to the recommended number of 4. I still really would like to know what the errors that I mentioned mean, and what they pertain to. It seems as though the Mikrotik knows that the clients in question are trying to associate, but rejecting them for some reason. The log messages are not verbose enough, and there is not enough information online to decipher what they mean or how to resolve them. This seems to be a very rare issue.

At this point I’m leaning towards the possibility that it may be a bad XR2 card, as we’ve deployed many more of these units now, without issue. In fact, the same Mikrotik box has a second XR2 card serving another sector with exactly the same settings, and client equipment associating without any of these issues. Going to try swapping this out soon and see if it does any good. Please let me know if you have any further suggestions. Thanks!

16

We are seeing the same issue. We took down an AP and moved it to a new pole and now all of the Tranzeo CPE simultaneously disconnect at random periods. The Mikrotik CPE stay associated.

Hardware retries=4. Firmware = 3.7. TxPower backed off to 19 (12) card rates.

Anyone?

17

It appears as though more and more people are having this issue. Can you set your wireless logging to debug mode to make it more verbose and check to see if you’re getting any of the same errors that I’m getting? Look for stuff like:

exchange timeout or received deauth:
4-way handshake timeout (15) error.
group key exchange timeout
unicast key exchange timeout

18

we either need access to one of those APs with the disconnections, or we need one such tranzeo device to repeat the problem here in testing. So far support hasn’t received any valuable information on this. Please email support so we can start working on it.

19

Sent in all information to Mikrotik support, including supout.rif. Waiting for response.

20

i am seeing same issue and with mostly mikrotik clients and we now have a few nano stations in the mix
i will aslo send a autosupout