AP 630s that are dropping clients very frequently

We have new Aerohive 630s.  We are struggling with keeping clients connected.  I use a scanner and see the radios dropping out from time to time (not regular that I can tell) and then they come back. I also see that clients are connecting to APs in other room with much weaker signal that the APs close to them.  Any help

30 replies

Are the APs disconnecting from the HiveManager at all? For the issue of clients connecting to APs with weaker signals, I'd recommend disabling lower data rates. That will require a stronger signal between the AP and the client device, so clients should stay with APs closest to them.


To disable the lower data rates we need to go to Configure> Select the network policy> Open the SSID> Expand Additional Settings> Customize Optional Settings (at the end of the page)>In the 2.4 GHz 11/bg Rate Setting section, we want to turn 1Mbps-9Mbps to N/A. In the 5.0 GHz 11a Rate Setting section we want to turn 6 Mbps and 9 Mbps to N/A.

The APs are NOT disconnecting from the Hive. Thanks for the suggestions on the data rates. I'll give those a try.

Since the APs are not disconnecting, you might be seeing those interruptions when a background scan gets through. The APs use these background scans to update data in the tech log and to make auto channel or power adjustments. These happen by default every 10 minutes, and most client devices aren't affected by the scans at all.

That seems to have made the problem worse.


Could you send tech data from an AP having this issue to

That's a huge volume of text. Is there some way of cutting that down some?


I was able to get a different AP that had less content, but still the same symptoms. Data sent.


Thank you for that tech data. I see most of the stations connected to this AP (CLI command "show station" if you're curious) with a Good connection state. A couple have a connect state of High Retires so I took a look at your interference levels.


Looking at the output for "show acsp neighbor", we want to look at the RSSI column. These values depict how loud the neighboring APs are, or in other words how much air space they are taking up. For these values we want to see -75 or lower. The closer to 0 this value is, the louder that AP is, and the more interference you will be experiencing. In your case you have one loud 2.4GHz neighbor, but several loud 5GHz neighbors. I'd recommend lowering the 5GHz power on neighboring APs to reduce signal overlap.


I checked the health of your 2.4GHz radio and found a 66% CRC failure rate, which means 66% of the traffic on your 2.4GHz radio has to be resent at least once (likely more than once) before the receiving radio is able to read it. This will cause slower wifi speeds as the APs have to keep repeating the same packets until they are readable, and can cause frequent disconnections as well.


CRC errors are usually related to environmental interference factors. These factors include mainly metal, glass, water, or large amounts of people. All of these factors tend to reflect, refract, or generally damage your signal, leading to more retries, which leads to slower WiFi speeds. To help with CRC errors  if you could send pictures of a few problem APs with as much of the environment showing around the AP as possible, I can help you rule out any environmental factors that could be damaging your wireless signal.   


The 5GHz radio looks good, no significant interference there. Are we using band steering by chance? You can find this in your Radio Profile if you're not sure. If we aren't using it already, I would suggest turning it on so we can get most of your clients away from the 2.4GHz radio.

The rooms are typical classrooms, block walls and one wall mostly block with glass (regular, not Low-E, maybe not even tempered) about half way up the wall. The only unique thing in the classrooms is a heatpump in the middle of the room that is physically 12" higher than the AP, and horizontally 6' or more away. Classrooms are 30' x 35'. They typically hold 24 kids. One 75" TV on a wall, opposite the AP and opposite the glass.


I am familiar with band steering.


We have Connect, so I think that Band steering is not available. Is that correct?


That is correct, it's not available in Connect.

So my solution for those in question was to just turn off the 2.4 radio in that classroom, as I know the devices have a 5GHz radio.


Anecdotally, what I have right now is large batches of Lenovo N42s that do not seem to have trouble. large batches of ASUS C300s that seem to be fine.


BUT I have 250 or so HP 11 G7 chromebooks that are a pain and get kicked off regularly. From HP I see they have the following NIC...


Intel®️ Dual Band Wireless-AC 9560 802.11a/b/g/n/ac (2x2) Wi-Fi®️ and Bluetooth®️ 5 Combo, non-vPro™️ Compatible with Miracast-certified devices.


I remember reading about an Intel issue. Is there a fix for that on the aerohive end?



BTW -- when we had a pre-sales meeting, the engineer we met with then told us it was best to NOT employ band steering.

We don't have a particular work around for an Intel issue, but we do have this guide for recommended settings when using a lot of chromebooks:


If you could tell me why the engineer recommended not enabling band steering at the time, I can try to explain the differing advice. In general, I don't recommend it either unless the 2.4GHz radio is having significant interference issues. Your solution of disabling the 2.4GHz radio works just as well, so long as you don't have any legacy clients that can't use 5GHz.

I think maybe that was the wrong link

I did post the wrong link originally but that should have been updated, this is the guide I'm referring to for Chromebooks:

Thanks for all your help. I still don't have the issue resolved yet, but maybe I am getting closer to a diagnosis.


I have spent quite a lot of time with HP trying to verify it is or is not a wifi card issue.

So when I take the Aerohive APs down and put up an HP AP, with an identical configuration (power, channel and as many setting as are comparable which is admittedly very few) then the clients seem to stay connected.


When you say "Lower than -75", you mean like -90 or so, not -30. We are talking numerically, not in terms of magnitude, yeah?



Correct, -75 to -100 is the ideal range for that RSSI reading on the APs neighbor list. The -60's are considered not the best but not really a problem, but once we start seeing values in the -50's on up to 0, that indicates a neighboring device that is broadcasting too loudly near by.

Great! I hope to have a positive outcome!

At this point, I have the power on the 5GHz radios to between 9 and 13 db and the power on the 2.4GHz radios at about 4-9 db. I have been very diligent to make sure there is no channel overlap. I have checked the RSSI numbers and some are as high as -55, but those are the APs with the power at 9 and 4, respectively. I don't know if I can get them lower. I tried turning them off completely, but had mixed luck with that. I can turn up the other radios and cover the area, but that seemed to cause as many problems as it solved. All channels are at 20 Mhz bandwidths. I have also turned off the slower data rates in the 2.4 GHz 11/bg Rate Setting section, 1Mbps-9Mbps, to N/A;in the 5.0 GHz 11a Rate Setting section, 6 Mbps and 9 Mbps to N/A and the 12 Mbps to Basic from Optional.


We seem to be doing much better now.

Not sure if this will help but it's worth a shot. Have you tried disabling tx beamforming on the 5Ghz radio? I was having a similar issue with AP550's and it resolved my problem. I'm supprised there isn't a big forum sticky post regarding this.


Here is a comment from another thread -


Aaron Krohnberg (Customer)

a month ago

I've been up against this issue as well. I ended up upgrading an AP230 to version 8.2r6 and then we turned on verbose debug via the CLI. Below is what the technician found.


Thank you for the attached tech data. While reviewing the 8.2r6 tech data I found the following error repeated:

2019-08-07 10:10:12 info kernel: [wifi]: wl1: fatal error, reinitializing

2019-08-07 10:10:12 info kernel: [wifi]: wl1: phyerr thresh exceeded HAMMERING!

This behavior is a known issue when transmit beamforming is enabled in the 5 GHz radio profile on APs running 8.2rX and 10.0rX HiveOS version. This issue is currently being addressed by our development team as part of CFD-3835.

Unfortunately there is not an ETA for the resolution yet. I would recommend either disabling TX beam forming or using non 8.2rX/10.0rX firmware for the time being.

In addition to John's good suggestion, I wouldn't worry about continuing to lower the power on the APs that are still very loud. They are still operating as expected when using a power level of 1 or 2dBm, and it's not unheard of to see that in a live deployment when you have APs that are close to each other.

I am very ready to try that, even though we're pretty good (still room for improvement, though). I can't find anywhere to turn off beamforming. Can you tell me where that is?


I guess I should have mentioned we have connect, not select.