Frequent wireless disconnections occurring since upgrade to 10.21.01.0065

[Steve_Ballantyn]

I apologize for the redundant question. It seems like "clients disconnecting" is a common topic. But I am starting a new one, because it seems that every situation is different.

I have a C5210 and a bunch of 3825i AP's all over my hospital. Just before Christmas I upgraded to the latest firmware, 10.21.01.0065. Since then I am getting complaints from users (across the board) that they are frequently getting dropped from WiFi. After it happens they are easily able to reconnect and all is well. But it's driving them mad as they will be in mid-sentence documenting in their various applications and then it sort of freezes up and KAPOW! Connection lost!

There is nothing newer to upgrade to. And I suppose I could downgrade to see if the problems goes away. But I would rather seek out the source of the problem and fix it. Especially if it's just something wacky in my configuration.

I plan on putting in a call and opening a ticket on Monday morning with support. But in the meantime - does anyone have any ideas for me? I use Netsight and Purview, and I have all of these logs and diagnostic data at my disposal, but I am not really sure where to start. I suppose the first question is - does anyone else have this issue with this firmware?

[Steve_Ballantyn]

Hello Jeremy, I am not seeing Band Preference Steering in my ap.log's and I don't see that option anywhere. Is that perhaps a model-specific feature? I have all 3825i AP's.

[Jeremy_Gibbs]

Do you have Band Steering enabled?.. I agree, I also have seen this when a client is roaming from one radio to another. However, I didn't pay any attention in the direction of the roam (2.4->5 5->2.4).

Also, if you ssh to your AP... user root password new2day.

Run this

tail -f /tmp/log/ap.log | grep "Band Preference Steering"

[Steve_Ballantyn]

Hey Jeremy, if I wanted to check for this problem with my equipment - what would I search my ap.log files for? I can run traces off my AP's and maybe we can see if there is a common problem there.

I have noticed that at least two of my drops in the past few days were with clients going from 5ghz to 2.4Ghz on a roam and I wonder if there was some sort of struggle there.

[FES]

other improvements... (if somebody dont think like me let me know ;D)

set DTIM from 5 to 3.
enable MSDUs and MPDUs
enable LDPC
set power in radio1 to 10dbm or less if you have a lot of aps
set power in radio2 to 6 dbm or less if you have a lot of aps
set channel plan to 3 channels. if you set it in auto the channel plan sets in 4 channel. (more cochannel interferences).
set protection method CTS and RTS.
Enable all DFS channels in radio a ( not use 144 channel).
Use 20Mhz in radio a not 40 to avoid cochannel interferences (also in radio a with high density scenario)

you can see the AP report to know the APs that have high use of air. Above 50% are a lot of collisions that is no so good.
In order to fix aps channel you have to enable active mode in aps for 2 hours and after this change to monitor mode (do this during the night for example).

more ideas???
sorry for my english

[Joshua_Puusep]

FES is referring to the Chnl Utilization lines. You can also see this under the "AP Performance by Radio" Report. Of all the settings mentioned, the only one that has previously caused client disconnects for us is having DCS set to active, which was on a 9.x release and you have already stated is not the case. The other settings mentioned could improve performance, but i don't believe they should cause client disconnects unless there is a related bug.

Since you are already planning on opening a ticket with GTAC, i would ask them for recommended radio settings prior to making a slew of changes at once. Their recommendations do change from time to time.

Have you replicated the issue with various types of devices and or confirmed the user devices have the latest available WAN drivers?