I have a RB600(default mk v3.7) with a R52H card set to AP-BRidge, 2.4B-G and all default configuration.
I set a security profile to dynamic keys, Wpa2 PSK, AES CCM, AES CCM, and a wpa2 pre-shared key.

Now the problem:
Group Key Update is set default(00:05:00)

My client (router wilress zinwell 2.4G) connect but after 5 min the log show: "<MAC>@<INTERFACE> DISCONNECTED, GROUP KEY EXCHANGE TIME OUT".

After 1 second show: <MAC>@<INTERFACE>: connected

My final customer does not see it remains connected by pppoe.
I replaced the wireless router by another mark but the problem remains.

What can I do???

Same thing happens to me, but don't know an answer

The group key is used to do broadcasts in the wireless network. Without it, it wouldn't be possible to talk to all stations at once since each have a different dinamic key.

I think you have a client problem.

Altough several manufacturers claim compatibility with WPA2 + AES the truth is there are many broken implementations.

Try reducing to WPA instead of WPA2 and use TKIP instead of AES. Also, try to test only one scheme at a time like WPA2+AES or WPA+TKIP separately. Some clients can't deal with algorithm diversity.

From a security standpoint, since you are using PSK instead of signed certificates there is not much difference in using WPA or WPA2. The main weakness is the key to leak, not get broken...

...yes AES is stronger than TKIP but if absolute strength were your primary concern I think you would't be using a Zinwell client, right?

...also, try to use the latest firmware.

Let us know if it works.

nothing resolved until today

...also, try to use the latest firmware.

Let us know if it works.

Not with 3.11 resolved

i'm still having this problem.

clients are getting disconnected randomly. Has this been resolved? I still see the timeout in the logs.... i've set mine to the max timeout. Since then, dropouts are less.... i don't get this dropping issue with my cisco APs.

forgot to mention i'm using 411UAHR with 2 x 8dbi TPlink antenna's and a R52n wireless card.

WPA/WPA2 with TKIP


any other info you guys need?

Hi.

I want to know if there is a fix for this too... Suddenly I have an AP doing the same thing to 1 customer.. There are just 2 clients on this AP.. Their signals are both -73.. All equipment is MT.

1 card is a Ubiquity the other r52.

I have tried assorted values of HW retries..

I use wpa2 psk with aes and MT management frame protection.

I was wondering if I could use the management frame protection on its own, without any other form of security (obviously mixed with acl entry)

How easy is it to crack the management frame security?

And as someone else pointed out , the disconnects seem more frequent during the nightime as if the RB does get bored.. All the time that I remain logged into the unit via winbox the AP mysteriously holds on to its client. I am logged into the AP via cable.

no help from Mikrotik support? do they check this list? or do we have to email them directly? This disconnection problem is making the wireless router look bad....clients saying whats the diff from SOHO routers if they still face d/c problems with a much more costly mikrotik router.

This is my nightmare with a brand new set-up:

[admin@AP] /log> print

13:09:53 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
13:09:53 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
13:09:53 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
13:09:58 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
13:11:23 system,info,account user admin logged out from 10.17.34.2 via winbox
13:11:36 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
13:11:36 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
13:11:36 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
13:11:41 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
13:12:18 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
13:12:18 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
13:12:18 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
13:12:23 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
13:18:53 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
13:18:53 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
13:18:53 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
13:18:53 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
13:18:53 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
13:18:53 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
13:18:53 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
13:18:53 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
13:18:53 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
13:18:53 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
13:25:23 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
13:25:23 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
13:25:23 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
13:25:23 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
13:25:23 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
13:25:23 wireless,debug Kenepuru: 00:02:6F:4B:27:4D attempts to associate
13:25:23 wireless,info 00:02:6F:4B:27:4D@Kenepuru: reassociating
13:25:23 wireless,info 00:02:6F:4B:27:4D@Kenepuru: disconnected, ok
13:25:23 wireless,debug Kenepuru: 00:02:6F:4B:27:4D in local ACL, accept
13:25:23 wireless,info 00:02:6F:4B:27:4D@Kenepuru: connected
13:40:36 system,info,account user admin logged in from 10.17.34.2 via winbox
13:41:11 system,info,account user admin logged out from 10.17.34.2 via winbox
13:57:54 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
13:57:54 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
13:57:54 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
13:57:59 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
13:58:04 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
13:58:04 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
13:58:04 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
13:58:09 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
14:00:37 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:00:37 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:00:37 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:00:42 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
14:00:51 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:00:51 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:00:51 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:02:45 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, group key exchange timeout
14:02:53 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:02:53 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:02:53 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:10:45 system,info,account user admin logged in from 10.17.34.2 via winbox
14:12:04 system,info,account user admin logged out from 10.17.34.2 via winbox
14:12:45 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, group key exchange timeout
14:12:50 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:12:50 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:12:50 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:12:55 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
14:13:31 system,info,account user admin logged in from 10.17.34.2 via winbox
14:13:48 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:13:48 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:13:48 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:13:53 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
14:15:02 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:15:02 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:15:02 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:15:07 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
14:16:03 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:16:03 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:16:03 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:16:08 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
14:16:47 system,info,account user admin logged in from 10.17.34.2 via telnet
14:16:53 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:16:53 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:16:53 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected
14:16:58 wireless,info 00:0C:42:65:CD:F3@Kenepuru: disconnected, unicast key exchange timeout
14:17:29 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 attempts to associate
14:17:29 wireless,debug Kenepuru: 00:0C:42:65:CD:F3 in local ACL, accept
14:17:29 wireless,info 00:0C:42:65:CD:F3@Kenepuru: connected

[admin@AP] /log>

Half-a-dozen CPE's connect to this AP perfectly happily and yes, the security profile is identical. What is unusual in this case is that I'm using a RH52nM card in the CPE and RouterOS v4.16 because you have to in order to drive the 52nM card - and based on the fact that Mikrotik have been unable to resolve all the complaints about this problem that Google throws up, and that any other card than a Mikrotik one doesn't seem to have the problem at all, one has to assume this is a serious bug/flaw in a Mikrotik product the company is ignoring in the hope it goes away.

Hi

I have 2 clients with ubiquity air-grid m5 and
AP (120 degree 5ghz sector) signal is +-(-60). That is connected in Wds.

The clients gets dropped almost every 5 minutes.

(mac address)disconnected group key exchange timeout
(mac address)connected, wants wds

For both clients

@wireless>security profiles>(my security name)
i see there is a group key update set to 00:05:00?

Is the fault with the router board or with the ubiquity air-grid?

Thanks Jannes Coetzee