-
Reset to factory defaults
reset config bootstrap reset configThe username is
adminand the password isaerohiveorAerohive1. -
Configure interfaces
interface mgt0 vlan [management VLAN] interface mgt0 native-vlan [native VLAN] interface eth0 native-vlan [native VLAN] interface eth1 native-vlan [native VLAN] -
Update firmware.
AP230-10.5r3.img.SNote: If the current firmware is older than 6.1r6, first upgrade to 6.1r6, then 6.2r1, then you can update to any version.
save image <location> now # tftp://location:path/filename # scp://username@location:path/filename save image <url> now # http://domain/path/file -
Set admin password
admin root-admin admin password [password] -
Create a hive for all access points to join.
hive MyHive hive MyHive password [password] -
A few miscellaneous things
system led brightness off no capwap client enable
The switch ports should be trunk ports passing all the VLANs you need. Make sure the native VLAN configuration on the switch matches the AP.
It is simpler if the native VLAN is the management VLAN. That means you can plug in the AP without first having to console in and set the management VLAN.
Once everything is configured, run save config so it persists across reboot.
A user profile sets the VLAN, QoS policy, and firewall rules
user-profile Guest vlan-id 1 attribute 1
user-profile Inside vlan-id 5 attribute 5
user-profile IOT vlan-id 10 attribute 10
User profile policies map users to user profiles based on rules. This is only necessary if you're using PPSKs.
Rules are evaluated in sequential order based on the rule number. Leave some space between the rule numbers, such as 10, 20, 30, etc., to allow for inserting rules in between other rules later.
Note: Be sure to create the user groups first. See the users section.
user-profile-policy <name> action-for-upid-change switch
user-profile-policy <name> rule <number>
user-profile-policy <name> rule <number> user-profile-attr-id <new attribute if rule matches>
user-profile-policy <name> rule <number> group-name <group>
Security objects control the authentication mechanism (PSK, PPSK, RADIUS, etc.) and the default user profile attribute for an SSID.
security-object Guest
security-object Guest security protocol-suite wpa2-aes-psk ascii-key [PSK]
security-object Guest security private-psk
security-object Guest default-user-profile-attr 1
security-object Inside
security-object Inside security protocol-suite wpa2-aes-psk ascii-key [PSK]
security-object Inside security private-psk
security-object Inside default-user-profile-attr 5
security-object IOT
security-object IOT security protocol-suite wpa2-aes-psk ascii-key [PSK]
security-object IOT security private-psk
security-object IOT default-user-profile-attr 10
If/when you switch to using PPSK, you'll need to add these lines to each security object:
security-object <name> security private-psk default-psk-disabled # Only if you don't want to use the default PSK
security-object <name> user-profile-policy <user profile policy name>
Create the SSIDs which you will later add to interfaces. You can have tons of SSIDs but they do not become live until you assign them to interfaces.
Note: Rather than creating several SSIDs, consider using one SSID with PPSKs and user profile policies to put users in the correct VLAN based on their user group.
ssid Guest
ssid Guest security-object Guest
ssid Guest 11g-rate-set 11-basic 12 18 24 36 48 54
ssid Inside
ssid Inside security-object Inside
ssid Inside 11g-rate-set 11-basic 12 18 24 36 48 54
ssid IOT
ssid IOT security-object IOT
ssid IOT 11g-rate-set 11-basic 12 18 24 36 48 54
For PPSKs, add the groups to the SSID:
Note: This is important. If you do not associate user group with an SSID, devices will not be able to connect.
ssid <name> user-group <group>
These are the nitty gritty radio behaviors. You can just use the default profiles (show radio profile). These are mine which I've tweaked a bit.
radio profile radio_ng_bandsteering1
radio profile radio_ng_bandsteering1 phymode 11ng
radio profile radio_ng_bandsteering1 frameburst
radio profile radio_ng_bandsteering1 band-steering enable
radio profile radio_ng_bandsteering1 band-steering mode prefer-5g
radio profile radio_ng_bandsteering1 band-steering prefer-5g suppression-limit 3
radio profile radio_ng_bandsteering1 weak-snr-suppress enable
radio profile radio_ng_bandsteering1 weak-snr-suppress threshold 25
radio profile radio_ac1
radio profile radio_ac1 phymode 11ac
radio profile radio_ac1 dfs # Enable DFS channels
radio profile radio_ac1 channel-width 80
radio profile radio_ac1 weak-snr-suppress enable
radio profile radio_ac1 weak-snr-suppress threshold 25
The 2.4 GHz interface is wifi0, the 5.0 GHz interface is wifi1.
interface wifi0 radio profile radio_ng_bandsteering1
interface wifi0 ssid "Nacho WiFi"
interface wifi1 radio profile radio_ac1
interface wifi1 ssid "Nacho WiFi"
Changing these settings are optional. By default, the AP will use wifi1 (5 GHz radio) for access and backhaul traffic and wifi0 (2.4 GHz radio) only for access. All APs in the same hive will create mesh connections if a wired connection is not present.
One important thing to note is that the "portal" AP (the AP with a wired backhaul connection) and the "mesh" AP must be using the same channel otherwise they will not connect. By default, the channels are set automatically. You can manually set the channel to help the mesh link come up faster.
There are three modes for an interface:
- access: only allow wireless clients
- backhaul: do not allow clients and only use for wireless mesh
- dual: use for both wireless clients and wireless mesh
If the 5 GHz radio isn't providing a reliable mesh connection, using the 2.4 GHz radio will usually provide better results.
Here is an example of configuring the 2.4 GHz interface for mesh connectivity.
On the portal (non-mesh) AP(s):
interface wifi0 mode dual
interface wifi0 radio channel <int> # Optional. If set, it must be set the same as the mesh AP(s).
interface wifi1 mode access # Optional. Set this to prevent the 5 GHz radio from being used for mesh connectiviy.
On the mesh AP(s):
interface wifi0 mode dual
interface wifi0 radio channel <int> # Optional. If set, it must be set the same as the portal AP(s).
To verify the interfaces are configured correctly, run show interfaces. Look for Wifi0.1 and Wifi0.2 interfaces. One should be in backhaul mode the other in access mode.
To verify mesh connectivity, run show hive <hive> neighbor. On the portal and access APs you should see the MAC of the AP(s) to which they are connected and other useful information.
The last thing to check is that the roaming cache is being updated with the MAC of clients connected to the mesh AP. Run show roaming cache | i <mesh mac> to see that the mesh AP has reported clients to other APs in the hive.
Because Aerohive APs use a Trusted Platform Module for storing user information, it's best to think of user settings and other configuration as two separate files that need to be managed. Saving the running config does not save the user config. Likewise, showing the running config does not show the user config.
user-group <string>
user-group <string> user-attribute <default attribute ID>
user <string> password <string>
user <string> group <string>
save config users
Note: If show users lists any user accounts as invalid, that is because a user group needs to be created.
There are four different config files in HiveOS: current, backup, bootstrap, and default. The current config is what is loaded on boot. It is what is updated by default when running save config. Details on the different config files can be found here.
Backup running config
show running-config password > scp://username@location:path/filename
Backup PPSK passwords
show running-config users password > scp://username@location:path/filename
Restore running config
save config scp://username@location:path/filename current now
Restore PPSK passwords
Note: This command does not work. The only way I have found to restore PPSK configs is by copy/pasting the values into a command prompt.
save users updating-config scp://username@location:path/filename
Since HiveOS doesn't support SSH keys, I wrote a TCL script that pulls the password from the macOS system keychain to ease logging in.
Open Keychain Access and create a new password object. The "Account" field is what you'll use to look it up.
To run the command: networklogin.tcl [username] [FQDN or IP] [account name].
I went a step further and created Profiles in iTerm2 for each AP to make it even easier to jump into the AP.
#!/usr/bin/expect
# Automatically login using password from system keychain
set timeout 20
set prompt \[Pp\]assword:
set account [ lindex $argv 0]
set host [ lindex $argv 1 ]
set keychain_account [ lindex $argv 2 ]
set host_string "$account@$host"
set password [ exec /usr/bin/security find-generic-password -a $keychain_account -w ]
if { $account == "" || $host == "" || $keychain_account == "" } {
puts "Please enter a host, account, and keychain account"
exit 1
}
spawn -noecho ssh -A $host_string
expect {
# Accept SSH host key
yes/no {
send yes\r
exp_continue
}
# Wait for login prompt, then send password
-re $prompt {
send $password\r
}
}
interact
It may be necessary to turn down interface power and/or remove slower data rates to encourage clients to roam faster and prevent APs from interfering with each other.
This article has excellent details on troubleshooting RF issues.
To get an overall idea of interface health:
show interface wifi0
show interface wifi1
The Summary should be "Good" or "Fair". Anything other than that indicates a problem.
Telling the AP not to advertise slower data rates can help clients roam to a different AP rather than hanging on to an AP at a slow data rate. The advertised rates are set per SSID per mode. Here is how to disable rates below 11 Mbps for 802.11g:
ssid <your SSID> 11g-rate-set 11-basic 12 18 24 36 48 54
It's possible to do this for 802.11ac as well, but there are many rate sets that have to specified using the proper MCS value. The issue is usually with 2.4 GHz data rates, not the 5 GHz rates, so don't worry about adjusting the 5 GHz rates unless you really need to.
EIRP (Effective Isotropic Radiated Power) will show the current Transmit Power.
You can also run show acsp (Aerohive Channel Selection Protocol) to show the current Transmit Power. The default setting is auto which will select a number between 1-20.
Ideally APs will see a signal strength of -75 or lower from their neighbors. Higher than that and there is potential for interference (which can also come from other APs).
show acsp neighbor | include <your SSID>
Once you determine which interface (wifi0 is 2.4 GHz, wifi1 is 5 GHz) on which AP to adjust, dial it down 2 dBm from its current value:
interface wifi0 radio power 10
You need to wait a while for the ACSP scan to run again (the default interval is 10 minutes) before the signal strength measuremetns update. You may wish to reset interface counters and wait about an hour before rechecking the packet loss rates.
clear interface wifi0 counter
Common CLI commands, and what they're used for (Extreme Portal)
Show who is connected to an AP:
show auth
Show devices on an AP:
show station
show station | include <regexp>
show station <mac>
Show devices on an AP with MAC, user name, hostname, and IP:
_show rt-sta
Show devices on an AP in JSON:
show _client detail info
Kick a device off an AP to force roam/reauth:
clear auth username <user>
clear auth roaming-cache mac <mac> hive-all
clear auth local-cache mac <mac>
clear auth station mac <mac>
Secret command to enable debug logging:
_debug <options>
Show logs:
show log buffered
show log buffered tail <number>
show log buffered | include <regexp>
Show neighboring SSIDs and their signal strength:
show acsp neighbor
Show details on each channel:
show acsp channel-info detail
Show interface details:
show interface <interface>
Show interface counters:
show interface <interface> _count
Show serial number for adding to ExtremeCloud IQ
show hw-info
Reset interface counters for troubleshooting:
clear forwarding-engine counters interface <interface>
Test the trunk port to an AP to make sure VLANs are working and there in DHCP on the VLAN:
interface mgt0 dhcp-probe vlan-range <VLANs>
Shut down a wireless interface. A virtual interface, wifi0.x, is created for each SSID:
interface wifi0.1 shutdown
# An alternative command to do the same thing
interface wifi0 ssid <SSID> shutdown
Blink the LED in order to locate an access point:
_led color amber fast-blink
# The full command options:
_led color [off] [amber|white] [no|slow|fast]-blink
# Disable LED blinking
no _led color
_led color off no-blink
SNMP disabled by default default community is hive community
enable SNMP with public via
hive <hivename> manage SNMP
interface eth0 manage SNMP
snmp reader version v2c community public
The uboot can be accessed when booting and watching via console port. Once you pressed any key to interrupt the boot you need the uboot password, which should be: AhNf?d@ta06
The CLI is pretty restricted. There exists a hidden command _shell to access the underlying BusyBox. This requires a password, which is dependent on the serial number. Check https://github.com/NHAS/aerohive-keygen for a tool to generate the password.
Also see https://research.aurainfosec.io/hacking-the-hive/ for more info about the underlying busybox system.
I've had some weird connectivity issues with a specific user with PPSKs when they have five or more devices connected. I don't have any per-PPSK limits set on the group or SSID.