As an increasing number of people rely on Wi-Fi connectivity for communication, collaboration and productivity, it is becoming more important to be able to detect and resolve Wi-Fi related issues. One way to detect such issues is to have monitoring probes placed in Wi-Fi enabled locations. These probes can simulate end-user clients by running tests against the network. That way potential problems can be uncovered.

Even though systems for this kind of monitoring already exist, they can quickly become expensive, even at a small scale, and may not be as flexible as one wishes. As a solution to this problem, UNINETT has been developing a Wi-Fi monitoring system based on ordinary Raspberry Pis and free, open-source software, which drastically reduces costs and makes it possible to modify the system to one's needs.

An overview of the system

In essence, our Wi-Fi probing system enables the transformation of ordinary Raspberry Pis (which are cheap, credit card sized computers) into measuring probes that run tests on the network at regular intervals. The system is split in two, with one part being the probe management software running on a central web server, and the other part being the custom Linux image running on the probes themselves, which includes a collection of test scripts and control programs.

While it's possible to both host and use the system for oneself, the idea is that an organisation like an NREN can host the web server, while the users of the system can, for instance, be sysadmins of national universities or the like.

Setting up a monitoring probe

In a nutshell, to set up a probe a user needs to:

1. Buy the required hardware (see more details on that below);
2. Register their Raspberry Pi and install the provided image;
3. Update the probe, and;
4. Move it to the desired location.

Additionally, a database must be set up if not using an existing database instance. More details are described in the methodology section below.

Benefits over existing solutions

So what are the benefits of this system compared to existing ones like 7signal? The main benefits are cost and licensing (open source). While a commercial system can easily cost thousands of euros for setup and licensing fees, our system only requires the initial costs of buying the fairly cheap and generic hardware, which can be bought for under EUR 100. A database also has to be hosted, but this can be done with fairly low costs.

Because the whole system is open source, it can also be changed if desired. This can be changes to the system itself, but also stuff like adding new tests or changing existing ones, or adding support for new databases.

Methodology

To set up a probe, a user needs to first buy the required hardware, which mainly consists of a Raspberry Pi and a Wi-Fi dongle, in addition to peripherals like an SD card, a power cable and an Ethernet cable. The user can then log in to the web interface and register their probe, which consists of adding the MAC address of the Wi-Fi dongle, giving a name to the probe and specifying the credentials of the network the probe will run tests against. Information about the database where the probe should send data to must also be specified.

Figure 1: Screenshot of the website interface, with two probes already registered.

The required Linux image can then be downloaded from the website and installed on the SD card. When the Raspberry Pi is booted up for the first time with the new image, it will automatically attempt to identify itself with the web server via an Ethernet connection, using the MAC address of the Wi-Fi dongle for identification. If successful, it will set up a persistent reverse SSH connection to the server (more on this later).

When the Raspberry Pi has been identified and a connection set up, the user can press a button in the web interface to begin updating the Raspberry Pi. The installed Linux image only contains the bare minimum required to initiate a connection to the server, to keep it as generic as possible. As such, it does not yet contain any test scripts or control programs. Updating the Raspberry Pi will install additional programs required for performing tests, transfer the test scripts to be run in addition to a control program for running the scripts and reporting results back, and any additional configuration deemed necessary. Decoupling the image and the monitoring software makes the solution more flexible, as the image doesn't have to be regenerated at each minor change, and the scripts can be updated after the initial installation.

The updating itself is done by Ansible via the SSH tunnel established earlier by the probe, using a custom Ansible playbook. By piggybacking on the reverse SSH connection like this, we avoid the issue of the server not being able to reach probes behind NAT.

After Ansible has done its thing, the probe can be powered off and moved to the desired location, where it will automatically begin probing the network when booted up. The test results will then be sent to the previously specified database.

The system relies on the use of an external database and visualisation software, so in theory whatever preferred system can be used. In practice though, the control program running on the probe must know the data format the database expects, so some code changes are required for new databases. Currently, Elasticsearch and InfluxDB are supported. To make it easier to begin using the system for new users, UNINETT has also been giving users the option to send data from the probes to an Elasticsearch instance set up by UNINETT, and access to the corresponding Kibana dashboard.

Figure 2: Screenshot of UNINETT's Kibana dashboard, visualising data from a particular probe.

What's missing?

We still consider the system to be in a pilot phase, so there are some features missing. An example is that there's no provided feature to get alerts based on certain events, but as the system is mainly centred around managing probes rather than analysing data, this task can potentially be delegated to the database or other data analysis software.

The system has also mostly been tested within UNINETT's network and by UNINETT, and have some UNINETT dependencies that should ideally be removed. This situation will hopefully improve when other organisations take the system into use, and we see what has to be changed.

Conclusion

So to sum it all up: through the use of cheap Raspberry Pis and simple Wi-Fi adapters the hardware costs of the system remain low, and the software used is open source and free to use. Altogether, the system will allow more NRENs, campuses and other organisations to perform Wi-Fi monitoring on their premises.

If you're interested, you can check out the code on GitHub (Web interface & image generation, Ansible playbook & scripts) and a more technical documentation of the system.

This project was presented as a lightning talk at the TNC17 conference in Linz in May 2017.