Wireless Access

 

I recently upgraded controllers (620) from 5.0.3.3 to 6.1.3.6.  I have one location that called in to report that wireless coverage in the office was severely degraded, and that previously they've had no issues for 2+ years.

 

I ran through all the usual - update drivers, patches, etc.

 

I put the office in Airwave and the office clearly did not have enough coverage - 2 APs & approximately 10k sq ft.  That gives me enough "evidence" that I need to give them a few more APs to cover the dead areas, but unfortunately it takes time to get approval, ship, and coordinate with a vendor to do the install.

 

Still, it was bothering me that nothing had changed other than the firmware upgrade.  I've upgraded 75% of our offices and had no other complaints.

 

Looking at the new functionality on the controller, I just couldn't find any information to support what was being reported.  Everything was being reported within "acceptable" ranges.  I apparently lost historical data in Airwave during the last upgrade, so I could only go back a few weeks - not enough in there to call the user crazy.

 

After dealing with it for a week, I decided to roll back to the older firmware.  Called the user today and got "did you do something?  Everything is better!"

 

Any reason an upgrade to the latest would cause something like this?

I hope you opened a case.  That would take some time to understand.

 

Sorry, haven't been able to open a case.  PO for support renewal was just approved - expired in Oct and renewal quote has been sitting on a desk since Dec.  :manfrustrated:

 

APs are AP-93 (2.4ghz).

 

Ended up sending out 3 more APs for coverage for one particular location, and the other issue will hopefully be corrected by moving the AP closer.

 

Not much you can do when the intial deployment was intended to cover the desk farms and not the outer offices ("they don't need wireless, they were all cabled").

 

Just seemed strange that the complaints started after the upgrade, and in these cases we are talking about a range of about 10 ft.

 

Was just wondering if there was any sort of explanation - maybe some added features in the new code or something that I could use to give to management.

hi Cole1

 

one possibility is that the reg domain power levels changed, if the APs were on max tx power before the upgrade, and we updated the max EIRP, we could have reduced power slightly. Whilst this is a possibility, the more likely case is due to CSD override, please try turning it off, it lives in ht-radio-profile default-g / ht-radio-profile default-a and was enabled by default in 6.1.3.2 and higher.

 

this feature which changes the way we transmit to clients can change the perceived RSSI at the client in some cases, try turning it off (no impact to APs/clients if you make the change on running system)

 

regards

-jeff

I'm having similar issues on 6.2.0.2 (upgraded from 6.1.3.1) so I'm trying turning that CSD off now.

I'll let you know if there's any improvement.

 

Enabling CSD-Overide, does it not give 2x2 or 3x3 MIMO on AP104/AP105, AP92/AP93, AP124/AP125 and AP134/AP135 respectively. 

 

or it would affect only AP92, AP104, AP134, the ones with external antennas? sending out single stream on the first antenna port. 

 

What i understand is enabling CSD-Overide is going to bring down the through-put for the n-radio clinets, please correct if i am wrong. 

 

 

According to the 6.1.3.2 release notes:

 

"Single-chain-legacy is Renamed CSD-override Starting with ArubaOS 6.1.3.2, the single-chain-legacy parameter in high-throughput radio profile has been renamed to csd-override. When this feature is enabled, all legacy transmissions will be sent using a single antenna. This enables interoperability for legacy or high-throughput stations that cannot decode 802.11n cyclic shift diversity (CSD) data, and changes 802.11n transmission by restricting CSD spreading. 

This parameter is enabled by default, and will be enabled when you upgrade to ArubaOS 6.1.3.2, regardless of whether the single-chain-legacy setting was enabled or disabled before the upgrade. Do not disable this feature unless you do not need to support legacy or high-throughput stations that cannot support 802.11n CSD data. Use the command rf ht-radio-profile <profile> csd-override to enable this feature, or disable it using the command rf ht-radio-profile <profile> no csd-override."

 

So it is on by default, and if you feel that you have less range, try turning it off.  I want to say that it is that straightforward.

What type of Access-points are in use? 

Have you got a case open, and can you tell me what your status is?

We have a similar issue in 6.2.0.2 and haven't had much TAC response after the initail triage.

 

I can tell you that the fewer details that are provided, the less likely your issue will be resolved. If you are not currently on the build with the issues, it is less likely TAC will see what your problem is, because there is no information to gather..