Wireless Access

We have aruba ap installed for almost a year however there is an issue that keep bothering me that is the clients are not connecting to the nearest ap instead it is connecting to the ap a floor above or below. Our building is full of concrete wall and signal is hard to travel from one room to another.  As a result, when the client is connect to the ap above, the signal is not good and will affect the transfer rate. i did a ping test with the client machine connecting to ap at one floor above there is a lot of connection drop. i had disable channel load balancing, but it is not helping. Appreciate for any useful advice

Please try the solution in the thread here:  http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/quot-Sticky-Client-quot-Problems/m-p/9123/highlight/true#M3478

Are these clients running Windows? I have seen this issue with older wifi drivers on Windows computers. Please ensure that the drivers are up to date.

no. they are all mac client. all the driver is up to date. However, i heard from someone telling me that mac is not good in wireless. :(

Ok. Please try the steps in the thread that Colin posted, and let us know how it goes.

i had remove the 802.11g transmit rate of 1, 2, 5 and will monitor the status.

Sounds like you've got sticky clients.

If removing those transmit rates doesn't work it might be worth trying Station Handoff Assist.

Station Handoff Assist.

Allows the controller to force a client off an AP when the RSSI drops below a defined minimum threshold.
Default: Disabled

James.

---

@jrwhitehead wrote:

Sounds like you've got sticky clients.

 

If removing those transmit rates doesn't work it might be worth trying Station Handoff Assist.

 

Station Handoff Assist.

Allows the controller to force a client off an AP when the RSSI drops below a defined minimum threshold.
Default: Disabled

 

James.

---

There are a few clients out there that will not associate if they do not see the lower rates, so removing them is no longer a preferred method.  Using station handoff is also no longer a preferred method, because it sends deauths to a client when it is at a certain signal level and some clients consider this disruptive.

Please use the local-probe-response-threshold method, since that is the more modern, standards-based and least disruptive method to clients.

Ah well it looks like abcstop has got the wrong end of the stick with the link you posted and has disabled the lower data rates.

Thanks for the info on the station handoff assist!

I see that this is the bit you were referring to in the linked post:

------------------------------------------------------------------------------------------------------------

As of ArubaOS 5.0.3 and 3.4.3 and above, there is a parameter in the SSID profile called local-probe-req-thresh which will ignore probes from clients that are below a certain threshold

(Aruba3200) (SSID Profile "test") #local-probe-req-thresh ?
                        requests will get ignored (only used if
                        local-probe-response is also enabled)

You should try it with an SNR of 20

------------------------------------------------------------------------------------------------------------

jrwhitehead,

I can see how abcstop got the wrong idea.  Thanks for that clarification.

We had similar issues with Apple devices sticking and not being able to connect, low signal, the whole kit.

Coverage is not an issue with this location, plenty of APs

Spoke with TAC and they recommended the following changes.

1. Station handoff Assist set to 25

2. Local Probe Request Threshold (dB) set to 30

3. Deny_Broadcast Probes (unchecked)

4. Opportunistic Key Caching (uncheck it)

5. Check certificate common name against AAA server (uncheck it)

I did a bit more research and enabled Validate PMKID.

The changes seemed to help quite a bit but recently, they complained about 2 iPads not being able to connect.

Looking at Airwave and some logs, I posted this

http://community.arubanetworks.com/t5/Wireless-IPS-and-Content/Block-Ack-Attack-the-cause-of-wifi-outage/td-p/48270

Looking at the trap, it does not seem like the Block Ack Attack was the cause but the user's SNR was 10, they were probably trying to connect to an AP too far away.

I then called TAC and they are now recommending to enable DOS Prevention.

I figure also we should remove the G data rates 1 and 2.

I am not too sure what to do at this point

Hello everyone.

Having the same issue on a 15 building deployment.

VisualRF with no precision when trying to determine the client location because the client located on 4th floor is associated to the 6th AP for example.

I tried to set Local Probe Treshold request but no success. 

How far apart are your access points Felipecomputer and what is the output power on each radio?

Hi

How far apart are your access points

About 220 ft - Horizontal
           65 ft -  Vertical

what is the output power on each radio?

Please see the attached file.
90% of our clients are windows desktops with 802.11 N Wireless adapters.

Thanks.

Attachment(s)

issued_floor.txt   35 KB 1 version

thanks for the update, i had enable the 1,2,5 transmit rate and set a SNR ratio to 20. Will monitor the status

After the changes, i notice that there are still around 5-10% of the device with SNR lower than 20 most of the are iphone and blackberry minority of them are macbook. I will continue to monitor the status.

Do you have a screenshot of where you made the change?

the changes was done by using command line 

(Aruba3200) (SSID Profile "test") #local-probe-req-thresh 20

Is "test" the SSID your users are connecting to?

yes it is.

hi guy,

is there any further enhancement that can be done as i am still facing this issue although the number of affected machine reduced.

Please try changing the local probe threshold parameter to 25.

Nothing is perfect, and each client uses a different algorithm to determine when to roam.  It is not realistic to assume that clients will always connect to the strongest signal.  You just do not want users with a poor client experience.