Wireless connection droppping on RB951-2n

RouterOS General
1

I’ve had a new 951-2n set up as an access point/router for a week now but it has not been stable. In particular, it drops wireless connections. I notice somebody else mentioning wireless drops in the 5.18 thread, and this hasn’t been mentioned in the 5.17 or 5.18 release notes. The 951-2n came new with 5.16.

The most common drop is to a Buffalo AirStation bridge that supports a PC behind it. The Buffalo has its own static management IP address (.250) while the PC behind it (XP) pulls a DHCP address from the pool. This worked fine on the old access point (Linksys), though that box itself had a habit of crashing now and then. The Routerboard doesn’t crash; it just loses connections.

The AP has WEP-40 established on its primary SSID and WEP PSK set up on a virtual AP SSID. The dropped connections are on the secondary SSID, which I’ve been using since it’s more secure. (I still need WEP support for some legacy devices, until it can be phased out.) When the connection drops, the Buffalo still sees a strong signal and thinks it’s connected at the WiFi level, but can’t ping the AP. The AP doesn’t show the Buffalo’s MAC address in the registration list, though; it needs to be rebooted. I think a laptop or two has also dropped a connection, though, so it’s not unique to the Buffalo.

Any clues? This may be an issue in recent releases. But it’s the first time I’ve used RouterOS. Thanks.

2

It’s been reported that 5.15 - 5.18 all have wireless dropouts. I’m worried that there will not be anymore “good” 5.x releases with 100% working wireless.

3

Could you clarify which reports you mean? There are no known wireless issues in v5.18


fgoldstein, please enable wireless debug logs, and post the disconnection messages from the log file. It should clarify why it disconnects. http://wiki.mikrotik.com/wiki/Manual:Wireless_Debug_Logs

4

It just happened again. I ran home and copied the log to Notepad before rebooting. The device in question has a MAC ending in :CA.

92 Jun/26/2012 11:55:04 memory wireless, info 00:16:01:70:63:CA@wlan2: disconnected, group key exchange timeout

There are other messages in the log but don’t mention that MAC.

Am I missing any logging options? I thought I had everything on, but it’s just the default.

Note that wlan2 is the virtual AP, with WPA-PSK. Mode “dynamic keys” (default). AES COM, AES CCM.

5

Theres a thread about this exact error in 5.18. Can you try not using wpa as a test?

6

Did you read the previous message:
Note that wlan2 is the virtual AP, with WPA-PSK. Mode “dynamic keys” (default). AES COM, AES CCM.

7

It failed again maybe an hour or two after the last reset. I wasn’t there to catch the log when it had to be reset. But I’m going to move the Buffalo in question from WPA mode to WEP mode to see if that helps. I still wonder if there’s something about my WPA settings that is causing the problem. The link quality is not spectacularly good, if that matters, but it doesn’t fully fail at the physical layer.

8

Thanks, but could you try without WPA?

9

There have been no obvious failures of the WEP connections. However, the Buffalo was the only static one on a desktop; laptop and smartphone connections come and go, and we don’t use the Wii often enough to know. I’ve moved the Buffalo over to WEP and it has stayed up ovenight, not that it’s a long enough test.

10

The error in the log was “disconnected, group key exchange timeout”. The default “group key update” value was set at 00:05:00 (5 minutes/300 seconds). I had no idea what that meant and if it was the same thing, so I googled around and found some exchanges on the topic. This is the time before the group key, which is the secret key used for encryption of the traffic flow, is changed. WPA rotates this regularly. It takes a minute to try to do a new key exchange. Four failures (4 minutes) and it disconnects; apparently one end or the other doesn’t know to try again.

So 5 minutes is the bare minimum allowable value. 30 minutes to an hour is more common; longer is permitted too. So I set it up to 1:30:00 (90 minutes). I haven’t put the Buffalo back there yet but this is likely to reduce the frequency of failures.

Comments welcome.

11

I just turned off encryption. So far I’m just not happy with the wireless on this unit. I think I’m going to put my RB750G back in place and leave the PowerAPN for the wireless. Quite disappointing :frowning:

12

I too was nervous about the dropping issue, has this been resolved on 5.18? I still went ahead with ordering 2 dozen units for some projects, glad that I took one out to test this issue out in the lab. Running fine for 2 days and then this morning…boom! no wireless…sigh :-/

Too bad…sending all 24 back today to supplier in replacement for the 751U/G’s for now…unless someone can verify that 5.18 has resolved this drop out.

Cheers!

13

Did you test all 24 devices?

14

I did not…but I put them all into a big black magicians hat and shook it all up and grabbed one lucky rb951 from the bag of tricks…isn’t that everyone does it? :slight_smile:

Cheers!

15

It seems to me that not all units are affected. Take two more and see how they gonna work. If none of them will work call it three strikes, you’re out. That’s what I would do with such an order. Cheers.

16

I think it’s a software bug, so testing one should suffice.

From the logs, it appears in my case that the problem is the default 5 minute group key lifetime in WPA. (The unit being disconnected is pre-WPA2, but has WPA “1” with AES.) The re-keying sometimes fails. I don’t know the details of the protocol in question but it may be sensitive to the lousy link quality (only a -90 dB typical signal at the AP). WPA assumes four failures and you’re locked out. Four bad passwords I could see; four link failures I couldn’t, and it should unlock, though the protocol might not say so.

17

interesting…so were you able to find a work around in your case?

18

I raised the group key lifetime to 90 minutes, so there are fewer rekeying incidents. So far the failures that have happened have been in the Cisco cable modem itself – now that is giong to need replacement. Of course this has only been a few days; for a while, I was back in WEP mode.

19

It’s going all gaga again! Or as my son asked me when his laptop lost its connection, why am I buying cheap Latvian gear? I told him that it’s because of the good support. BTW I’m still on 5.16, which it came with.

First off, some background. The initial problem for which I started this thread was caused when a WPA (not WPA2) client bridge got locked out. Its RF link was marginal. I patched it by setting it back to WEP (ugh) but I also fixed a problem with its antenna and now its link is strong and reliable. So I have been thinkng of putting it back on WPA. BUT…

Last night I was sitting at my laptop four feet from the access point 951. And I noticed that my laptop had associated with the WEP, not WPA, SSID, even though that’s below it on the list. Then my son marched downstairs to tell me that his laptop (WPA2) had lost its connection too. I captured the log (fortunately raised to 250 entries) before rebooting, which fixed things.

Here’s the laptop:
75 Jul/24/2012 20:37:04 memory wireless, debug wlan2: 70:F1:A1:37:F7:39 attempts to associate
76 Jul/24/2012 20:37:04 memory wireless, info 70:F1:A1:37:F7:39@wlan2: reassociating
77 Jul/24/2012 20:37:04 memory wireless, info 70:F1:A1:37:F7:39@wlan2: disconnected, ok
78 Jul/24/2012 20:37:04 memory wireless, debug wlan2: 70:F1:A1:37:F7:39 not in local ACL, by default accept
79 Jul/24/2012 20:37:04 memory wireless, info 70:F1:A1:37:F7:39@wlan2: connected

That sequence happens many times, and leaves him connected. A little while later:

152 Jul/24/2012 21:40:20 memory wireless, info 70:F1:A1:37:F7:39@wlan2: disconnected, extensive data loss

That is the last entry from his MAC address, which to be sure is not a terribly strong link, but things are starting to go nuts. The next MAC is that of my laptop, whose IP ends in .152, and which is four feet from the AP (-39 dB or so), as i am trying to get it back onto wlan2, the WPA2 virtual AP (the primary AP is WEP):

167 Jul/24/2012 21:45:44 memory wireless, info 00:18:DE:47:D8:2B@wlan2: connected
168 Jul/24/2012 21:45:44 memory wireless, info 00:18:DE:47:D8:2B@wlan2: disconnected, received deauth: unspecified (1)
169 Jul/24/2012 21:45:44 memory wireless, debug wlan2: 00:18:DE:47:D8:2B attempts to associate
170 Jul/24/2012 21:45:44 memory wireless, debug wlan2: 00:18:DE:47:D8:2B not in local ACL, by default accept
171 Jul/24/2012 21:45:44 memory wireless, info 00:18:DE:47:D8:2B@wlan2: connected
172 Jul/24/2012 21:45:49 memory wireless, info 00:18:DE:47:D8:2B@wlan2: disconnected, unicast key exchange timeout

** For some reason the key exchange decided to time out. So the laptop tries again:

173 Jul/24/2012 21:45:49 memory wireless, debug wlan2: 00:18:DE:47:D8:2B attempts to associate
174 Jul/24/2012 21:45:49 memory wireless, debug wlan2: reject 00:18:DE:47:D8:2B, banned (last failure - unicast key exchange timeout)

repeat four more times, then:

183 Jul/24/2012 21:45:54 memory wireless, debug wlan2: 00:18:DE:47:D8:2B attempts to associate
184 Jul/24/2012 21:45:54 memory wireless, debug wlan2: 00:18:DE:47:D8:2B does not provide suitable security method, reject

*** So here I’ve been rejected from WPA2, so it’s moving to the WEP SSID instead:

185 Jul/24/2012 21:45:54 memory wireless, debug wlan1: 00:18:DE:47:D8:2B attempts to associate
186 Jul/24/2012 21:45:54 memory wireless, debug wlan1: 00:18:DE:47:D8:2B not in local ACL, by default accept
187 Jul/24/2012 21:45:54 memory wireless, info 00:18:DE:47:D8:2B@wlan1: connected
188 Jul/24/2012 21:45:55 memory dhcp, info default assigned 192.168.123.152 to 00:18:DE:47:D8:2B

But I’m trying to get to WPA:

189 Jul/24/2012 21:46:02 memory dhcp, info default deassigned 192.168.123.152 from 00:18:DE:47:D8:2B
190 Jul/24/2012 21:46:02 memory wireless, info 00:18:DE:47:D8:2B@wlan1: disconnected, received deauth: unspecified (1)
191 Jul/24/2012 21:46:03 memory wireless, debug wlan2: 00:18:DE:47:D8:2B attempts to associate
192 Jul/24/2012 21:46:03 memory wireless, debug wlan2: reject 00:18:DE:47:D8:2B, banned (last failure - association not possible: invalid AKMP (43))

** repeat five times** Then it goes back to WEP:

201 Jul/24/2012 21:46:06 memory wireless, debug wlan1: 00:18:DE:47:D8:2B attempts to associate
202 Jul/24/2012 21:46:06 memory wireless, debug wlan1: 00:18:DE:47:D8:2B not in local ACL, by default accept
203 Jul/24/2012 21:46:06 memory wireless, info 00:18:DE:47:D8:2B@wlan1: connected
204 Jul/24/2012 21:46:11 memory dhcp, info default assigned 192.168.123.152 to 00:18:DE:47:D8:2B

Then a bit later another node tries to use WPA2:
225 Jul/24/2012 21:48:03 memory wireless, debug wlan2: 00:17:AB:D5:86:62 attempts to associate
226 Jul/24/2012 21:48:03 memory wireless, debug wlan2: 00:17:AB:D5:86:62 not in local ACL, by default accept
227 Jul/24/2012 21:48:03 memory wireless, info 00:17:AB:D5:86:62@wlan2: connected
228 Jul/24/2012 21:48:03 memory wireless, info 00:17:AB:D5:86:62@wlan2: disconnected, received disassoc: sending station leaving (8)

By this point, the Registration table has gone from four to zero WPA2 clients. I reboot and everything comes back up.

So virtual access point wlan2, which uses the WPA2 security profile, lost its ability to authorize or keep even users with strong connections, not to mention ones with flaky connections. There’s clearly something buggy about the code, probably the wpa2 part. Just maybe it’s tied to being a virtual AP. I haven’t flipped the profiles to make WPA2 the primary and WEP virtual.

20

Although 5.18 fixed the major WDS loop issue, im still having problems with WPA2 WDS links, and now with Virtual APS. I posted about the strange results a few days back, in my mind, Virtual APS are also broken,

I hope we have a better response from Mikrotik though: When I contacted them to ask if they would be making the WDS loop fix to MESH , they said it wasnt a priority for them. Maybe. It damn well is a priority for me, as we have 1,300 grooves on site that need mesh.

Your results just confirm this for me.