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?

Show the user the data sent to Airwave, with simple quality indications. Buttons for ‘report trouble’ and ‘diagnostic help’

Discover AirWave & other servers, send AMC reports & receive updates

Enterprise iPerf Server

Cloud iPerf Server

AirWave Server

AP / controller

LAN / WAN

Internet

“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 dBmo When standing underneath a ceiling-mounted access point, perhaps -40dBmo A ‘good’ signal is better than -68dBmo The signal will be problematic below -75dBmo 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+ Mbpso An 802.11n device might reach 65 Mbps or 130 Mbps with 40 MHz channelso Under normal conditions a link faster than 20 Mbps is very goodo 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 widelyo With good conditions, a stable delay of less than 20 msec is expectedo If ping times are consistently over 100 msec, application performance will suffero 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:

AP / controller Ping and iPerf to “WAN” iPerf server or cloud iPerf server

Ping default gateway

Enterprise iPerf Server

Cloud iPerf Server

AirWave Server

Internet

LAN / WANReport to AirWave default

Blue buttonsThe 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.

SettingsSettings 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 isiperf –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 ReportingThe 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 AirGroupWhen 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 configurationiPerf 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 = 0Start-Process -windowstyle Normal -WorkingDirectory "C:\Program Files\iperf-2.0.5-2\" .\iperf.exe $iperfargswhile ($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 re-starting it…

#!/bin/bash

while:doecho “hello”pkill –x iperfsleep 5pkill –x iperfsleep 5nohup iperf –s –t 10 &sleep 5done

Appendix: AirGroup configurationAutomatic 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" "_local-performance._tcp" "demo._local-performance._tcp.local" "<iPerf_IP>"airgroup static mdns-record srv "01:11:22:33:44:55" "demo._local-performance._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._local-performance._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 GuideThe 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 slotb. 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 fileThe “email” button sends a csv file, example shown below (split to fit the screen):