Download AirO Admin Guide v13

AirO
The Air Observer from Aruba Networks
“If your app needs a guide, you’d better fix the UI so it doesn’t.” – anonymous app guru
AirO is intended for technical and not-too-technical owners of Wi-Fi capable Android and iOS
devices. It displays the health of the Wi-Fi (“Local Area”) connection, and measures the
characteristics of a “Wide Area” connection to a server deeper in the network. It can be used to
answer questions like:





What’s wrong with my Wi-Fi today?
How strong is my Wi-Fi signal?
Is there evidence of wireless interference?
Is the problem in the Wi-Fi connection, or out on the Internet (or corporate network)?
Is the overall connection to the data center good enough to run my corporate apps?
Internet
AirWave
Server
Cloud iPerf
Server
LAN / WAN
Enterprise iPerf
Server
AP / controller
Discover AirWave &
other servers, send
AMC reports & receive
updates
Show the user the data sent to
Airwave, with simple quality
indications. Buttons for ‘report
trouble’ and ‘diagnostic help’
“Wi-Fi and Local Area Network”
The top “Wi-Fi and Local Area Network” section of the screen displays three measurements that
show the health of the Wi-Fi connection:

Signal Strength. In Wi-Fi terms, this is received signal strength, or RSSI. It is measured
in dBm and is always negative. A larger (negative) number indicates a weaker signal.
o When right next to an access point, the figure might be -35 dBm
o When standing underneath a ceiling-mounted access point, perhaps -40dBm
o A ‘good’ signal is better than -68dBm
o The signal will be problematic below -75dBm
o A signal of -80 dBm is generally unreliable to unworkable
We measure signal strength first because if it’s poor, there is no chance of getting a good
connection. The remedy, in simple terms, is to get closer to the access point.

Link Speed. This is technically the modulation rate of the Wi-Fi link in Mbps.
o A new 802.11ac device (Samsung Galaxy S4) might show 200+ Mbps
o An 802.11n device might reach 65 Mbps or 130 Mbps with 40 MHz channels
o Under normal conditions a link faster than 20 Mbps is very good
o Once a link drops below 5 Mbps it is likely to be unreliable
The usual cause of low link speeds is poor signal strength. But sometimes, even when
signal strength is good, interference on the air from Wi-Fi and non-Wi-Fi sources reduces
link speeds.

Ping. This is the familiar ICMP echo test to the network’s default gateway, normally a
router close behind the access point. It indicates the round-trip delay between sending a
packet to this gateway and receiving a response.
o Ping results vary quite widely
o With good conditions, a stable delay of less than 20 msec is expected
o If ping times are consistently over 100 msec, application performance will suffer
o A ping time above 500 msec indicates something’s wrong
A low link speed will often cause long ping times. If link speeds are good but pings
slow, it may be a long way to the default gateway over a narrow broadband connection.

Strongest AP. On the right of the ‘Wi-Fi’ section is a small icon showing “Strongest
AP”. In the Wi-Fi protocol, devices are responsible for choosing the access point they
connect to, and sometimes when their owner moves, they remain ‘sticking’ to an old, and
now distant access point. The left-hand bar of the icon shows the signal strength of the
connected (“this”) access point. The right-hand bar shows the signal strength of the
strongest signal the device (with the same SSID) showing on the device’s Wi-Fi scan.
Under each is the signal strength value, in the same units as for the ‘signal strength’
reading. Because the scan is a different measurement, some variation is expected, but if
‘this AP’ is more than about 10dB weaker than ‘best AP’ it’s time to move closer to ‘this
AP’ or shake the tree by putting the device into airplane mode and out again - one way to
induce the device to move to the stronger access point. (Note: Some Android devices
are very reluctant to scan: if both readings are at -99 but there’s a good connection, it is
because the Wi-Fi interface is not returning scan information to the AirO app. Putting the
device into/out of airplane mode, or toggling Wi-Fi off/on, should fix this but not
permanently.)

Address. The header line of “Wi-Fi and Local Area Network” displays the device’s IP
address, the SSID of the current connection and the radio channel (channels < 15 are in
the 2.4GHz band, > 30 are in the 5GHz band).

BSSID. There is a display of the BSSID of the currently-connected AP, and a lookup of
the IEEE OUI database gives the manufacturer’s name.

Summary Bar Graph. At the bottom of the ‘Wi-Fi and Local Area Network’ section is a
horizontal bar graph. This displays an overall estimate of the health of the Wi-Fi
network, from a proprietary formula by the CTO group. We are aware that this is a
subjective figure, and the coloring may not always be consistent with the icons beside
individual figures (e.g. the bar is yellow when there are at least two red icons).
“Wide Area Network”
The lower section of the screen displays results from tests between the device and an iPerf
server, usually in the corporate data center or on the Internet. The address of this server is
chosen from a number configured in ‘settings” – but once chosen, only one server address is
used for these tests.

Ping. There is a ping measurement to this server. It is the same ICMP ping test as above,
but because this one goes further it will normally (but by no means always) take longer.
Again, 20msec would be fast and 500 msec would be slow.
Some networks may block ICMP (ping) traffic. In this case, the Wide Area Network
ping test will always fail, but normal (e.g. Web) traffic may pass.

Speedtest. The next tests are ‘speedtests’. For this, we use the iPerf function (iPerf v2).
In a corporate context, this should be an iPerf server instance set up somewhere in the
core of the network, probably a data center. Because it is a throughput test, the figures
here will never be more than about 50% of the ‘link speed’ figure for the Wi-Fi
connection. The iPerf client in the app is configured to run in bidirectional mode, first an
upstream test then downstream.
o In a corporate network, uplink and downlink speedtest should give a figure higher
than 10M bps.
o In a home network, the speed will usually be limited by the broadband connection
rate. A figure of 1 to 10 Mbps can be expected. In home networks, or behind
firewalls, the downstream test may fail to pass the firewall, but this does not
indicate normal (e.g. Web) traffic will fail.
o The icons to the left of the screen spin after an iPerf request has been sent, and
before a response is received. This gives the user an idea of what’s going on
because iPerf doesn’t give us continuous measurements.
Most apps should perform adequately even with network rates below 1 Mbps, but at
some point below 0.3 Mbps, application response times will slow.
The back-stop iPerf server is an Aruba CTO-maintained Amazon Web Service hosted in
Portland, Oregon. If no iPerf address is discovered (see mDNS below) or configured in
Settings, or if the app can’t open a socket to port 5001 on this IP address, the app will fall
back to this “cloud” server with a 54.X.X.X address.
An appendix to this document contains more details on the iPerf tests and setting up an
iPerf server.

Summary Bar Graph. The horizontal bar graph shows the overall health of the Wide
Area connection, a combination of Ping and iPerf measurements.
The diagram below shows the paths followed by the various tests run by AirO:
Internet
AirWave
Server
Report to
AirWave
default
gateway
Ping
default
gateway
Cloud iPerf
Server
LAN / WAN
Enterprise iPerf
Server
AP / controller
Ping and iPerf to
“WAN” iPerf server
or cloud iPerf server
Blue buttons
The left-hand ‘email report’ button does just that – it generates a snapshot of Wi-Fi and phone
conditions and emails it to <whoever you want>, usually a helpdesk address. The default
address is in ‘settings’ but can be over-ridden when sending the email. The data is contained in a
CSV formatted file that can be opened by Excel or another spreadsheet program, headers are
included so it should be self-explanatory.
One virtue of the email report is that the snapshot can be taken when the device has no
connectivity, saved as a draft and sent later, when conditions are better. We believe users are
happier when they can do something to report trouble (we’ll see whether helpdesks agree).
The right-hand ‘diagnostic ideas’ button brings up a relatively simple set of conclusions drawn
from the data displayed on the screen. Each diagnostic idea explains in simple terms what’s
going wrong and how things might be improved. It will be obvious to the user that, particularly
in bad conditions, readings jump around a lot, and it is difficult to get a consistent estimate of
what’s wrong… we’ll be working to improve this function in the future.
Settings
Settings are accessed in the usual way (varies with device and Android version but usually the “ :
- symbol with three dots”).


There are five available address fields for iPerf server addresses. IPv4 or FQDN (the
app isn’t tested with IPv6) points to the host that is used for WAN Ping and Speedtest
tests. When first launched, and every minute following, a test utility checks reachability
to port 5001 (the iPerf default receive port) of each address in turn. The first one that
passes the test is used, so the list is an ordered list… It is pre-populated with two values
at the bottom, one for a public iPerf instance (54.201.159.31) and the last for a private
address in the Aruba Sunnyvale network (10.6.100.216). When used in a corporate
context, the addresses of one or more private iPerf servers should be entered in one of the
upper address fields (if the iPerf address is learned from AirGroup (see below, mDNS) it
is inserted after the top and above the second configured address.
iPerf test frequency is actually the repeat interval. The default is 20 sec. It is not
reasonable to reduce this below about 10 sec, and it can be increased. If there is no
response to iPerf requests, the app will timeout and re-start after 2x this interval. Results
are staled out after 3x this interval.



iPerf duration is the –t parameter in the iPerf command line. The default is 4 sec. As
noted below, the default behavior on this app is
iperf –c <server address> -r –i 2 –t <duration>
With the default of 4 sec, this takes 4 sec for the upstream test then another 4 sec for
downstream. Given some latency, the overall test will take 10-16 sec, which is why the
default frequency is set to 20 sec. The idea of bursty, not continuous testing is to avoid
congesting the network with test traffic.
This default command line can be over-ridden by the knowledgeable user (see appendix).
Default email address for report. The ‘email report’ button triggers the device’s email
functions to come to the foreground, pre-populated with the report attached, a title and
this address as the addressee. This is just a time-saver, it can be over-ridden.
‘Send background reports’ is an opt-in option (default is off) to send periodic reports
about wireless conditions to a server maintained by Aruba. When used by a significant
percentage of a population over time, this can provide statistical insights into Wi-Fi
patterns across a campus.
AirWave Reporting
The app can be used on all WLANs, not just Arubas, but it has default settings that, when it is in
an Aruba network with certain configuration settings (see “mDNS and AirGroup) send periodic
reports to the network’s AirWave server. This information can be viewed on the device detail
screen on AirWave, allowing improved troubleshooting.
Also note that, for the iOS version of AirO, an Aruba Clearpass server is required in order to
send reports to AirWave. This is because iOS does not allow an app to learn the true MAC
address of it’s device, and the MAC is the key AirWave uses to identify the device. Fortunately
the Clearpass team has a solution to this where an entry in AirGroup returns the device’s MAC
in the text field of a response for the “_clearpass._tcp.” service: AirO makes use of this existing
feature.
An example of the report on AirWave is shown below:
mDNS and AirGroup
When building an app for universal app stores at Google and Apple, we face a challenge in
discovering network-specific items such as the IP addresses of the AirWave and iPerf servers
referred to in this document. If we can’t hard-code such addresses in the app – and it’s not
possible unless they are always the same – every user will have to enter network-specific settings
after downloading the app. We make a special enterprise-specific app build, but then the
enterprise will need to have an internal app store, and to make a new build for every new version
of the app.
Our solution is to use mDNS, the mechanism behind Apple’s Bonjour. mDNS allows our app to
search with a “well-known” service name and receive a network-specific IP address and other
information, with a DNS-like capability called DNS-SD. Aruba already has a feature called
AirGroup that deals with mDNS, and we can use a static AirGroup entry to point the app to the
local IP address for each service.
There are two services currently defined for AirO:


The AirWave server. This is a service called “_airwave._tcp.” in mDNS terms. The
AirWave server entry also contains a text field “deviceid=<password>” where
<password> is the password for the shared “AMC” account named “client” on the
AirWave server used to report device data.
The iPerf server. This is a service called “_local-performance._tcp.” that points to the IP
address of the iPerf server.
When using AirO in conjunction with an Aruba network, identify the IP addresses of these
servers, then configure static AirGroup entries to map the well-known service names to local IP
addresses (and the AirWave password). Then the app as downloaded from the app store will be
able to discover and use these services. If desired, these learned values can be over-ridden using
the Settings screen. If AirGroup is not configured, and Settings are not entered on the app, the
iPerf and AirWave reporting functions will not work.
(The algorithm choosing from the Settings list of iPerf servers is described above. The
AirGroup-learned address, if present, is inserted after the top entry in the list and before the
second position, so it is possible to over-ride the learned value by using the first entry, or provide
a local back-stop by entering a value in the second or lower positions.)
Screenshots (AirO v13)
Appendix: iPerf configuration
iPerf was chosen as the bandwidth test tool for this app because it is widely used and understood,
and server code is available for all common platforms. But iPerf is not quite ideal for our
purposes. This appendix covers some issues and workarounds.
The client-side implementation is iPerf 2.0.5-2 (see below for the -2 patch). The command
syntax depends on settings for <server address>, the server address (either IP address or FQDN),
and <duration>:
iperf –c <server address> -r –i 2–t <duration>
A special option allows the user to change iPerf options. If the ‘duration’ setting starts with a ““, it will be interpreted as the command option string and added to the iperf exec verbatim.
Thus, if ‘duration’ is “-p 5010 –i 5 –t 55” the command executed will run without the –r option
as:
iperf –c <server address> -p 5010 –i 5 –t 55
In ‘normal’ –r mode, the app will run iPerf for <duration> seconds in upstream, then the server
changes to client mode and runs again <duration> seconds in downstream mode. When it does
this, it opens a new socket which can be blocked by client-side firewalls (the default receiving
port is 5001). The downstream test will not complete under these circumstances, but a figure for
upstream speedtest will be displayed.
Another issue is a bug in the most common version of iPerf, v2.0.5. The symptom is that when
the server switches to client mode for the second half of a bidirectional test, it will exit at the end
of the test. There is a patch for this bug. Compiled versions of 2.0.5-2 are available at
www.iperf.fr, or this simple patch can be applied to the source:
In file Client.cpp
void Client::Run( void ) {
char* readAt = mBuf;
#if HAVE_THREAD
+
/*
if ( !isUDP( mSettings ) ) {
RunTCP();
return;
}
+
*/
#endif
// Indicates if the stream is readable
In other words, comment out the code from “#if” to “#endif”.
Finally, iPerf servers have been known to crash from time to time. There is an available daemon
mode which may be restarted automatically, but we have not tested it. It is probably prudent to
write a script to spot when iPerf is not running, and restart it. Here is a simple Powershell
example for Windows:
# Starts num_copies of iperf in server mode in this case, and
# periodically checks how many copies are still alive every num_seconds, and
# restarts as needed to keep num_copies active iperfs.
# This is necessary because if -r or -d are invoked from the client,
# when the server goes into client mode it can stop at the end of the test.
# Also, when multiple clients access the same iperf server simultaneously
with the -r or -d options,
# the iperf instance can crash. On the server, this will popup the Windows
Error Report window
# which will sit waiting for keyboard input and hang the crashed program. So
disable WER by going
# to local group policy editor (run > edit group policy > administrative
templates > windows components
# > windows error reporting... there are several options, we had success with
'display error notification
# disabled', 'disable WER enabled', 'prevent display... enabled'.
# You can monitor with task manager > processes while one or two clients are
running in -r or -d mode
# to see iperfs closing and being restarted. There should always be
num_copies active.
$iperfargs = "-s"
$num_copies = 1
$num_seconds = 10
$b = 0
Start-Process -windowstyle Normal -WorkingDirectory "C:\Program Files\iperf2.0.5-2\" .\iperf.exe $iperfargs
while ($b -le 2) {
if ( ( Get-Process iperf | Measure-Object ).Count -le ($num_copies - 1)
) {
Start-Process -windowstyle Normal -WorkingDirectory "C:\Program
Files\iperf-2.0.5-2\" .\iperf.exe $iperfargs
Write-Host -NoNewline (Get-Date)
Write-Host -NoNewline " starting a new iPerf, new total "
Write-Host ((Get-Process iperf | Measure-Object ).Count)
}
Start-Sleep -s $num_seconds
}
And for Linux, a simple script to stop and re-start iPerf can be entered in a cron job. Most
admins will want to enhance this, for example to check iPerf is running before killing and restarting it…
#!/bin/bash
while:
do
echo “hello”
pkill –x iperf
sleep 5
pkill –x iperf
sleep 5
nohup iperf –s –t 10 &
sleep 5
done
Appendix: AirGroup configuration
Automatic server discovery requires these two static AirGroup entries:
airgroup service "static" enable
airgroup static mdns-record ptr "00:11:22:33:44:55" "_airwave._tcp"
"demo._airwave._tcp.local" "AirWave_IP"
airgroup static mdns-record srv "00:11:22:33:44:55" "
demo._airwave._tcp.local " 443 0 0 "demo-AMP-Server.local" "AirWave_IP"
airgroup static mdns-record a "00:11:22:33:44:55" "demo-AMP-Server.local"
"AirWave_IP" "AirWave_IP"
airgroup static mdns-record txt "00:11:22:33:44:55" "
demo._airwave._tcp.local " "deviceid=<password>" "AirWave_IP"
airgroup static mdns-record ptr "01:11:22:33:44:55" "_localperformance._tcp" "demo._local-performance._tcp.local" "<iPerf_IP>"
airgroup static mdns-record srv "01:11:22:33:44:55" "demo._localperformance._tcp.local" 5001 0 0 "demo-iperf-Server.local" "<iPerf_IP>"
airgroup static mdns-record a "01:11:22:33:44:55" "demo-iperf-Server.local"
"<iPerf_IP>" "<iPerf_IP>"
airgroup static mdns-record txt "01:11:22:33:44:55" "demo._localperformance._tcp.local" "deviceid=01:11:22:33:44:55" "<iPerf_IP>"
Where “AirWave_IP” is the IP address of the AMP server. And “<iPerf_IP>” is the IP address
of a server with iPerf v2.0.5 running in server mode.
The server names, ports and MAC addresses do not matter, so long as they are consistent. It’s
the service definitions and IP addresses that are important, and the text entry
“deviceid=<password>” for the AMC “client” account password.
Troubleshooting Guide
The AirO app is designed to work out-of-the box on download from the app store, but a number
of configurations must be in place to provide this zero-conf experience for the user. The
following is a brief troubleshooting guide if you don’t see reports displayed in AirWave.
i. If you had Settings entries for iPerf (in the top position) and AirWave values, you will need
to erase those values for auto-discovery to work (iPerf addresses below the top position
won’t matter.)
ii. If you have set up the local iperf server and the “_local-performance._tcp.” Airgroup entry to
point to it, you should see the IP address show up under “Wide Area Network”, “Server” if
the app can open a socket to that address, port 5001. If it’s not possible to connect to that
address port 5001 (which we have seen when the iPerf server isn’t running for whatever
reason), the app will probably fall back to the cloud server which is 54.201.159.31. If it
connects to the iPerf server, it will display ping/uplink/dnlink values on the AirO screen.
This is independent of Airwave AMP account. It’s worth getting this right before going on
to Airwave because for Airwave we need the password over AirGroup as well as the address.
iii. Once you have the iPerf working, check the Airwave AMC account is set up. The username
is “client”, the password should not matter but we are steering people towards
“client4AMC!” . If posts aren’t working, check this account is not disabled, it can happen
through login attempts with bad password.
iv. The AirGroup entry for the AMC account should be “_airwave._tcp.” And should point to
the IP address of the Airwave server. There’s code to add “https://” if you don’t put it in the
entry. In the txt entry, “deviceid=<password>” is required, and don’t forget to remove the
old txt entry.
v. If all else fails, you can over-ride in “Settings” like this:
a. For iPerf, enter an IP address in the top-most settings slot
b. For Airwave AMP account, enter “https://1.3.4.5” or whatever, near the bottom. You
need the “https://” here.
c. For Airwave AMP account, enter the “AMC client password” in the bottom-most box.
Example emailed csv file
The “email” button sends a csv file, example shown below (split to fit the screen):