09-30-2019 11:03 AM
AP Configuration
Interface Radio Mode Radio Profile Admin State Channel Power (dBm)
2.4 GHz (wifi0) 802.11g/n radio_ng0_v2-TEST Up Auto Auto
5 GHZ GHz (wifi0) 802.11a/n radio_ng0_v2-TEST Up Auto Auto
AP's shows High retry rates.
10-10-2019 09:33 AM
Have sent this thank you.
10-09-2019 12:08 PM
Could you send me tech data from the site that is still having connection issues? If the clients can't connect at all, you'll want to enable auth debugs, replicate the issue, note the MAC address of the device you used to replicate the issue, pull tech data, and send that tech data and the MAC address of the test client to me so I can review and let you know what I find. This guide reviews how to set up auth debugs: https://thehivecommunity.aerohive.com/s/article/Authentication-Auth-Debugs
10-09-2019 10:57 AM
Hi Sam,
Thank you for the detailed information. The issue resolved after we made the changes you suggested, we also noticed an issue in both whereby the wireless access points were pointing at the wrong site, this was changed and clients could connect. The issue has come back and clients can't connect at one site.
Please, could you advise ?
Many Thanks,
Ziran
09-30-2019 02:32 PM
Thank you for that tech data. The first thing I checked was the output of "show acsp neighbor" to make sure we didn't have any overlapping signals. In this output you want to look for any RSSI values in the -50-0 range, which would indicate an overlapping signal. You had a couple loud neighbors on the 2.4GHz radio, but they weren't Aerohive devices so there isn't much we can do about those. Additionally, you're competing with 89 other signals in range of your Radio, which will lead to some interference by default, and most of it isn't Aerohive signal.
The next outputs I checked were "show int wifi0" and "show int wifi0 _count" which will show me the health of the 2.4GHz radio. Overall, I'm seeing some moderate interference readings here (~10-20% retry rates, ~20-30% CRC failure rates, ~15% unicast retry rates), but I'm not sure how current that data is as we're missing quite a few background scans. The AP need to get a background scan through to update the information I'm looking at, so this could be older data.
Next I checked "show int wifi1" and "show int wifi1 _count" to see the health of your 5GHz radio. Everything looks good on this radio, except we have a 49% CRC failure rate, which means 49% of the traffic received on this radio was too damaged to read and had to be resent at least once before the AP could move on to the next packets. Here again we are missing a lot of background scans though, so again I can't tell how recent this data is.
First off, I would recommend enabling background scans while you have clients connected in a power save state. You can adjust the background scan settings in the Radio Profile of the AP. That way we'll be able to get more up to date information from the APs.
I would also usually recommend enabling band steering to get your clients over to the 5GHz radio, since you only have 4 competing signals on that radio. However, the 49% CRC failure rate means this radio will still have significant interference. CRC failures are usually caused by environmental factors, such as metal, glass, or water. Could you email me a picture of a typically placed AP or APs at communityhelp@aerohive.com so I can help rule out environmental interference factors?
This guide reviews everything I looked at, what it may mean, and how to fix it, in case you want more details: https://thehivecommunity.aerohive.com/s/article/Radio-Frequency-Interference-Troubleshooting