Inventory SSID is WPA2-CCMP
Using smart-rf policay
Any idea on what to look at next?
1) What version of WiNG on the AP650's? versus, what version of WiNG on the 7522's?
2) Did you replicate the AP650 profile for the AP7522's?
3) Same SmartRF policy used for both 650's and 7522's?
4) Same WLAN Profile used for both the 650's and 7522's?
5) Are you 100% certain this problem only started once you began using the 7522's? Could it just be coincidental timing?
If you see a pattern here, we're looking for anything that is different except the AP hardware.
Once you can eliminate any possible configuration differences, then we can start investigating if there might be something at fault that is specific to the 7522, that did NOT exist on the 650.
For those users affected, *how often* does it happen?
Any idea if this client-side problem is affecting ALL users or just some subset?
Possible to take one of the affected units and upgrade its firmware (if there is an update) and then see if it continues to have an issue?
Current version is 188.8.131.52 on the 9610 and AP's. Users are using 9090's,92N's, and TC8000's.
We have tried updating some guns to latest version and fusion driver and it did not help.
Not entirely sure about the version on the 650's, but we believe it was 5.x.x
With the 650's, we did not use rf-policy.
The 650's had external drop down antennas. Our current 7522's have internal antennas.
WLAN profile is the same.
Co-worker stated that we rarely had issues when we had the 650's. Now we always have reports of issues with the rf guns dropping.
When you say that the 650's didn't use an rf-policy, what does that mean exactly?
What height are the 7522's mounted? (was it the same for the 650's)?
Seeing that you statically channel/power mapped the 650's, I'd really be interested in hearing how they were configured. Do those 650 'objects' still exist on the NX9610 or were they deleted?
Can you post your current SmartRF policy that is being used? Wondering if maybe the radio power on the 650's was set higher than what the SmartRF policy's max value allows for....
Here is some info:
wlan INVENTORY1 description Data Collection Device (HH) SSID
wpa-wpa2 psk 0 xxxxxxxxxxxxx
wpa-wpa2 handshake timeout 800
wpa-wpa2 handshake attempts 3
wpa-wpa2 handshake priority normal
use ip-access-list out BROADCAST-MULTICAST-CONTROL
use mac-access-list out PERMIT-ARP-AND-IPv4
assignable-power 5GHz min 14
assignable-power 2.4GHz max 20
assignable-power 2.4GHz min 11
channel-list 5GHz 36,40,44,48,149,153,157,161
The SmartRF policy looks pretty basic.
Do the affected devices use only 2.4GHz or only 5GHz or both?
As Robert asked, a SmartRF Report might be revealing.
Really wondering what power level the APs are being set at by SmartRF....
In this rf-domain, the handhelds have been changed to use only 5ghz. We do have 2.4 enabled on the radios just because there are some laptops out there that do not have 5ghz capabilities.
As far as the tunneling, not really sure. I think it has to do with how our network is separated. Again, before my time here.
(Also seeing this type of activity on the 2.4GHz radios as well, but it doesn't appear to be nearly as frequent)
Question: When the 650's were being used, were the handhelds typically using the 2.4GHz radios?
If a survey was done for the deployment of the 650's, was the survey performed based on 2.4GHz coverage requirements? (not for 5GHz coverage)
What I'm getting at here is that the AP placements may have been surveyed based on 2.4GHz coverage...and then you've moved most of your clients over to 5GHz (all of your handhelds). Based on the SmartRF report and all the power recovery activity, I'm thinking that maybe the coverage doesn't look too good using 5GHz.
You could test this by taking 1 or 2 handhelds and re-configuring them to only use 2.4GHz ONLY and then put them into production for a day or two...or however long would prove if the change made a difference. If you see that the connection issues go away on those devices, then I would conclude that you're dealing with a 5GHz coverage problem.
Can I recommend that you contact GTAC
We have a very good wing team that will be able to assist in this matter.
I can see some changes in your WLAN setting that you have configured that could cause problems in old windows mobile devices roaming.
You have enabled 802.11r for example that is not support on windows mobile so will not help.
Can you also attached a copy of the tech support file
Neighbor Recovery is used to automatically expand one or more AP's coverage area by increasing an AP's power when a WiNG neighbor AP’s signal has deteriorated/degraded. This is essentially a recovery mode whereby the APs are detecting that another WiNG AP is basically 'down' or somehow seriously affected. Either failed, antennas broken off, or some large RF obstacle has moved in the way of the AP such that it appears that it's down. The default settings in the SmartRF policy is -70dBm. This value is adjustable...so if your environment is such that you would expect for periodic large blockages of APs to occur...such that the Neighbor recovery mechanism would kick in, you should probably alter that value or just disable the Neighbor Recovery option altogether. There are different ways of dealing with this.
Coverage Hole Recovery:
This is a recovery method that allows for neighboring APs to increase their radio transmit power to compensate for what is seen as a coverage hole. It's possible that whatever is causing the frequent Neighbor Recovery instances is also responsible for causing the coverage hole recoveries.