WiFi 6E channels now permitted in New Zealand (August 2022)

WiFi in NZ finally got the major boost that we've been waiting for!

More channels equals less interference and less contention.

RSM (part of MBIE) is the NZ government body responsible for Radio Spectrum Management in New Zealand. In their August 2022 Business Update, RSM has finally announced the news that everyone in the WiFi industry has been waiting for: WLANs in New Zealand can begin to make use of more RF spectrum i.e. one of the key features of the WiFi 6 standard. Specifically, the WiFi 6E amendment. 

Why do we need more RF spectrum? 

 When you run a large number of WiFi access points (APs), you quickly run into 2 problems.

1. Not enough channels for all your AP radios without re-using them several times (not to mention your neighbours' AP radios), so your system suffers from co-channel and adjacent-channel interference. This impacts overall performance of the network.
   
2. To try and solve #1, you use the narrowest possible channels (20MHz), to squeeze out as many non-overlapping channels as possible. However by doing so you've now reduced the throughput capacity of each radio, and your entire network isn't as fast as it could be if you had wider channels.
   

With the WiFi 6E standard, there are (theoretically):

59 x new 20MHz channels = 29 x 40MHz channels = 14 x 80MHz channels = 7 x 160MHz channels.

So now we can have networks that are both more resistant to interference and we can get maximum performance from our network!

[Watch out for WiFi standard IEEE 802.11be (WiFi 7) which will enable a whopping 320MHz channel width]

What changes for New Zealand now?

With the changes announced by RSM, we unfortunately don't get all 59 new 20MHz channels. We only get 500MHz of the technically supported 1200 MHz.

We only get permission to use the so-called UNII-5 band. Sometimes this is referred to by the frequency range covered of 5925-6425 (MHz).

That is only a fraction of the total RF band covered in the WiFi 6E standard, but it still gives us 24 x new 20MHz channels or 6 x new 80MHz channels which will be very welcome.

How do we enable the new channels?

Do you have compatible hardware?

Firstly, we need to be running hardware which is capable of operating in this radio band. This needs to be supported on both the APs and the WiFi client devices. Look for the WiFi Alliance "WiFi 6E" badge.

I have compatible hardware!

Generally speaking, each manufacturer of WiFi equipment codes the permitted frequencies, channels, and maximum EIRP into their firmware.

They code this to adhere to the spectrum management laws in each country, that is why you always need to select a country code when configuring a new WiFi network.

So we'll need to wait for this news to filter through to the manufacturers who will make the appropriate updates to their code. Then, we need to update our device firmware manually (or this can happen automatically for some devices) before the new channels will be available for use.

When will New Zealand get the rest of the new channels?

There a are a few issues that need to be resolved before RSM can approve use of more channels on the 6GHz band for NZ.

The main issue is that this piece of RF spectrum is already allocated to private, licensed users in New Zealand, and they pay a hefty fee for RSM to enforce that nobody else is on their channels.

What are the limitations on the new channels?

RSM has approved use of the UNII-5 band provided it is only used indoors and at very low power (relatively speaking).

For higher power applications, such as long distance wireless point-to-point links, the WiFi standard does have a more complicated workaround for this: the mandatory use of an Automated Frequency Coordination (AFC) service. This exists in theory but not yet in practice in NZ.

An AFC service would require all APs to know their GPS location and also to be able to reach out to this theoretical server that would then coordinate all the channels in the country to avoid massive interference issues.

As you can imagine, this would require our WiFi systems to behave quite differently than they do today, so AFC is still on the horizon. 

Where can I read more?

You can read the official RSM announcement at the RSM website

You can find a nice graphic of the 6GHz channels in this article on Juniper's website

 

 

 

 

Wi-Fi 6E (new unlicensed RF spectrum) won't be available any time soon in New Zealand

Wi-Fi just got a major enhancement that will be a game-changer...but not in New Zealand.

Background

The basic limitation with Wi-Fi in our workplaces, schools & universities, public spaces, stadiums, airports and shopping centres is that there is a limited amount of unlicensed RF spectrum available, and everyone needs to share it.

Most parts of the RF spectrum can only be used under government-issued license (think cellular towers, RADAR, public safety radio, etc.) but a couple of little slivers were carved out early on in the 2.4GHz and 5GHz ranges for unlicensed use and for Industrial, Scientific and Medical use.

This then became the backbone of Wi-Fi: the fact that any device we buy off the shelf can talk to practically any Wi-Fi access point in the world is what allowed Wi-Fi to become so ubiquitous and indispensable.

The Problem

As time went by and the number of connected devices skyrocketed, the contention for that available unlicensed spectrum became worse and worse, to the point where today's Wi-Fi designers prefer to pretend that the 2.4GHz spectrum doesn't exist because it is so crowded and unreliable.

The holy grail of "better Wi-Fi" is to have access to a channel, a slice of the RF spectrum, that nobody else around you is using. This is getting harder and harder to find. Even in the 5GHz range where there are more channels, we desire to bond them together to increase total bandwidth, effectively reducing the number of available channels and getting back into the same problematic situation as before.

The News from USA

In early 2020, USA's FCC announced that they would be making another significant chunk of RF spectrum available for unlicensed use (actually they have been working on this for years). This will be in the 6GHz range, so it will have similar characteristics to today's 5GHz Wi-Fi.


Although we refer to it as the 6GHz band, the band actually runs from 5.925–7.125GHz, a significant range resulting in over twice as much available RF space than we've ever had in Wi-Fi before.

This means that we can bond channels together for that delicious bandwidth, and still have plenty to go around uncontested in our local area - a real game-changer!

The Wi-Fi Alliance has also been busy, and they are ready to start certifying devices in 2021, with Broadcom already announcing a chip in February 2020.

The new spectrum will be known as Wi-Fi 6E (building on the Wi-Fi 6 new naming scheme from 2019).

What about all those organisations who already paid for licenses in the 6GHz spectrum?

Avoiding interference for existing license holders (mainly being telcos and broadcasting companies who use it for long distance point-to-point links) will be mitigated in multiple ways.

Firstly, the FCC has determined that the way those licensees use this spectrum is different to the way a business uses Wi-Fi. They don't think that there will be much opportunity for interference to occur to any level that would impact those license holders.

Secondly, even though the new spectrum can be used license-free, usage of channels in this space must still be registered against a central database and coordinated to avoid interference. How this will play out is not clear, but presumably Wi-Fi systems will call in to a regional database and use that to safely and automatically coordinate their available channel-set to avoid licensees' spectrum.

Read all about it

The entire FCC document can be found at https://docs.fcc.gov/public/attachments/DOC-363490A1.pdf

Broadcom has produced a graphic showing how much more RF spectrum is made available by this new notice.

New Zealand's Government Has No Immediate Plans To Follow Suit

In New Zealand the airwaves are regulated by Radio Spectrum Management (RSM), a department of the Ministry of Business, Innovation and Employment (MBIE).

In response to an Official Information Act request from April 2020 asking whether RSM will follow the FCC's lead regarding making the 6GHz spectrum available for unlicensed use, an MBIE representative has made the following statement: 

We have no immediate plans around WiFi 6e  (i.e. WiFi @ 6GHz). Spectrum

above 5925 MHz is currently allocated for bidirectional fixed link use in

NZ. We also have C-band satellite uplink licensed across different parts

of the 6 GHz band.  Fixed and satellite services must coordinate on a

first-come-first-serve basis.

 

At this stage we don’t have a clear sense of whether the technical

mitigations proposed to allow 6e (low power indoor use and automated

frequency coordination (AFC)) will be sufficient to manage the

interference concerns of the incumbents.  In particular AFC is still

unproven technology in this scenario.  We are watching closely to see

whether a significant device eco-system is evolving and when the large

consumer nations (USA, China, Europe) move.  Once it becomes clear that 6e

is really going to happen elsewhere then we will likely run a domestic

consultation before making a decision.

 

Kind regards

Ministry of Business, Innovation and Employment

This means that MBIE will be taking a wait and see approach, and in the best case scenario it will be years before we can benefit from Wi-Fi 6E in New Zealand, if at all.

Finally, a real collaboration between industrial IoT and enterprise Wi-Fi

"HPE announces the integration of ABB Ability™ Smart Sensor technology with Aruba access points from end of 2019."

Included in HPE's news release on Tuesday, June 18 2019 was an announcement of a new Intelligent Edge partnership with ABB: the 130-year old Swiss industrial equipment manufacturer.

Motor Sensor. Photo from ABB catalogue

Integrations like this, in addition to the recently released SES-Imagotag Electronic Shelf Labels integration, are helping to differentiate Aruba products as IoT-friendly in a competitive market.

SES-imagotag electronic shelf label. Image from SES-imagtotag.com

The ABB integration is part of a suite of so-called "turnkey edge-to-cloud" solutions for Industy 4.0, which also includes cool toys like an IP55-rated enclosure announced in 2018 called the "Secure Edge Data Center", that can be installed nearer to the factory floor for handling all those time-sensitive operational workloads.

Back to the sensors: ABB has an existing sensor platform called ABB Ability Smart Sensors.
(The sensor capabilities are detailed at the end of this post.)


In the ABB Ability platform without Aruba APs, the sensors communicate over Bluetooth either to a phone within 1-10 meters, or to a ABB-supplied Bluetooth gateway within 50 meters (best case). From there, the information is sent to a cloud service which plots historical data onto graphs, shows lovely red icons when a sensor is alerting, etc.

While the details of the Aruba integration have not yet been announced, it is fair to assume that the BLE radios that have been included in the 300-series and 500-series Aruba APs will be put to use to replace the "gateway every 50 meters" functionality.

If it works anything like the aforementioned SES-Imagotag ESL integration, we can expect to be able to deploy it with a few simple lines of configuration that will allow the AP to bridge the BLE sensors to ABB's cloud servers.
While SES-Imagotag requires a USB dongle, I am hopeful that the ABB solution will be native, as it uses standard BLE.

European organisations can purchase directly from ABB online and the store page reveals subscription pricing of €99.00/device/year with their native gateways. There probably won't be any cost from the Aruba side though.

Bearing Sensor. Photo from ABB catalogue

The sensor portfolio includes:

Condition monitoring for pumps to get readings for:

• Health parameters
• Overall condition
• Overall vibration (velocity rms)
• Bearing condition
• Misalignment
• Unbalance
• Looseness
• Blade problems
• Cavitation (under development)
• Flow turbulence (under development)
• Skin temperature (degrees)
• Operating parameters
• Radial vibration (velocity rms)
• Tangential vibration (velocity rms)
• Axial vibration (velocity rms)
• Speed (rpm)
• Operating hours
• Number of starts

Mounted bearing sensors to get readings for:

• Temperature
• Vibration
• with a traffic-light health dashboard visible in smartphone app

Low voltage motor sensors to get readings for

• Health parameters
• Overall condition
• Overall vibration (velocity rms)
• Bearing condition
• Misalignment
• Skin temperature (degrees)
• Operating parameters
• Radial vibration (velocity rms)
• Tangential vibration (velocity rms)
• Axial vibration (velocity rms)
• Speed (rpm)
• Operating hours
• Number of starts
• Supply frequency (Hz)
• Output power (hp/kW)
• Regreasing count-down

Guide to 5GHz Wi-Fi Channels in New Zealand (NZ)

Disclaimer: I am not a registered RF Engineer, and this is just my interpretation of the information. You are responsible for ensuring your own compliance with Radio Spectrum Management

Most web searches for information about 5GHz Wi-Fi channels result in America-centric or Euro-centric results, so I've compiled this post for New Zealand specific information.

This information was sourced from rsm.govt.nz and from the NZ Government Gazette Radiocommunications Regulations (General User Radio Licence for Short Range Devices) Notice 2019 of April 2019. The regulations therefore may have changed since the 2017 version that is referenced on Wikipedia's list of WLAN channels

You should be aware that ground weather radar, covering channels 114, 118, 120, 122, 124, 126 and 128, operates at nine locations across New Zealand. These being Kaeo, Tamahunga, Mamaku, New Plymouth airport, Mahia, Outlook Hill (Wellington), Rakaia Trig, Blue Spur Range (Hokitika) and Invercargill Airport. If 5GHz Wi-Fi equipment is to be deployed in the vicinity of these 9 locations, it is highly recommended that these channels be avoided, as the weather radar is licenced for protection from interference. If your equipment causes any problems to these licenced services, compliance action may be taken against you. ---RSM.govt.nz

Ch36 to Ch48 (Ch50/)

5150MHz to 5250MHz

Max EIRP -7.0dBW

Use is limited to wireless LAN indoor systems only.

In the band 5150 – 5250 MHz, the maximum power is −7 dBW (200 mW) e.i.r.p. and the maximum permitted power spectral density is −20 dBW/MHz (10 mW/MHz) e.i.r.p. or equivalently −36 dBW/25 kHz (0.25 mW/25 kHz) e.i.r.p.

Ch52 to Ch64 (/Ch50)

5250MHz to 5350MHz

MAx EIRP -7dBW or 0dBW (depending on Indoor or Outdoor usage)

Use is limited to wireless LAN.

Indoor-Only Systems: In the band 5250 – 5350 MHz, the maximum power is −7 dBW (200 mW) e.i.r.p. and the maximum permitted power spectral density is −20 dBW/MHz (10 mW/MHz) e.i.r.p., provided Dynamic Frequency Selection and Transmitter Power Control are implemented. If Transmitter Power Control is not used, then the maximum power (e.i.r.p.) value must be reduced by 3 dB;
Indoor and Outdoor Systems: In the band 5250 – 5350 MHz, the maximum power is 0 dBW (1 W) e.i.r.p. and the maximum permitted power spectral density is −13 dBW/MHz (50 mW/MHz) e.i.r.p., provided Dynamic Frequency Selection and Transmitter Power Control are implemented in conjunction with the following vertical radiation angle mask where θ is the angle above the local horizontal plane (of the Earth):


Maximum permitted mean power density

Elevation angle above horizontal

−13 dB(W/MHz)

for 0° ≤θ <8°


−13 - 0.716(θ - 8) dB(W/MHz)

for 8° ≤θ <40°


−35.9 - 1.22(θ - 40) dB(W/MHz)

for 40° ≤θ ≤45°


−42 dB(W/MHz)

for 45° <θ;

Ch96 (actually Ch100) to Ch144

We must not implement Ch96, typically we begin at Ch100 for Wi-Fi, but the document does specify that this piece of spectrum begins at 5470MHz which is Ch96.

5470MHz to 5725MHz
Max EIRP 0dBW
Use is limited to wireless LAN
In the band 5470 – 5725 MHz, the transmitter peak power must not exceed −6 dBW (250 mW). The maximum power is 0 dBW (1 W) e.i.r.p. and the maximum permitted power spectral density is −13 dBW/MHz (50 mW/MHz) e.i.r.p., provided Dynamic Frequency Selection and Transmitter Power Control are implemented. If Transmitter Power Control is not used, then the maximum power (e.i.r.p.) value must be reduced by 3 dB.

Ch149 to Ch169 (actually Ch168)

The published frequency range includes Ch169, but we must not use Ch169 in New Zealand.

5725MHz to 5850MHz
Max EIRP 23 dBW
In the band 5725 – 5850 MHz, the transmitter peak power must not exceed 0 dBW (1 W) and the power spectral density must not exceed 17 dBm/MHz. The maximum power of any emission must not exceed 23 dBW (e.i.r.p.). Transmission is permitted from customer premise equipment with integrated antenna that is part of a point-to-multipoint system receiving from and transmitting to a central access point.


It is interesting to note that the RSM boundaries fall on the centre frequencies of wide Wi-Fi channels, meaning that the upper and lower halves of the channel may have different regulations. I invite any commenters to clarify this.

This diagram sets out the Wi-Fi channels that you can and can’t use in New Zealand.
and here is a static image in case that link becomes unavailable:

Aruba Outdoor AP Mounting Bracket Photos

These are the 4 outdoor AP mounting brackets for Aruba AP 270 series, 360 series, 370 series 275, 365, 367, 374, 377, 374, 380

MNT-H1 - JW054A - Hanging install (can tilt)
MNT- H2 - JW055A - Hanging install (flush, cannot tilt)
MNT-V1 - JW052A - Long arm pole/wall mount (300mm from wall)
MNT-V2 - JW053A - Short arm pole/wall mount (75mm from wall)

Important: If using AP377 or AP387 or other directional AP, don't use the wall mount or you'll end up aiming the antennas at the floor! Rather use the MNT-H1 mount on a wall or pole.


All will become clear when you see the photos:

Dragonblood: Should you worry? (Wi-Fi WPA3 security vulnerabilities explained for the not-so-techie)

On 10 April 2019 I noticed a flurry of panicky news stories and posts around LinkedIn and Twitter. The Wi-Fi Alliance published a security update regarding security vulnerabilities in the new WPA3 Wi-Fi standards which WLAN vendors are expected to start rolling out en masse in 2019.

The WPA3 standards promised a far more secure environment than the aging WPA2 standards currently in use just about everywhere today. The vulnerabilities (named Dragonblood) already have their own webpage, logo, theme song, etc. so we know that non-technical company execs will be seeing this across their feeds and demanding information about the security of the million-dollar Wi-Fi refresh they've just paid for, by the end of the week.

Before we engage in mass hysteria, let's examine the vulnerabilities a little further and see if there is truly anything to worry about.

Is this report from a reputable source?
Yes! The analysis and POC code were written by Mathy Vanhoef (NYUAD) and Eyal Ronen (Tel Aviv University & KU Leuven). Vanhoef had also discovered the Krack attack vulnerabilites that got everyone worried in 2017.

Why "Dragonblood"?
It is trendy for vulnerabilities to be given catchy names as this makes it easier for them to be written about in the media and go viral. These vulnerabilities are mainly around the handshake key exchange mechanism used in WPA3 which is called Dragonfly, hence the analysis paper was titled Dragonblood. The researchers released 4 tools to demonstrate the specific attacks and named them Dragonslayer, Dragondrain, Dragontime, and Dragonforce.
Note that the Dragonfly family of handshakes is not only used in Wi-Fi. Other encryption-based systems could also be vulnerable.

Can the Dragonblood vulnerabilities be fixed?
Yes, mostly.
Thanks to the researchers' responsible disclosure of the vulnerabilities, major vendors already had patches in place or in the works before the public announcement was made. simply ensuring that the firmware on your network equipment is kept up to date is sufficient to mitigate or remediate against most of these vulnerabilities. (this is why it is important to use trusted brands and keep those support contracts up to date folks).
In at least one of the downgrade attack scenarios (explained in more detail later on), a device is tricked into connecting to a WPA2 network and then a WPA2 exploit is used. This can't be easily fixed but it isn't strictly a WPA3 exploit either.
Unless you're 100% in control of every device connecting to your network (and who is?), you can't update the client side devices. The good news here is that hardly any WPA3 client devices are released yet, so hopefully most will be fixed before anyone even buys them.

Cisco has already released a statement by the reputable Jerome Henry, saying "Cisco Access points are not affected by any of the vulnerabilities described. The Cisco AireOS and IOS-XE releases that support SAE for WPA3-Personal will also include protection mechanisms against these vulnerabilities. WPA3 clients may need to be updated and Cisco recommends finding the latest information from vendors’ websites."

I will update this page with statements from other vendors as they become available. Personally I'm looking forward seeing a comment from Dan Harkins, the computer scientist who wrote Dragonfly and EAP-pwd, and currently happens to be employed by Aruba Networks.

In summary: The sky isn't falling, keep your network devices up to date, keep your client devices up to date.

You can find more detail about the individual tools below.

Dragonslayer
From the readme: This is an experimental tool to test EAP-pwd implementations for vulnerabilities. We also strongly recommend to perform code inspections to assure all vulnerabilities have been properly addressed.

Should you worry?
No.
Virtually nobody is using EAP-pwd in their Wi-Fi networks. It is rarely even presented as an option. Unless your job involves actually building Wi-Fi devices, you don't need to worry about this.

Dragondrain
From the readme: The Dragondrain tool forges Commit messages to cause a high CPU usage on the target. This can for example be used to drain the battery of a device, or more generally to drain and exhaust resources.

The name is a play on the fact that this is a 'clogging' attack.

Should you worry?
Not if you keep your network devices up to date.
It is a denial-of-service attack. The authors have already given the solution to the vendors to implement i.e. use a dedicated, low-priority CPU thread to run this task so that the entire CPU can never be impacted.

Dragontime
From the readme: This is an experimental tool to carry out timing attacks against WPA3's SAE handshake. It was created to carry out attacks, not to detect whether an implementation is vulnerable in the first place. It was used to carry out the timing attack against MODP groups 22 and 24 as described in the Dragonblood paper.

This vulnerability actually has a CVE allocation: CVE-2019-9494

Should you worry?
Not too much.

You don't need to know what MODP (Modular Exponential) groups are, just that they are options implemented in cryptographic algorithms. Three groups have been identified here as being vulnerable while another three groups are suggested to be avoided. This can be fixed in a software patch that simply removes those groups as options (that is if the groups were ever used in the first place - according to the paper there were already known issues since 2017 with these groups, so they should have been avoided all along). The authors even state this "Note that most WPA3 implementations by default do not enable these groups"

Dragonforce

This is the tool that takes the information from the other tools and runs something similar to a dictionary attack to retrieve the keys.

What about that 'downgrade attack' mentioned earlier?

It is really difficult to move 20 years' worth of devices to a new encryption scheme, so the WPA3 standard allows for a compatibility mode, or transition mode, of operation where the network will simultaneously support WPA2 and WPA3. The attack in this case involves setting up an 'evil twin' SSID using only WPA2 and the client device connects to it because it knows that WPA2 is still permitted. WPA2 vulnerabilities are then leveraged to discover the keys.

Should you worry?

No more than you worried yesterday about your WPA2 networks.

The fix for this needs to come from the manufacturers of client devices. Samsung, Apple, Lenovo, etc. 

As a network operator you can run WIDS/WIPS to guard against this type of attack.

I'm having trouble sleeping at night, where can I find the full paper?

The full paper has been published at https://papers.mathyvanhoef.com/dragonblood.pdf

How To: Upgrade Aruba Airwave

Introduction

This post will answer the following 3 questions:

1. How to upgrade Aruba Airwave Server?
2. How long does it take to upgrade Aruba Airwave?
3. What type and duration of outage can be expected during the upgrade of Aruba Airwave?

The example below shows the actual output from a real upgrade of AMP from version 8.5 to version 8.2.7.1 in a single server environment (no Glass). This specific server is a virtual appliance hosted on Hyper-V.

As Network administrators we are used to upgrades of firmware on a switch, router or WLC taking a few minutes at the most. When it comes time to upgrade the server software we use, we can be caught off-guard by the lengthy amount of time required and it is unclear when any outage will occur. To help with understanding the process I present to you an annotated output of the upgrade process, including timings.

System Output

Key:

    System output

    My input

    My annotations

    Outage information

Before starting the backup, download the nightly backup file from the web GUI to a safe location.

T = time of initial login to CLI

login as: ampadmin

Authorised access only. Managed by xyzabc.

ampadmin@server's password:

Last login: Fri Sep 14 13:49:46 2018 from server

Loading Menu...

AirWave Management Platform 8.2.5 on servername

  1  Upload File

  2  Download File

  3  Delete File

  4  Backup

  5  Restore

  6  Support

  7  Upgrade

  8  Advanced

  9  Security

10  Custom Commands

  q  >> Quit

Your choice: 7

Upgrade

  1  Upgrade AirWave Management Platform

  2  Upgrade OS Kernel

  b  >> Back

Your choice: 1

Running Upgrade AirWave Management Platform

AMP version: 8.2.7.1

Running [/usr/local/airwave/bin/start_amp_upgrade -f /var/ampcli/user -v 8.2.7.1]...

Upgrade script AMP-8.2.7.1-amp_upgrade was not found in local cache.

Upgrade package AMP-8.2.7.1-x86_64-cvs.tar.gz was not found in local cache.

Upgrade package will be downloaded from the internet...

Do you use proxy server? (y/N): N

Download upgrade package from:

    1. Aruba Support Portal

    2. HPE My Networking Portal

Enter your choice (1 or 2): 1

Preparing to connect to Aruba Support Portal...

Enter your Aruba Support Portal username: USERNAMEgoesHERE/PW Prompt not shown

######################################################################## 100.0%

Upgrade package AMP-8.2.7.1-x86_64-cvs.tar.gz was not found in local cache.

Checking iptables.

T + 2 minutes

Checking the database schema.

T + 5 minutes

Preparing to connect to Aruba Support Portal...

T + 20 minutes (the progress bar stays on a single line unless you hit enter)

##########################                                                36.9%

T + 32 minutes (this part takes a while)

##########################################################                81.1%

T + 40 minutes (phew, finally)

######################################################################## 100.0%

Validating the upgrade package...

Verifying authenticity of the upgrade package....

Verifying signature....

Good Signature....

Verifying checksum....

Upgrade package verified....

Upgrading AMP to version 8.2.7.1 from version 8.2.5...

Detailed log will be written to /var/log/upgrade/AMP-8.2.7.1-upgrade.log

STEP 1: Moving old version aside.

STEP 2: Unpacking upgrade package.

STEP 3: Checking for compatibility.

T + 45 minutes

STEP 4: Stopping AMP services

T + 46 minutes
46 minutes after starting the upgrade, Airwave Application is unavailable. 
The Airwave server itself is still up and responding to ICMP monitoring, and for some time also HTTP monitoring.
As shown in the screenshot below: the browser which was displaying Airwave GUI is still reachable but shows a 502 error in the frame.

STEP 5: Installing upgrade.

T + 55 minutes. Still installing the upgrade. Waiting patiently. No useful feedback on terminal.

***************************************************************

Updated kernel packages that fix various security issues are now

available for your OS. To upgrade, select 'Upgrade' menu item on the AMPCLI Menu,

and then choose 'Upgrade OS Kernel' menu item.

For more information refer to the security advisory:

  https://access.redhat.com/errata/RHSA-2018:2390

***************************************************************

T + 57 minutes. Upgrade complete

STEP 6: Restarting AMP services.

**********************************************

Post upgrade schema check is in progress..

This may take a few minutes..

**********************************************

T + 59 minutes.
Services are back up (verify by logging in to web GUI). 13 minutes of actual application outage time so far, and server stayed up the entire time. 😏

But wait! There was a prompt to also upgrade the OS Kernel. Looks like we're in for a full reboot after all. 😫.

Upgrade from 8.2.5 to 8.2.7.1 is successful.

Hit <enter> to continue

Hit enter to continue, 's' to show output, 'r' to show return code.

Upgrade

  1  Upgrade AirWave Management Platform

  2  Upgrade OS Kernel

  b  >> Back

Your choice: 2

T + 1 hour 02 minutes

Running Upgrade OS Kernel

A newer version of the kernel is available.  If you choose to upgrade

you will need to reboot the system for the change to take effect.

Upgrade the kernel? (y/N) y

Preparing...                ########################################### [100%]

   1:kernel-firmware        ########################################### [ 33%]

   2:kernel                 ########################################### [ 67%]

   3:kernel-headers         ########################################### [100%]

The kernel has been upgraded successfully.

T + 1 hour 04 minutes. (wow that kernel upgrade was really quick compared to the application upgrade)

Reboot now? (y/N) y

Are you sure? (y/N) y

Broadcast message from ampadmin@servername

        (/dev/pts/0) at 10:44 ...

The system is going down for reboot NOW!

Hit enter to continue, 's' to show output, 'r' to show return code.
<end of output>

At this point the server reboots and the SSH session is lost. Now the server is hard down.

T + 1 hour 07 minutes

The server is back up after only a couple of minutes. The services will take some time to start up.

T + 1 hour 10 minutes 

Done! The application is back up and running and verified.

Conclusion

The Airwave upgrade process is heavily scripted by Aruba and doesn't need much interaction after starting the upgrade. In fact I only touched the keyboard a handful of times and mostly for y/n input. The upgrade does always take a lot longer than I expect which I why I decided to document it this time.

There were 2 outages: 13 minutes while the application upgraded and another of 6 minutes for the OS reboot.

Despite the fact that I had allocated a 1 hour outage window for this change (which I thought was overly generous at the time, ha), I ran over the window with the second part of the outage actually falling outside of that window, ouch.

Other factors that could possibly impact the upgrade duration are the size of the database and the specs of the VM resources allocated.

Note that the application can be upgraded by firstly downloading the file from Aruba or HPE website then uploading locally to Airwave, then starting the process. I have not yet timed that method.

Note also that the RHEL kernel can be upgraded at any time from the AMPCLI menu, it does not need to happen as part of the application upgrade.