Frequent wireless disconnections occurring since upgrade to 10.21.01.0065


Userlevel 5
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?

51 replies

Userlevel 2
Check ATPC and DCS settings. Disable ATPC and change DCS to monitor mode to test.
Post screenshot of radio settings and advanced radio settings.
Userlevel 5
Evan Kuckelheim wrote:

Check ATPC and DCS settings. Disable ATPC and change DCS to monitor mode to test.
Post screenshot of radio settings and advanced radio settings.

Hello Evan, thanks for the help. It appears that my ATPC is already disabled, and DCS is already set to Monitor.

Here are screenshots of my radio settings, and advanced radio settings.

Userlevel 2
Just curious, what firmware were you on before 10.21.01.0065 ?
Userlevel 5
JP wrote:

Just curious, what firmware were you on before 10.21.01.0065 ?

Hello JP, I was on 10.11.02.0032.
Userlevel 7
Hey Steve,

here what I currently use as standard setting...

- I set the basic rate to 24Mb if the AP coverage allows it = dense deployment
- radio#2 g/n, protection mode none for 11g = I don't support any 802.11b clients
- disabled on the WLAN service = 802.11k, FT, MFP

Could you tell whether the issues is on 2.4Ghz or 5GHz ?



Userlevel 5
Ron wrote:

Hey Steve,

here what I currently use as standard setting...

- I set the basic rate to 24Mb if the AP coverage allows it = dense deployment
- radio#2 g/n, protection mode none for 11g = I don't support any 802.11b clients
- disabled on the WLAN service = 802.11k, FT, MFP

Could you tell whether the issues is on 2.4Ghz or 5GHz ?




Hey Ron, I can try these settings in an secluded area. We have a building that is off on it's own and is having a lot of these problems. I'm sure they won't mind if I tell them I am trying some different settings with them. I do have a very dense deployment of AP's, so I should be able to use these same settings as you.

I am not sure if the clients are 2.4Ghz or 5Ghz. They have all long gone home now and I am not sure how to view the history. I am betting that they are using these Fujitsu Lifebook tablets which are VERY old and would not support 5Ghz.
Userlevel 5
Ron wrote:

Hey Steve,

here what I currently use as standard setting...

- I set the basic rate to 24Mb if the AP coverage allows it = dense deployment
- radio#2 g/n, protection mode none for 11g = I don't support any 802.11b clients
- disabled on the WLAN service = 802.11k, FT, MFP

Could you tell whether the issues is on 2.4Ghz or 5GHz ?




From what I am hearing - the laptops are only about a year old (so they did get replaced at some point). They should at least be on the 'n' band. I have applied all of Ron's suggested settings to the AP's in this building and I am soliciting feedback from the users.

It sucks that all of these Advanced settings cannot be made upon multiple AP's at once using the admin pages. That took me a while!

*EDIT* Ron - do you think any of these settings were changed as a result of the upgrade?
Userlevel 2
Ron wrote:

Hey Steve,

here what I currently use as standard setting...

- I set the basic rate to 24Mb if the AP coverage allows it = dense deployment
- radio#2 g/n, protection mode none for 11g = I don't support any 802.11b clients
- disabled on the WLAN service = 802.11k, FT, MFP

Could you tell whether the issues is on 2.4Ghz or 5GHz ?




Unless its different in v10, you can make the changes on multiple AP's through:
AP-Bulk Config- AP multi-edit. Select multiple AP's and then change the settings on the right. If they are greyed out, you have to start at the top and work your way down until they become active.

***Edit*** - It looks like Ron posted the same thing about making changes to multiple AP's and it does looks like its different in v10.
Userlevel 7
You'd use multi-edit...

Set the checkmark on the APs (only APs from the same series i.e. 38xx in my example) and click on the Action button and choose multi-edit....

Userlevel 5
Ron wrote:

You'd use multi-edit...

Set the checkmark on the APs (only APs from the same series i.e. 38xx in my example) and click on the Action button and choose multi-edit....


I see it now. I feel stupid. I was looking under the Radio 1 and Radio 2 actions drop-downs. Well, nice to know where to find that because I might be applying those settings to another 70 access points!
Userlevel 7
Ron wrote:

You'd use multi-edit...

Set the checkmark on the APs (only APs from the same series i.e. 38xx in my example) and click on the Action button and choose multi-edit....


no need to feel that way - the first time I was .. what the heck they removed multi-edit, should I change the config of 1000 APs one by one 🙂

took me a while to find the option
Userlevel 3
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
Userlevel 5
FES wrote:

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

First off - thanks for all of this advice!

I have no idea what any of these settings are, so I trust you know a lot more than me when it comes to this stuff! Since I had to look them up, I figured I would paste it here from the documentation for the sake of discussion.

DTIM
Type the desired DTIM (Delivery Traffic Indication Message) period — the number of beacon intervals between two DTIM beacons. To ensure the best client power savings, use a large number. Use a small number to minimize broadcast and multicast delay. The default value is 5.

Aggregate MSDUs
Determines MAC Service Data Unit (MSDU) aggregation. Enable to increase the maximum frame transmission size.

Aggregate MPDUs
Determines MAC Protocol Data Unit (MPDU) aggregation. Enable to increase the maximum frame transmission size.

LDPC
Increases the reliability of the transmission resulting in a 2dB increased performance compared to traditional 11n coding.

Monitor Mode
An alarm is triggered and an information log is generated.
Active Mode
An alarm is triggered, an information log is generated, the AP stops operating on the current channel, and ACS automatically selects an alternate channel for the AP to operate on.

Protection Types
CTS
CTS (Clear to Send) Only.
RTS (Request to Send) and CTS
Recommended when a 40 MHz or 80 MHz channel is used. This protects high throughput transmissions on extension channels from interference from non-11n APs and clients.



Question - when you said to check the high use of air, which report was that? When I run the Wireless Statistics by Wireless APs I am seeing a lot of failures. Here is a screenshot ...

Userlevel 4
FES wrote:

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

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?
I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz
Userlevel 5
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

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.
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

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"
Userlevel 5
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

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 wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

Oh, do you have band steering enabled? It's under AP->Load Groups->Radio Preference. You create a Group and assign APs and WLANs to it.

You might not be using it:


Userlevel 5
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

Wow, okay. Thanks for driving me to those options. I do not have anything configured there yet.
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

Since many clients won't connect to 5 Ghz, band steering tries to force 5 Ghz capable clients to the 5 Ghz radio.. Freeing up resources for those who only have a 2.4 Ghz radio. Works well in areas of good 5 Ghz coverage. If 5 Ghz is sparse, I would hold off.
Userlevel 1
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

How do I view the ap.log file? I tried to ssh into ap with admin/new2day, but couldn't get it to work.
Userlevel 1
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

How do I view the ap.log file? I tried to ssh into ap with admin/new2day, but couldn't get it to work.
Userlevel 7
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

ssh into the AP

#change directory
cd /tmp/log

# to show the complete content of the file - increase the window size as you'll get a
# lot of messages, or log it to a file with your ssh app
cat ap.log

or

#to get the last messages "live" as they get written into the file by the AP
tail -f ap.log

The ssh timeout is per default very short so it's a good idea to increase it so you don't get logged out all the time...

cset sshtimeout 99999
capply
csave
Userlevel 5
Jeremy Gibbs wrote:

I am too having some issues with this also. Please post any updates you find here, as this will be very useful to many people! My radio settings are almost the same as Ronald Ds. Using 12 and 24 for the MBR.. 12 in less dense and 24 in most dense areas.

One thing I have noticed, sometimes band-steering tries to force users who don't have an 5 Ghz to 5 Ghz by constantly rejecting their association requests. I have seen this in the new version of code, especially with XBOX 360 consoles. I won't even see the MAC in NetSight until I turn off BS... If you do a tail -f /tmp/log/ap.log | grep -i "mac address of client" you can see the logs for band-steering trying to force a non capable 2.4 client to 5 Ghz

Laura, if the new2day password didn't work, it's because the AP is successfully pulling a config from the controller, and your controller is dictating the password.

You can set/change that password in the web GUI under AP tab > Global Settings (on the left) > Registration. Check the "SSH Access" password. Mine appears to be blank --- which is odd, because I know I have set a password and use it all the time.

Reply