6.1r3 slow performance

  • 5
  • Question
  • Updated 4 years ago
  • Answered
I wonder if anybody else ran into performance problems with 6.1r3? I have a small lab kit with 6 AP121's. As soon as I upgraded to 6.1r3 my performance dropped from roughly 130Mbps (single client) to around 24-25Mbps max throughput. Downgrading back to r2 got me my performance back. I have a case open for this with support and they've given me some steps to try, but those hasn't helped so far. I also disabled all the extra features and went down to as basic wifi setup as I could, but no help there.

I also got a tip from a fellow engineer, that currently the best working release for rock solid wifi (if you don't need the extras) is 5.1r5. I ended up downgrading there for now and now my single client speeds are actually up to 180+Mbps.

I guess series 6 still has some way to go..

//Juha
Photo of Juha Lindstrom

Juha Lindstrom

  • 13 Posts
  • 1 Reply Like

Posted 4 years ago

  • 5
Photo of Gary Smith

Gary Smith, Official Rep

  • 299 Posts
  • 61 Reply Likes
Hi Juha,

Could you share the AP config please?

Kind Regards,
Gary Smith
Photo of Juha Lindstrom

Juha Lindstrom

  • 13 Posts
  • 1 Reply Like
Here is the running config from one of the AP's. This is now with the 5.1r5 version, which is working brilliant. But if I upgrade it to 6.1r3 without any further change, it'll start to break down..

//Juha

Eteinen#show config running 

security mac-filter Aerohive default permit

security mac-filter AeroBug default permit

radio profile high-Capacity-24

radio profile high-Capacity-24 phymode 11ng

radio profile high-Capacity-24 acsp access channel-auto-select time-range 00:00 06:00 station 20

radio profile high-Capacity-24 acsp interference-switch enable

radio profile high-Capacity-24 interference-map enable

radio profile high-Capacity-24 deny-client 11b

radio profile high-Capacity-24 short-guard-interval

radio profile high-Capacity-24 benchmark phymode 11b rate 11 success 60 usage 50

radio profile high-Capacity-24 benchmark phymode 11b rate 5.5 success 70 usage 50

radio profile high-Capacity-24 benchmark phymode 11g rate 36 success 70 usage 50

radio profile high-Capacity-24 benchmark phymode 11g rate 24 success 80 usage 50

radio profile high-Capacity-24 benchmark phymode 11a rate 36 success 70 usage 50

radio profile high-Capacity-24 benchmark phymode 11a rate 24 success 80 usage 50

radio profile high-Capacity-24 benchmark phymode 11n rate mcs12 success 80 usage 50

radio profile high-Capacity-24 benchmark phymode 11n rate 54 success 70 usage 50

radio profile high-Capacity-24 band-steering enable

radio profile high-Capacity-24 weak-snr-suppress enable

no radio profile high-Capacity-24 safety-net enable

radio profile high-Capacity-24 band-steering balance-band threshold 90

radio profile high-Capacity-50

radio profile high-Capacity-50 phymode 11na

radio profile high-Capacity-50 channel-width 40-above

radio profile high-Capacity-50 acsp access channel-auto-select time-range 00:00 06:00 station 20

radio profile high-Capacity-50 acsp interference-switch enable

radio profile high-Capacity-50 interference-map enable

radio profile high-Capacity-50 deny-client 11b

radio profile high-Capacity-50 short-guard-interval

radio profile high-Capacity-50 dfs

radio profile high-Capacity-50 benchmark phymode 11b rate 11 success 60 usage 50

radio profile high-Capacity-50 benchmark phymode 11b rate 5.5 success 70 usage 50

radio profile high-Capacity-50 benchmark phymode 11g rate 36 success 70 usage 50

radio profile high-Capacity-50 benchmark phymode 11g rate 24 success 80 usage 50

radio profile high-Capacity-50 benchmark phymode 11a rate 36 success 70 usage 50

radio profile high-Capacity-50 benchmark phymode 11a rate 24 success 80 usage 50

radio profile high-Capacity-50 benchmark phymode 11n rate mcs12 success 80 usage 50

radio profile high-Capacity-50 benchmark phymode 11n rate 54 success 70 usage 50

radio profile high-Capacity-50 band-steering enable

radio profile high-Capacity-50 weak-snr-suppress enable

no radio profile high-Capacity-50 safety-net enable

radio profile high-Capacity-50 band-steering balance-band threshold 90

security-object AeroBug

security-object AeroBug security protocol-suite wpa2-aes-psk ascii-key *** 

security-object AeroBug security private-psk

security-object AeroBug security private-psk same-user-limit 5

security-object AeroBug security private-psk default-psk-disabled

security-object AeroBug default-user-profile-attr 1

ssid AeroBug

ssid AeroBug security-object AeroBug

ssid AeroBug security mac-filter AeroBug

ssid AeroBug 11g-rate-set 18-basic 24 36 48 54

ssid AeroBug 11a-rate-set 18-basic 24 36 48 54

hive Aerohive

hive Aerohive security mac-filter Aerohive

hive Aerohive wlan-idp mitigation-mode manual

hive Aerohive password ***

interface wifi0 radio profile high-Capacity-24

interface wifi1 mode access

interface wifi1 radio profile high-Capacity-50

interface mgt0 hive Aerohive

interface wifi0 ssid AeroBug

interface wifi1 ssid AeroBug

security wlan-idp profile kettis

security wlan-idp profile kettis ap-policy

security wlan-idp profile kettis ap-policy ap-oui

security wlan-idp profile kettis ap-policy ap-oui entry f0:9c:e9

security wlan-idp profile kettis ap-policy ap-oui entry 08:ea:44

security wlan-idp profile kettis ap-policy ap-oui entry 9c:5d:12

security wlan-idp profile kettis ap-policy ap-oui entry 00:19:77

security wlan-idp profile kettis ap-policy ap-oui entry e0:1c:41

security wlan-idp profile kettis ap-policy ap-oui entry 40:18:b1

security wlan-idp profile kettis ap-policy short-preamble

security wlan-idp profile kettis ap-policy short-beacon

security wlan-idp profile kettis ap-policy wmm

security wlan-idp profile kettis ap-detection connected

interface wifi0 wlan-idp profile kettis

interface wifi1 wlan-idp profile kettis

lldp 

access-console security protocol-suite wpa2-aes-psk ascii-key ***

hostname Eteinen

dns server-ip 62.241.198.245 

dns server-ip 62.241.198.246 second

ntp server time1.mikes.fi 

ntp server time2.mikes.fi second 

clock time-zone 2 

clock time-zone daylight-saving-time 03-30 02:59:59 10-26 03:59:59

config version 12 

config rollback enable

snmp location mylocation@alakerta

mobility-policy AeroTestPolicy dnxp nomadic-roaming

mobility-policy AeroTestPolicy dnxp unroam-threshold 1000 30

no bonjour-gateway enable

ssid AeroBug user-group mygroup96

no os-detection enable

capwap client server name 192.168.100.100 

capwap client dtls hm-defined-passphrase *** key-id 1

capwap client vhm-name home

no capwap client dtls negotiation enable

qos policy hima user-profile 2000000 100 user 2000000 

qos policy hima qos 0 wrr 2000000 10

qos policy hima qos 1 wrr 2000000 20

qos policy hima qos 2 wrr 2000000 30

qos policy hima qos 3 wrr 2000000 40

qos policy hima qos 4 wrr 2000000 50

qos policy hima qos 5 wrr 2000000 60

qos policy hima qos 6 strict 20000 0

qos policy hima qos 7 strict 20000 0

user-profile internal qos-policy hima vlan-id 1 attribute 1

user-profile access-vlan qos-policy def-user-qos vlan-id 2 mobility-policy AeroTestPolicy attribute 2

Eteinen#                        

Photo of Dwayne Hottinger

Dwayne Hottinger

  • 3 Posts
  • 0 Reply Likes
I updated a few ap's to 6.1r3 release.  I have a 10.8 imac lab that is mostly wireless.  I started getting complaints from the teacher (my canary) almost immediately.  They are getting server disconnect errors.  Im pushing out the 5.1r5 to those ap's to see if it solves the issue.  Tech Support hasnt provided much help.  Guess Ill never run the 6.x releases successfully.
Photo of Juha Lindstrom

Juha Lindstrom

  • 13 Posts
  • 1 Reply Like
Well, that might be a bit of a harsh statement. At least I'm not ready to go down that path just yet :-) Though it is worrying that it takes this many patch releases to get things stable. From software development point of view, what's needed is a release or two with nothing but bug fixes. No new features.. or split the software into two release trains: stable & early deployment.

Anyway, waiting with interest if this case gets solved with current software & settings or if it needs another patch release to get solved.

//Juha
Photo of Dwayne Hottinger

Dwayne Hottinger

  • 3 Posts
  • 0 Reply Likes
agreed.  didnt mean to sound harsh.  just frustrated.  in general our aerohive deployment has been very stable.  most of the issues i have had have been with various updates.  hence the reason I test on my canary lab,  the teacher there is very quick to chirp when something isnt right.
Photo of Gary Smith

Gary Smith, Official Rep

  • 299 Posts
  • 61 Reply Likes
Hi Juha,

Let's investigate this together via the open support ticket. We can report our findings on here once we know more as it will be useful for other customers.

Kind Regards,
Gary Smith
Photo of Juha Lindstrom

Juha Lindstrom

  • 13 Posts
  • 1 Reply Like
Hi Gary,

Excellent idea. I'm all for it. I replied to the ticket already, so let's continue there and I'm sure we'll find the prob. After all, it might still very well be my configs as my experience with wifi is still lacking compared to many others.. 
Photo of Bill Lohrer

Bill Lohrer

  • 1 Post
  • 0 Reply Likes
I had the same result... After upgrading to 6.1r3 all access points would allow a max of 20MB speed.   Downgrading the APs back to 6.1r2 brought our speeds back to where they should be.  
Photo of Angie Tellmann

Angie Tellmann

  • 17 Posts
  • 2 Reply Likes
Our company had something very similar to this when we upgraded to 6.1r2.  We have 1 location out of approximately 60 that DOES NOT LIKE the upgrade.   The performance is horrible if I upgrade their ap 340s to 6.1x.   They work on the 5.1r5.   Thank you for posting this.  I am anxious to see the outcome.  As info - their setup is basically the same as our other locations - same switches, same access points, same type of work, same type of building, same type of MPLS circuit.  We had the same problem a year ago with this location when trying to upgrade to 4.x.   We stayed at 3.x for the longest time until 6.1x came out and I thought I would give it a try.  
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Is there correlation around the client type, specifically client chipset and driver version? Or is it independent of that.
Photo of Angie Tellmann

Angie Tellmann

  • 17 Posts
  • 2 Reply Likes
All clients are using the same equipment - chipsets, driver versions, etc.   We did explore that possibility with an Aerohive engineer and the vendor for the units we use.   Nothing seemed to work.   An Aerohive associate from California even traveled to our location in TN to run some test, but could not find anything.   All of that was in 2012 and I thought the problem was fixed when we upgraded to 5.1r5, but the old problems returned when we did an upgrade to 6.1r2.
Photo of Juha Lindstrom

Juha Lindstrom

  • 13 Posts
  • 1 Reply Like
I son't think there is. I've tested it with various types and ages of macs from late 2008 macbook, late 2010 macbook, 2012 imac to late 2013 macbook pro with 892.11ac chipset and iphone 4, iphone 5 and ipad 3. All share the same performance. Common nominator between those all is Apple and "desktop" models have os x mavericks and mobile devices latest iOS.

All noticed big performance benefits right after downgrading software either back to 6.1r2 and even more so with 5.1r5.

But were set to do some testing with Gary and get back here when we have something nailed down.

So thumbs up and fingers crossed.

//Juha
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Folks,
If anyone else is experiencing this, and if you have any discretion in the matter, please do leave 6.1r3 on your Aerohive devices and open a ticket with our support organization. We are still trying to find the root cause(s) of these observed performance decreases, and more data points will help us find it sooner.
Photo of Angie Tellmann

Angie Tellmann

  • 17 Posts
  • 2 Reply Likes
Mike - there was extensive research done back in 2012 when I initially reported the similar problem.   David Dippon and Rusty Wyatt worked on it for us.   I think the ticket was 20418.   We stayed at the 3.5x until 6.1r2 came out.   We did the upgrade and the problem came back at this location.  Currently, they are running 5.1r5 and working great!   I did not report it because quite frankly we never really got a resolution back in 2012 after months and months of testing.  Check out the ticket and you will see how long we tested.
Photo of Gary Smith

Gary Smith, Official Rep

  • 299 Posts
  • 61 Reply Likes
Hi All,

Juha and I worked together this morning on the performance issue that he saw. We gathered all the appropriate information and will have the root cause investigated.

For your information, there is a workaround which we proved to be sufficient for the time being. This is to set the SSID data-rates to their defaults. In Juha's case;

no ssid AeroBug 11g-rate-set 
no ssid AeroBug 11a-rate-set 

I will update this thread on the findings but would like to remind everyone that performance can be affected by a number of variables, e.g. software, hardware, design, configuration, environment. From reading the comments on this thread, I do not think that everyone is seeing the same issue as Juha.

Kind Regards,
Gary Smith
Photo of Juha Lindstrom

Juha Lindstrom

  • 13 Posts
  • 1 Reply Like
Gary is spot on. We had a good debugging session and got some useful data out of it. Keeping that in mind, I'd suggest people having similar issues to also open a support ticket to provide even further data. Some helpful things could include sniffer traces with the beacon frames visible etc, as we had some troubles getting those from my lab due to Wireshark not supporting remote sniffer in their OS X implementation.

Also one thing to know about my setup is that I have a pretty clean RF environment at my home office, so it changes things compared to many office environments which can be horrible.. including our main office!

If you're in a noisy RF environment, I'd suggest doing some spectrum analysing & channel planning first..

Anyway, some food for thought in there. Hope everybody gets their issues sorted. And special thanks to Gary for taking the time.

//Juha
Photo of Marco Verleun

Marco Verleun

  • 6 Posts
  • 0 Reply Likes
I've done some testing as well with an AP-121.
With release 5.1r5 I've got the best performance: 9-12 MBs
Release 6.1r2 downloads at 9-12 MBs.
Release 6.1r3 is slow: 2-3 MBs. After the workaround command no ssid 11x-rate-set it went up to 6-10 MBs, but mostly around 6-7 MBs.

I can't create a support ticket as asked by Mike. If I try to I'll get redirected to the download area.

Please let me know how I can help. If not I'll downgrade until the issue is resolved. 
(Edited)
Photo of Gary Smith

Gary Smith, Official Rep

  • 299 Posts
  • 61 Reply Likes
Hi Guys,

the root cause is still being investigated but I would like to share another workaround that could be more suitable to your WLAN deployments.

We have found that if the lower data rates are disabled and MCS0 is also disabled, the performance is as expected - that is, the higher rates can be achieved.

In my test I disabled MCS 0 and 1 and tested on 2.4GHz.

Portal-463e00#show ssid Home_WiFi
Frag=fragment threshold; RTS=request to send;
DTIM=delivery traffic indication map; WMM=Wi-Fi Multimedia;
UAPSD=unscheduled automatic power save delivery;
IST=AP will permit traffic between stations connected to one or more of its access interfaces;
Strict=AP will disconnect all stations if SSID binding user profile table is changed;

SSID profile: Home_WiFi
Security Object: Home_WiFi
RTS threshold: 2346
Fragment threshold: 2346
Hide SSID: No
Ignore broadcast probe: No
DTIM period: 1
Max client number: 100
Client age out: 5 minutes
MAC filter: Home_WiFi
Access console: Disabled
WMM state: Enabled
UAPSD state: Enabled
IST state: Enabled
11g rate set: 12M(b) 18M 24M 36M 48M 54M
11a rate set: 6M(b) 9M 12M(b) 18M 24M(b) 36M 48M 54M
11n rate set: mcs2 mcs3 mcs4 mcs5 mcs6 mcs7 mcs8 mcs9 mcs10 mcs11 mcs12 mcs13 mcs14 mcs15 mcs16 mcs17 mcs18 mcs19 mcs20 mcs21 mcs22 mcs23
Mode legacy: Off
Mode compliance: On
Bind interfaces: Wifi0.3 Wifi1.4
Scheduler Entry(s): 0
RRM state: Enabled
WNM state: Enabled
WMM-AC state: BE(Disable) BK(Disable) VI(Disable) VO(Enable)

Portal-463e00#show station 10bf:48ea:bfa5 (Google Nexus)
Pow=Power in dBm; txrate=transmission rate;
txpkts=transmitted data packets; txbytes=transmitted data bytes;
rxrate=reception rate; rxpkts=received data packets; rxbytes=received data bytes;

 Pow txrate txpkts txbytes rxrate rxpkts rxbytes
 -42(50) 65M 208 100.79K 65M 870 83.82K
 -42(50) 65M 208 100.79K 65M 870 83.82K
 -42(50) 65M 208 100.79K 65M 870 83.82K
 -42(50) 65M 208 100.79K 65M 870 83.82K

This has been verified to work on an AP330, AP121 and a BR200 in my tests.

As a side note - we do not see this issue on any other HiveOS version and we have not seen the issue on an AP120.

I hope this helps.

Kind Regards,
Gary Smith




(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Do we know if Apple devices still powersave to MCS0 blindly without checking for the data rate being available, or was this fixed in their current software releases?

I remember it being just iOS devices, but the post below suggests otherwise:

https://www.mail-archive.com/wireless-lan@listserv.educause.edu/msg09190.html

(Edited)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
This is quite an interesting topic. I've read and re-read the 802.11n spec and must admit to being hopelessly confused.

It very clearly states that for an 802.11n AP, MCS 0-15 are *MANDATORY* and for an 802.11n STA, MCS 0-7 are *MANDATORY*:

HT PHY specification (20.3.5):

"MCS 0 through 15 are mandatory in 20 MHz with 800 ns GI at an AP. MCS 0 through 7 are mandatory in 20MHz with 800 ns GI at all STAs. All other MCSs and modes are optional, specifically including transmit and receive support of 400 ns GI, operation in 40 MHz, and support of MCSs with indices 16 through 76."

What does "mandatory" mean? I know what it says in MY dictionary, but this is the IEEE who seem to have their own special one.

While there are fields (BSSBasicMCSSet and Supported Rates Set) that appear to operate like the familiar "Supported Rates" element from 802.11g, i.e. defining the "basic" and "supported" MCCs, the standard implies that the BSSBasicMCSSet cannot exclude any of the "mandatory" MCSs.

It also states that for an HT transmission (i.e. where there are no non-HT stations present), packets which must be transmitted at a basic rate (e.g. broadcasts, management frames) should be transmitted using the lowest MCS index defined in the BSSBasicMCSSet or, if that is NULL, then the lowest mandatory MCS defined for the PHY (i.e. MCS0).

There are many more nuances documented in terms of rate selection, but the common ground seems to be that the BSSBasicMCSSet must be supported by all HT-capable (802.11n) STAs connecting to the BSS and that this set of rates must include at least the mandatory rates defined for the PHY (MCS0-7 / MCS0-15).

The way I read all this suggests that it actually should not be possible to "disable MCS0" at all.

Indeed, after experimenting with "disabling MCS0" (or indeed any other "mandatory" MCS) in the configuration, when I take a packet capture in the air, I always see MCS 0-15 advertised as supported. I can't find anywhere in any frame (association frames, beacons etc.) where the MCSs I have set to "not available" are marked as "disabled" or "not supported" in any way...

Indeed, I also see the BSSBasicMCSSet field is NULL in all HT Information elements in all frames from the AP, and that the Supported Rates Set is set to MCS0-15 (on an AP121) in all HT Capabilities elements in all frames. If "mandatory" really means "mandatory" then this would be in accordance with the standard.

I've also compared with frames from another vendor's AP and see the same thing.

If that's the case, then disabling MCS0 as suggested here should actually have no effect whatsoever on the network and ordinarily would have no effect whatsoever. However for some eason, it seems to work around whatever bug to do with Tx data rate selection is triggered in the HiveOS code (or more likely Atheros driver code, especially as the issue does not affect APs with a different chipset such as the AP120) when 802.11b/g rates are modified from the defaults.

By the way, this is one of the many reasons I find wireless networking, and 802.11n in particular, incredibly frustrating. Despite the rounds and rounds of drafting and endless arguing over wording, they still manage to end up with something that is unclear and open to interpretation. It's no wonder that writers of drivers trying to conform with the standard find it so difficult and there are so many driver "bugs" - I reckon half of them are the result of misinterpreting the intent of the wording or using an actual dictionary instead of whatever it is that the IEEE seem to use. Grrrrrrrr.

Maybe someone who worked on the standard could comment? ;)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
From some more reading, looks like some vendors don't allow MCS rates to be customised at all in the configuration, some only allow it to be done for an entire spatial stream range (e.g. 0-7 or 8-15) while others allow individual rates to be set/unset (Cisco for example, and also - on the surface at least - Aerohive).

However I still don't see any evidence in either 6.1r3 or 6.1r2 that disabling MCSs (ssid XXXX 11n-mcs-expand-rate-set) actually has any effect at all on the HT Capabilities or HT Information elements in the actual packets.

I've found a number of (non-Aerohive) forums debating whether disabling "low" MCS indices is a good idea and a fair few of them hit the same quandary over the meaning of "mandatory" in the standard and what the effect would be on clients of not advertising support for all the "mandatory" rates and indeed whether this is even possible.

Surely this should be easy, right? Ho hum.

Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I've also tested on an AP120 (which doesn't suffer from the bug being discussed in this thread) and the behaviour is the same.

From my testing, setting the supported MCS rates in Aerohive works like this:

1. It doesn't affect the supported rates which are advertised via the HT Information Element (this is always MCS 0-15, the mandatory rates defined in 802.11n)
2. It doesn't prevent reception of packets transmitted by stations at MCS rates not "enabled" in the AP configuration (so the Apple issue with MCS0 should not be a problem)
3. It DOES affect the actual rates selected by the AP when transmitting packets. I can see this both from a "show sta" command on the AP and from the remote sniffer capture. If enable only, for example, MCS 0 and leave all other MCSs disabled, I never see any transmissions from the AP at any of those other MCS rates however the client (which believes all rates are supported as that's what the HT Information states) happily transmits at these rates and the AP happily decodes and receives these frames.

This behaviour seems to be different to Cisco's behaviour, based on the many forum posts which say that disabling MCS0 in a Cisco infrastructure will cause problems for Apple devices (and possibly others). The inference is that disabling an MCS on Cisco actually causes the AP not to receive frames from stations transmitted at those rates. I suspect, but cannot confirm, that the reason it is stated that this is an Apple bug is because Cisco DO set the BSSBasicMCSSet and Supported Rate Sets in the HT Information and Capabilities elements, so the device should not use MCS0 for transmission in the first place.

That's what I reckon anyway. :)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Wow, thank you for researching and documenting that in such detail! :)

I agree that it's highly likely to be a driver bug, I wonder if a derivative of ath9k is being used or something else...
Photo of Juha Lindstrom

Juha Lindstrom

  • 13 Posts
  • 1 Reply Like
I've tried the MCS0 setting and it fixed the speeds when using custom data rates. With the new setting in place, I was seeing 115-117Mbps using iPerf.

No idea on the iOS powersave.

//Juha
Photo of sx

sx

  • 25 Posts
  • 2 Reply Likes
We upgraded to 6.1r2 in January, and 6.1r3 not long after it became available. I have not noticed any speed issues, but do have a few other issues that seem related to the new firmware & Hivemanger.

Firstly the Good.
- Love the reporting - and so do the management!
- Love the application level control!! Particularly the ability to block the likes of Bittorrent.

The Bad
1. Coverage & quality in 5GHZ. There are a number of sites that have reported coverage issues following the upgrade. This seemed to start in 6.1r2 for us, and was particularly noticeable with Ascom wi-fi phones, although other devices have experienced issues. In some areas where these phones had previously worked, they no longer have coverage.
There were also quality issues with handovers between AP's (also seen with laptops & iPads) that have improved by changing settings that were used in 5.1r5 - namely changing the SLA setting from High-density to Normal-density & turning DFS off.

We have also turned UAPSD (Power Save) off on the phones. (By default it is set to On on the phones, but is not enabled on the SSID.) Initial tests show improvements in quality, and based on comments above I am wondering if this setting on the SSID could impact other devices.

In the early stages of our testing we rolled the AP's back to the 5.1r5 firmware and the issues went away - so it seems that the new firmware behaves differently with the same configuration settings.

2. HTTPS stops in Hivemanager. This has happened twice now. Going to the HTTP page puts up the redirect page, but when you try to redirect or go to the HTTPS page manually the page time-outs. After a few hours it seems to fix itself.

3. Spectrum Analyser is broken. This is a known issue in 6.1r3 - just adding it for completeness. Big vote from me to bring it back.

4. 5GHZ channel availability. The AP's have access to channels 36 to 48, and 149 to 165. I'm trying to work out if should be able to access additional channels in New Zealand which would be useful in the density of our deployments.

Overall the upgrade is good for us due to the extra functionality it provides. The reduced coverage is a problem though, and not one that we were able to pick up in testing or the first batch of sites we upgraded.

Hope this helps someone.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
A significant change that was made in 6.1r2 was that the AP now uses a different mechanism to encourage load-balancing or band-steering than in previous releases. Priori to 6.1r2, the system would try to encourage clients to associate to a different radio or AP by IGNORING the association request; in 6.1r2 and later, it instead responds to the association request with a rejection (citing the "spoof" reason that the AP is fully loaded). Apparently this was done to improve the behaviour of some devices, but it seems this caused problems for other devices - at the end of the day, these functions are trying to get clients to do something without necessarily knowing how a specific client might behave (at the end of the day, the client chooses how it roams/associates).

In 6.1r3, it is now possible to specify a list of OUIs for which the band-steering/load-balancing will not apply (it is particularly bad for some Samsung android devices due to a bug in Samsung's wifi client - this is fixed in the latest releases).

In terms of Ascom handsets, I can say they do not respond well to:

1. High-density settings, especially the management frame data rate setting on "HIGH" and the selective probe response settings. Ascom phones use an aggressive polling mechanism to feed into their roaming algorithm and these settings will cause that to go haywire.
2. Load-balancing and band-steering being enabled.
3. Safety-net (preventing clients associating when SNR is low) - in some environments, this can trigger clients to get stuck when they try to associate at the edge of coverage and they can take a lot longer to associate even when in full coverage as a result.

In short, Ascom handsets (and some other devices) don't cope well with the AP trying to "be clever". There are similar problems with other vendors, but most vendors don't have the range of options we have available with Aerohive.

On the 5GHz radio, there is also a significant benefit in limiting the channels the handset scans. Avoid using a wide range of channels on 5GHz and limit the Ascom handsets channel set to just those in use. This significantly speeds up association times and can help with roaming in some circumstances.

UAPSD will improve battery life on the phones (and other mobile devices), but its use for VoWLAN phones especially is absolutely predicated on having a correct QoS configuration. Packets from the LAN to the handset MUST be classified into the correct CoS (i.e. the CoS the phone is expecting, as it will send UAPSD triggers to receive traffic it is expecting to be queuing in a particular WMM class - if those packets are in a different WMM class due to incorrect QoS configuration, you can end up with WMM buffers filling up and packets having to be dropped). Incorrect QoS configuration on the LAN and the Aerohive system can lead to connection issues, disconnects and call quality problems. Careful consideration needs to be made regarding signalling and media traffic, DSCP marking and QoS mapping in the Aerohive configuration.

I've not experienced any issues with HTTPS in HiveManager so far at any of my customers that have upgraded. If using a 32-bit HiveManager VM, did you follow all the release notes steps to reconfigure the VM and the HiveManager parameters? Due to the new features, especially L7 application awareness, I'd definitely recommend migrating to 64-bit HiveManager VM if you are still on 32-bit.
Photo of sx

sx

  • 25 Posts
  • 2 Reply Likes
Thanks Roberto – the information you provided was very helpful.

For anyone else using these phones there is also an Interoperability Report from Ascom on the settings to use for both Aerohive & the phones. (The one from January 2014 covers HiveOS 6.1r2 and the Ascom firmware 5.1.22.) The guide is comprehensive and very useful.

We have opened a TAC case for a problem with the 6.1r3 firmware and Ascom i62 handsets. There is a reproducible problem at multiple sites with poor voice quality in areas where the signal strength starts to drop. However the signal level in these areas should be a workable level.

When we revert the AP firmware back to 5.1r5 (with no other configuration changes) the problem disappears. To test at one site I rolled the AP forward again to 6.1r3, and the problem immediately reoccurred in the area. Rolled back a second time and the problem went away.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Official Response
Hooray! This issue has been resolved in HiveOS 6.1r3b:

"Disabling transmission at one or more of the default basic data rates caused Aerohive devices to switch from 802.11n to legacy mode, resulting in much slower throughput."

http://www.aerohive.com/330000/docs/help/english/documentation/Aerohive_ReleaseNotes_330104-03b.pdf

Photo of sx

sx

  • 25 Posts
  • 2 Reply Likes
That is good news Nick. 

If we disabled some of the lower data rates in the 2.4 band but not in the 5 band for a given SSID, would that cause the 5 band to  go to legacy mode?

Photo of Bradley Chambers

Bradley Chambers, Champ

  • 302 Posts
  • 53 Reply Likes
Bam! This totally fixed this for me. Tripled my speeds!