AP370 6.5r8b refusing clients

  • 1
  • Question
  • Updated 5 months ago
Since the 6.5r8b release, apparently at random out AP370s stop accepting clients, the majority of which are Macbooks, but also iPhones and Android phones.
The 'fix' is to reboot the AP.
I haven't seen this happen to an AP230 yet. We have 6 x AP370s on this floor and I would say this happens at least once a week at the moment.

Sorry I can't give more clues, but as the AP370 is a different chipset (and has never been well supported to be honest) I'm assuming the KRACK fix has a problem on this model.

Anyone else seen this? Got an idea where the problem lies. I'm tempted to roll back but there are security implications.

Cheers, Kevin.
Photo of Kevin Gee

Kevin Gee

  • 54 Posts
  • 4 Reply Likes
  • Annoyed

Posted 5 months ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Kevin,

This sounds like the type of thing that should be progressed via a support case. Do you have one already?

Thanks,

Nick
Photo of Kevin Gee

Kevin Gee

  • 54 Posts
  • 4 Reply Likes
Hi Nick,
Thanks for the response, I don't think I can open a support case as I don't have a support contract!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Kevin,

A known issue that we are aware of pertains to unicast to multicast conversion in certain circumstances, which should be disabled on the AP370/AP390. Do you have this enabled?

I would check for the following in the config:

ssid <string> multicast conversion-to-unicast disable

Regards,

Nick
(Edited)
Photo of Kevin Gee

Kevin Gee

  • 54 Posts
  • 4 Reply Likes
Thanks Nick, I've checked and we do have it disabled.   Happy to hear any other ideas :)
Regards,
Kevin.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Kevin,

I think that the issue you are experiencing would need investigation with supporting data, initially techdata after the issue occurs then potentially further targeted debugging and tracing information from the various components in HiveOS, driver, forwarding engine, etc., to understand the cause in your environment. This community is not suited for handling this that which is why we would suggest a support case.

Thanks,

Nick
Photo of Kevin Gee

Kevin Gee

  • 54 Posts
  • 4 Reply Likes
Hi Nick,
Understood, but as I said I don't have the option to open a support case ;-)

One thing that has come up is that is looks like the two most problematic APs are Bonjour Designated Devices. This may not be relevant but we have also had problems accessing Airservers since the  6.5r8a/b updates so I am going to try changing the Bonjour Gateway configuration priorities to change the BDDs to AP230s instead of AP370s.  I am also going to try to filter some of the Bonjour services to reduce the load on the BDDs.
Will post here if it makes any difference.
(Edited)
Photo of Christos

Christos

  • 6 Posts
  • 1 Reply Like
We the same exact issue with AP370s, and Aerohive is slow to react, we already opened a case for two weeks now and they are still gathering data.
This is the second time that is happening with the release of a code that creates a big issue in performance and or total refusal of connecting for some clients randomly.
In another office we have AP330s, and the performance is pretty bad after the upgrade.
We do understand that all companies are forced to quickly respond to the vulnerabilities but they need to have a better testing lab rather than rely on the clients to test new releases.
Photo of Kevin Gee

Kevin Gee

  • 54 Posts
  • 4 Reply Likes
Thanks for the reply Christos, if you do get a fix I'd be very grateful if you would post it here. I'll do the same if I get any progress.

I'm still thinking of rolling back the update as the inconvenience to users probably outweighs the security risk, most of our clients have been updated now in any case.  Longer term we may end up replacing the AP370s :-(
Photo of Brian Powers

Brian Powers, Champ

  • 396 Posts
  • 92 Reply Likes
Kevin, we've experienced similar symptoms, but with different APs (Broadcom .11ac - AP130/230/1130) on the other "KRACK" HiveOS (8.1r2a). 

One of the T3 engineers has requested we try to do a "no qos enable" on an AP that seems to not be passing traffic to see if service restores.  I've yet to hear from another customer still running the 8.x code to attempt this, but it's worth a shot from your end possibly...

Haven't been a big fan of the "KRACK" vulnerability codes at all thus far.
Photo of Kevin Gee

Kevin Gee

  • 54 Posts
  • 4 Reply Likes
Thanks Brian,
In case it helps, we switched our AP230s from 8.1r2a to the 6.5 'golden' track and that did solve a lot of problems, our AP230s are behaving OK.

I may try the 'no qos enable' anyway, qos often seems to be the culprit.The AP370 that causes me the most trouble is one of our busiest, so it may be something to do with client hand-off, but this is a only vague hunch at the moment.
(Edited)
Photo of Brian Powers

Brian Powers, Champ

  • 396 Posts
  • 92 Reply Likes
Yes, the 8.1r2a code on AP230s has caused us much frustration as well.  To the point we've been reverting upwards of 5k APs back to anything but 8.x...

Be leery of the 6.5 code, mainly above 6.5r4 as if you set static power settings, the power settings seem to not take effect and they'll run at basically full power.
Photo of Joe Nesci

Joe Nesci

  • 1 Post
  • 0 Reply Likes
I am seeing the same problem with having to reboot the AP's.  370's are the big culprit but every once in a while I have to reboot a 230 too.  I am running on Prem HM 8.1r2 and Hive OS 6.5r8b.