clients not connecting to nearest AP

[marty_5769526]

I have clients that connect two to three AP's away for some reason when they have an AP in their room and one in the next room. Even when there are not more then ten people on that AP it does it making their signal strength like 50 percent. Am i doing something wrong or?

[primoz_marinsek]

Here's my theory Marty

I see that you have APs configures on very different channels. There are 2 on UNII1 (36,44) and one in UNII3 on 161. Higher channels usually have higher power limits, so it would make sense to me that clients would choose the AP using the higher channels.

What if you set both APs in the same UNII band?

[keith_redfield]

That seems like a pretty smart answer even if it proves false!

[bill_burns_6069]

Marty:
Have you gotten a resolution to your issue?

I have seen something similar where a client will connect to a distant AP w/ a much weaker signal and have connectivity problems as a result.

This is especially an issue for dual-band clients that are set to prefer the 2.4Ghz band. (or possibly if there is interference in the 5Ghz band)

When Ruckus load balancing features are turned on, running inSSIDer on a dual-band client will show the 2.4Ghz signal alternating between very stong and non-existant.
This is a result of Ruckus load balancing causing the AP to provide very delayed responses to the client in hopes of steering the client to the 5Ghz band.

Unfortunately, the client may instead associate to a distant 2.4Ghz radio.
(have you gotten tired of hearing that it's the *client* that's responsible for roaming decisions?)

Solutions:
Turn-off a 2.4Ghz band preference on the wifi client (if it has that option) or set it to prefer 5Ghz.
Provide specific SSIDs for only 2.4Ghz and only 5Ghz operation. (which will supress band steering when a client associates w/ one of those specific SSIDs)
More extreme: Provide per-radio SSIDs. (I.E. an extra 2 SSIDs per AP throughout the organization) That way a user can manually choose which AP to associate with.

A (band-aid?) solution that does not involve adding SSIDs might be to turn off load-balancing on the one AP that the client has trouble connecting to.
(That option *might* be available w/ the very latest firmware. Otherwise, it will require a call to tech-support, and that config may not persist through an AP reboot)
This may also have the negative result of causing clients that should have associated with distant APs to associate with the local non-loadbalancing AP.

Let me know if any of that helps.

[nick_281894]

I've had this problem quite often although I'm not using load-balancing but just band-steering.

I'm not sure what type of clients you have, but we use mostly Lenovo T400, T410, T420,and T430's with different Intel adapters and removing the full Intel Wifi Software Suite and replacing with the latest driver-only package + changing the adapter settings for Roaming Aggressiveness from "Medium" to "Medium-High" fixed 95% of those issues. Before we would have notebooks that refused to roam when going to conference rooms, etc.

I know this probably isn't the answer you want to hear (far easier to control it on the AP side) but it was the fix for our environment.

[bill_burns_6069]

I was able to replicate the problem on a Lenovo x220. (near one particular AP)
"Intel" driver 14.2.0.10
Roaming aggressiveness is "medium" (the default)

Yup. This issue is related to band-steering.

Glad to hear you found your fix.
It's an academic environment here.
There's no way I can update drivers or settings for all clients.