HELP! Clients continously connecting/disconnecting!

RouterOS Wireless Networking
1

Asked this question in another thread without finding any solution, and now I’m getting a little desperate so I try again:

My AP is a RB 333 with rc5, R52 Radio in 2.4 GHz.

I have several old Linksys clients that I need to connect (customers won’t spend money on MT CPEs now).

When the AP is running and I reboot the clients they associate all fine with the AP.
When for some reason the clients are disassociated by the AP (change in wireless settings, updating access list, rebooting the AP etc) the clients associate and then de-associate after exactly 20 seconds, then immediately re-associate, disconnect after another 20 seconds and so on…
Some clients stick to the AP after a limited number of attempts but others try again and again maybe for hours.

Here is the log:

22:58:48 wireless,debug wlan2: 00:0F:66:5B:21:07 attempts to associate 
22:58:48 wireless,debug wlan2: 00:0F:66:5B:21:07 in local ACL, accept 
22:58:48 wireless,info 00:0F:66:5B:21:07@wlan2: connected 
22:58:48 wireless,info 00:14:BF:D2:5C:6A@wlan2: disconnected, received disassoc:
 class 3 frame received (7) 
22:58:49 wireless,debug wlan2: 00:14:BF:D2:5C:6A attempts to associate 
22:58:49 wireless,debug wlan2: 00:14:BF:D2:5C:6A in local ACL, accept 
22:58:49 wireless,info 00:14:BF:D2:5C:6A@wlan2: connected 
22:58:50 wireless,info 00:12:17:BC:D0:4F@wlan2: disconnected, received disassoc:
 class 3 frame received (7) 
22:58:51 wireless,debug wlan2: 00:12:17:BC:D0:4F attempts to associate 
22:58:51 wireless,debug wlan2: 00:12:17:BC:D0:4F in local ACL, accept 
22:58:51 wireless,info 00:12:17:BC:D0:4F@wlan2: connected 
22:59:08 wireless,info 00:0F:66:5B:21:07@wlan2: disconnected, received disassoc:
 class 3 frame received (7) 
22:59:09 wireless,debug wlan2: 00:0F:66:5B:21:07 attempts to associate 
22:59:09 wireless,debug wlan2: 00:0F:66:5B:21:07 in local ACL, accept 
22:59:09 wireless,info 00:0F:66:5B:21:07@wlan2: connected 
22:59:09 wireless,info 00:14:BF:D2:5C:6A@wlan2: disconnected, received disassoc:
 class 3 frame received (7) 
22:59:10 wireless,debug wlan2: 00:14:BF:D2:5C:6A attempts to associate 
22:59:10 wireless,debug wlan2: 00:14:BF:D2:5C:6A in local ACL, accept 
22:59:10 wireless,info 00:14:BF:D2:5C:6A@wlan2: connected 
22:59:11 wireless,info 00:12:17:BC:D0:4F@wlan2: disconnected, received disassoc:

I got the tip to increase Hardware retries but that didn’t work.

After all, what is this disassoc: class 3 frame received (7) that the clients apparently send, and why do they disconnect?

Linksys clients are Broadcom based and R52 is Atheros, is it likely that these chipsets don’t talk very well to eachother?
What can I do about it in ROS?

2

Upgraded to rc9 and now it’s even worse!

With rc5 the clients stayed associated for 20 seconds, now they disconnect immediately, but without any further error message:

08:10:19 wireless,info 00:14:BF:D2:5C:6A@wlan2: connected 
08:10:20 wireless,debug wlan2: 00:0F:66:5B:21:07 attempts to associate 
08:10:20 wireless,info 00:0F:66:5B:21:07@wlan2: reassociating 
08:10:20 wireless,info 00:0F:66:5B:21:07@wlan2: disconnected, ok 
08:10:20 wireless,debug wlan2: 00:0F:66:5B:21:07 in local ACL, accept 
08:10:20 wireless,info 00:0F:66:5B:21:07@wlan2: connected 
08:10:20 wireless,debug wlan2: 00:12:17:BC:D0:4F attempts to associate 
08:10:20 wireless,info 00:12:17:BC:D0:4F@wlan2: reassociating 
08:10:20 wireless,info 00:12:17:BC:D0:4F@wlan2: disconnected, ok 
08:10:20 wireless,debug wlan2: 00:12:17:BC:D0:4F in local ACL, accept 
08:10:20 wireless,info 00:12:17:BC:D0:4F@wlan2: connected 
08:10:20 wireless,debug wlan2: 00:14:BF:D2:5C:6A attempts to associate 
08:10:20 wireless,info 00:14:BF:D2:5C:6A@wlan2: reassociating 
08:10:20 wireless,info 00:14:BF:D2:5C:6A@wlan2: disconnected, ok 
08:10:20 wireless,debug wlan2: 00:14:BF:D2:5C:6A in local ACL, accept 
08:10:20 wireless,info 00:14:BF:D2:5C:6A@wlan2: connected 
08:10:21 wireless,debug wlan2: 00:0F:66:5B:21:07 attempts to associate 
08:10:21 wireless,info 00:0F:66:5B:21:07@wlan2: reassociating 
08:10:21 wireless,info 00:0F:66:5B:21:07@wlan2: disconnected, ok 
08:10:21 wireless,debug wlan2: 00:0F:66:5B:21:07 in local ACL, accept 
08:10:21 wireless,info 00:0F:66:5B:21:07@wlan2: connected 
08:10:21 wireless,debug wlan2: 00:12:17:BC:D0:4F attempts to associate 
08:10:21 wireless,info 00:12:17:BC:D0:4F@wlan2: reassociating 
08:10:21 wireless,info 00:12:17:BC:D0:4F@wlan2: disconnected, ok 
08:10:21 wireless,debug wlan2: 00:12:17:BC:D0:4F in local ACL, accept 
08:10:21 wireless,info 00:12:17:BC:D0:4F@wlan2: connected 
08:10:21 wireless,debug wlan2: 00:14:BF:D2:5C:6A attempts to associate 
08:10:21 wireless,info 00:14:BF:D2:5C:6A@wlan2: reassociating 
08:10:21 wireless,info 00:14:BF:D2:5C:6A@wlan2: disconnected, ok 
08:10:21 wireless,debug wlan2: 00:14:BF:D2:5C:6A in local ACL, accept 
08:10:21 wireless,info 00:14:BF:D2:5C:6A@wlan2: connected 
08:10:22 wireless,debug wlan2: 00:0F:66:5B:21:07 attempts to associate 
08:10:22 wireless,info 00:0F:66:5B:21:07@wlan2: reassociating 
08:10:22 wireless,info 00:0F:66:5B:21:07@wlan2: disconnected, ok 
08:10:22 wireless,debug wlan2: 00:0F:66:5B:21:07 in local ACL, accept 
08:10:22 wireless,info 00:0F:66:5B:21:07@wlan2: connected 
08:10:22 wireless,debug wlan2: 00:12:17:BC:D0:4F attempts to associate 
08:10:22 wireless,info 00:12:17:BC:D0:4F@wlan2: reassociating 
08:10:22 wireless,info 00:12:17:BC:D0:4F@wlan2: disconnected, ok 
08:10:22 wireless,debug wlan2: 00:12:17:BC:D0:4F in local ACL, accept 
08:10:22 wireless,info 00:12:17:BC:D0:4F@wlan2: connected

Uldis/Normis, are you there?
wireless.jpg

3

BUMP

Nobody that have experienced this? :open_mouth:

There must be some kind of workaround to this, parameters that can be changed or something?
Any tips are welcome!

4

it could be rf noise.

on a couple try b only (not g)

b is moe stable with high noise

5

Noise floor is approx -100, I manually picked the clearest channel, i.e. 2452 MHz.
RSSI measurement on clients are between -60 and -78 dBm, noise about -95 dBm.

Same clients with same firmware associated all fine to the old AP, a Linksys WRT54G with a 12 dBi omni which I’m certain was picking up a lot more noise.
Then SNR was as low as 5 for some of the clients, now it is 20 to 35. Most of the clients stay at 48 or 54Mbps once associated.
Current antenna is a 90 dBi sector.

To start re-considering the whole problem:
Is this about the client giving up, or is it thrown out by the AP?

Apparently something is different between rc5 and rc9.
In rc5 clients stayed associated for 20 seconds, then went away with the “disconnected, received disassoc: class 3 frame received (7)” log message. In rc9 they are flashing in for a second or two, and then gone without any other message than “disconnected, ok”

6

I have no idea

Are they in your access list?
What if you try defualt authenticate?

Are you using WEP/WPA perhaps disable this (just to test) to try narrow the problem down

7

They are all in my access list, copied there from the registration list (at the time they were all associated after being rebooted).
Have also tried default authenticate, no luck.
Anyway If I disable one of them in the access list (with def.auth. false) they won’t show up in the registration list at all.

No encryption enabled.

For my PPPoE server running on another inteface (wlan1) I get pretty detailed log output. Are there any log topics I can enable to get more information about what’s going on on this problem interface wlan2?
Topic wireless is enabled but does only output "disconnected, ok ".

Is there a chance that changing my R52 for another card will do the trick?

8

I have this same problem. The client is a broadcom chipset (buffalo)… Only variable to change is the upgrade from ROS 2.9 to 3rc10

please help,
Joe

9

I must say I’m a little wary of v3rcx right now - I had a pretty bad experience replacing a burnt out routerboard with an Intel based mini ITX PC running v3rc6, using the same original wireless cards & hardware as before. Signal strengths were not as good as before, and link quality (CCQ) and throughput dismal.

Changing out the motherboards with RB532’s running 2.9.xx fixed the problems…

Unfortunately I was not able to experiment and dig deeper to try and determine the root of the problem, but on the surface it certainly looked as if v3 was the culprit.

I have similar miniITX boards running elsewhere with no problems, but using 2.9.xx. Unfortunately 2.9.xx does not have Ethernet drivers for these boards, so I’m limited to using them only where I don’t need Ethernet, or where I only need 1 mini PCI + 1 ethernet…

10

The clients are failing to see a beacon, so they reattempt to associate, and when they do the ap throws out the already established connection.

11

that could be… try using the ‘sniff’ tool and click the ‘packets’ option - it may give you more to work on…

12

Solved for me: http://forum.mikrotik.com/viewtopic.php?p=95373#p95373

13

I believe this problem was fixed in the 2.9.46 version?

14

The problems are with the 3.0 beta.. 2.xx works fine.

15

Same problem, we need major ROS update. New RBs (RB333 and RB600) are unusable with RC13

16

I stongly disagree with your statement.
My RB333 has been running for 29 days now without problems. 3x R52, one 5GHz and two on 2.4. PPPoE server and firewall.
Initially I had big problems with frequent reboots on rc10. Upgraded to rc13 and upgraded the BIOS, this solved my problems.

I don’t know the exact reason for the wireless disconnect issue, but it was solved for me by upgrading the clients (Linksys with Sveasoft).

17

bomber67..

I tried the link you posted but there is no page there, can you tell us what you did.

Erik

18

You want to Decrease not Increase the hardware retries.

19

I figured out that upgrading the CPEs to the latest firmware did the trick. The CPEs are Linksys WRT54G (Broadcom) and at that time “latest” meant Talisman 1.3.1.

20

Hello Bomber67, hello everybody,

I have exactly the same problem with RB333 with up-to-date firmware and ros 3.0rc14.
I use cpe Linksys WRT54GL with DDwrtV23.sp2 for firmware.
I use WPA / TKIP mode for security.
But with RB532, no problem with V9.3x–>v9.48 and same config for cpe.

What news about your problem, have you got any solution ?

Thanks for your informations.
Regards.

Eric from France.