Connecting the world…


Aruba Airwave 8.2.4 and no CLI / shell access

BE AWARE: reading and applying this blog is at your own risk. Following the below procedure could affect the support validity on your Aruba AirWave appliance.

All AirWave firmware versions prior to 8.2.4 gave you shell access to the CentOS operating system. Once you upgrade from 8.2.3 to 8.2.4 you receive the message that the root user won’t be used anymore and you need to log in with the user ampadmin.

Your system has been converted to use AMPCLI. You may now log in as ampadmin. If you lose the password for ampadmin you may log in as amprecovery (password recovery) on the console to reset the ampadmin password.

Remove any OS user accounts you may have created to complete the securing of the system.

Once you log out, the linux shell will no longer be accessible.

Starting from 8.2.4 you only have a basic options menu and no shell access anymore. To me, this is a burden because I cannot install VMware Tools anymore or configure scheduled backups to offsite storage. Luckily there is a way to restore the shell access, but the guidelines below need to be applied directly after the upgrade from 8.2.3 to 8.2.4 and cannot be done on a new 8.2.4 installation.

Some additional information: /etc/passwd file stores essential information, which is required during login i.e. user account information. /etc/passwd is a text file, which contains a list of the system’s accounts, giving for each account some useful information like user ID, group ID, home directory, shell, etc. /etc/passwd contains the following entry before you start the upgrade.


Just start the upgrade as you always do, but do not log off after the upgrade is completed. Take another look at the /etc/passwd file and especially the entry for the user root.


The entry changed and /sbin/nologin disables the shell access for the root user. Change the entry to the default value and you are good to go!!! You should still have access to the shell after logging off or rebooting the appliance.

Flash clean-up

Lately I upgraded a Aruba Networks wireless controller or at least I tried…… The upload of a new image to the controller has two steps. First the copy process from a TFTP server to the controller and second the actual writing of the new firmware image to flash (system partition). The second step kept showing me exclamation marks for minutes. I left it running for one hour and finally decided to break the upload by ending the SSH session and starting a new SSH session. I wasn’t able to connect to the controller via SSH and physical access via the console didn’t work either. So I decided to reboot the controller via the hard reset. The controller rebooted the old system partition, but I noticed that the new system partition was imported and digitally signed (check via: show image version).

I changed the boot parameter to boot the new software and rebooted the controller. I received the following error message on the console after the reboot.

Ancillary image stored on flash is not for this release
* WARNING: An additional image upgrade is required to complete the *
* installation of the AP and WebUI files. Please upgrade the boot *
* partition again and reload the controller. *

I decided to upload the firmware a second time to the same system partition, but this time the controller “told” me that there wasn’t enough free space on the flash drive so I couldn’t copy the file. I noticed that I only had 35M flash storage left (check via: show storage).

I deleted some files from flash (via command: delete filename <file name>), but I couldn’t free enough space to copy the image a second time. Finally I used the tar command to clean up enough storage. The tar command archives a directory and creates a tar file in the flash memory, which can be deleted. The syntax is:

tar clean {crash|flash|logs}| crash | flash | logs {tech-support|user}}

I ran the commands:

tar crash
tar flash
tar logs.

This creates three separate files in the flash memory. The files can be deleted via the commands:

tar clean flash
tar clean logs
tar clean crash

After running these commands I had113.3M flash storage available, which is more than enough to copy the new firmware a second time to the system partition.

In my situation the crash files were the reason I didn’t have enough flash memory. Because I did a hard reset the controller created a lot of crash files, which are stored in flash memory.

Provision Aruba AP via CLI

Below you will find the necessary commands to provision an Aruba access-point via CLI. The commands add the access-point to the AP whitelist and provision the AP in the correct ap-group. Adding the AP to the whitelist is necessary when using control-plane security.

whitelist-db cpsec add mac-address “94:b4:0f:c4:7e:98” description “ap01”
whitelist-db cpsec modify mac-address “94:b4:0f:c4:7e:98” cert-type factory-cert state certified-factory-cert
clear provisioning-ap-list
provision-ap read-bootinfo ap-name “94:b4:0f:c4:7e:98”
provision-ap copy-provisioning-params ap-name “94:b4:0f:c4:7e:98”
provision-ap installation indoor
provision-ap no external-antenna
provision-ap server-name “aruba-master”
provision-ap ap-group “corp-01”
provision-ap ap-name “ap01”
provision-ap no syslocation
provision-ap no remote-ap
provision-ap reprovision ap-name “94:b4:0f:c4:7e:98”
clear provisioning-ap-list
clear provisioning-params

Aruba MAS – Tunneled node

Today I played a bit with an Aruba Mobility Access Switch with Tunneled Node configuration to a Aruba Mobility Controller. More information on Tunneled Node can be found here.

The configuration is straight forward. You need to configured a tunneled-node profile on the MAS and associate the access ports on the MAS to a VLAN, which is also present on the controller. I already have a controller in place and I would like to use some access ports for guest users with captive portal capabilities. I already setup a SSID with captive portal capabilities, so I use the same AAA profile on the controller for the tunneled-node clients.

I created the following configuration on the Aruba MAS.

controller-ip vlan 75
interface-profile tunneled-node-profile “tunnel-prof”
mtu 1300
interface-profile switching-profile “vl150-prof”
access-vlan 150
interface-group gigabitethernet “vl150-group”
apply-to 0/0/1-0/0/22
tunneled-node-profile “tunnel-prof”
switching-profile “vl150-prof”

The IP-profile defines the controller-ip of the MAS and the default-gateway configuration to access the Aruba controller ( A switching profile is configured with access vlan 150 and the tunneled-node and switching-profile are bound to switch ports 0/0/1 to 0/0/22.

On the controller you only need to enable wired access and assign the AAA profile, which you also use for the guest SSID.

aaa authentication wired
profile “guest-aaa_prof”

A guest devices gets an IP address assigned from VLAN 150, located behind the corporate Aruba Mobility Controller when I connect a device to switch port 0/0/1. The guest-aaa_prof is assigned to the device/user. This redirects the user to the captive portal to enter login credentials. You can also configure user derivation to assign different VLANs to the connected devices behind the Aruba MAS.

Aruba WPA2 with MAC authentication

Configuring an SSID with WPA2 Pre-Shared key or Enterprise authentication and encryption is very common. Sometimes you would like to add an extra authentication method. Although this method isn’t very secure, MAC authentication is still used as an extra method to strengthen the level of security of a wireless or wired network.

These days I have been configuring a Aruba Networks wireless network with one master en two local controllers. The customer is using WPA2 security and wanted to add MAC authentication as extra authentication method. The configuration of MAC authentication for Aruba Mobility Controllers is very straightforward. This blog provides an example of the MAC authentication configuration. The configuration of a MAC Authentication Profile and the definition the MAC database are key in the solution.

While testing I noticed that MAC authentication only worked when I configured the parameter “Max Authentication Failures = 1” of the MAC Authentication Profile. The MAC address of the client is blacklisted if it’s unknown. When blacklisted, the client cannot associate with any SSID for at least one hour. This wasn’t exactly what I wanted to happen.

The following log contains the user-debug information during the authentication process, when the parameter is still set to 0.

Dec 14 09:01:20 :522005: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User entry deleted: reason=essid change
Dec 14 09:01:20 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP=N/A User data downloaded to datapath, new Role=authenticated/54, bw Contract=0/0,reason=Station resetting role
Dec 14 09:01:20 :522042: <NOTI> |authmgr| User Authentication Failed: username=cc:08:e0:5e:2c:7b MAC=cc:08:e0:5e:2c:7b IP= auth method=MAC auth server=Internal
Dec 14 09:01:22 :522026: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User miss: ingress=0x1200, VLAN=666
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User role updated, existing Role=WA-Test_role/none, new Role=WA-Test_role/WA-Test_role, reason=First IP user created
Dec 14 09:01:22 :522006: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b IP= User entry added: reason=Sibtye
Dec 14 09:01:22 :522049: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User role updated, existing Role=WA-Test_role/WA-Test_role, new Role=WA-Test_role/WA-Test_role, reason=User not authenticated for inheriting attributes
Dec 14 09:01:22 :522050: <INFO> |authmgr| MAC=cc:08:e0:5e:2c:7b,IP= User data downloaded to datapath, new Role=WA-Test_role/59, bw Contract=16385/16385,reason=New user IP processing

To me it looked like the authentication was using an OR statement instead of and AND statement. Eventually, with the help of cjoseph from Airheads Social, I noticed that after WPA2 authentication, the user gets the initial role of the AAA profile. I configured this profile as authenticated (allow all). Next MAC authentication is performed. If MAC authentication fails, the user still has the initial role from the AAA profile. If MAC authentication succeeds, the client is elevated to the MAC authentication role from the AAA profile.

I want both authentication methods to be successful before the client is granted access to the network. The only thing to change was, changing the initial role from the AAA profile to deny all.

aaa profile "WA-Test_aaa_prof"
   initial-role "denyall"
   authentication-mac "MAC_auth_prof"
   mac-default-role "WA-Test_role"
   mac-server-group "MAC-auth_srv"
   authentication-dot1x "default-psk"