Wireless Access

Has anyone else with "legacy" APs (AP60 and 65 in my case) made the upgrade to 6.2x?

 

We are fairly happy with the upgrade in general at our AP92/93 sites, but it seems like ARM forgets to turn up the power on the older APs. I've opened a ticket with TAC, but wanted to know what other folks out there are experiencing.

 

Anyone else out there have any trouble with the upgrade?

 

 

I woud open the TAC case.  Just upgrading should not do that, because each AP saves the last power in flash before it reboots.  It should be the same as before upon reboot.  What did you upgrade from?

 

6.1.3.1 was the last running version.

 

We (TAC and I) have determined that ARM is seeking the minEIRP setting, and can't explain why.

With one site, we turned off the ARM OTA update flag and ARM began turning up the power on the access-points.

 

Think we had something, we made the change at our other sites, with no apparent change.

 

Back into the breach today...

After more than a month banging out heads, we've reverted to 6.1.3.1 and near-perfect coverage has been restored.

 

After site-surveys and ARM setting jiggling, and client setting jiggling we're convinced (I and my Aruba Partner) that there's a bug in the 6.2.0.2 code which is causing the controller to mis-read/calculate/interpret the client at a low RSSI value and "assist" it off onto another AP.  Turning off handoff-assist merely hid the problem.

 

Our warehouse management asked us to roll-back and wait for a more definitive fix/plan from Aruba and we went from 80 THOUSAND low RSSI deauths per day to 9 HUNDRED in 35 minutes (my record time for converting 6 controllers and 600 APs)

 

TAC telles me that 6.1.3.8 is getting ready for release and contains "a Low RSSI threshold issue."

 

Looking forward to the fix.

Is it fully understood what the issue is? The structure of a warehouse by itself presents its own physical issues.

old code=good

new code=bad

 

with no other changes and 4 warehouses all experiencing the same effect -- gotta be code

 

With so many variables in so many locations when just touching one variable causes such widespread effects, it's gotta be the cause.

 

6.1.3.2 has over 500 bug fixes, so just going from 6.1.3.1 to 6.1.3.2 should be attempted first as an interim step.

 

In addition, since we see many more 802.11n access points than a/b/g access point issues, fewer people are likely to see much less report a problem that matches yours.

 

Lastly, since you have a production environment and cannot stay on 6.2 to have it troubleshot, it is less likely that we will ever get to the bottom of the problem.

 

 

 

 

We had a rocky start with TAC on this issue. I'm getting much better help now, but the delay cost us credibility wih the production users.

We're looking at settings changes to the clients worst affected to try to mitigat the effect if it comes back in the next upgrade attempt.

 

I'm pointing to this event internally as evidence to why we should be following incremental upgrades sooner - to keep the number of variables down.