The monitoring system emulates a wireless device connecting to a wireless network called "eduroam" and authenticates using EAP as a normal client device would. The EAP method (TTLS, PEAP) and phase two authentication (PAP, MSCHAPv2) parameters are as supplied with the test account.
The tests are implemented using a modified version of CESNET's rad_eap_test, which in turn makes use of wpa_supplicant's eapol_test utility to do EAP negotiation. This is the same supplicant that Ubuntu (and other Linux operating systems) use for wireless authentication, and so this test emulates a Linux box connecting to the eduroam wireless network.
Each test is performed twice, once via each of the two national roaming servers. This is to ensure consistent responses from both servers, which normally operate in a load-balancing configuration.
To make it easier for you to find the monitoring system's attempts in your log files, the RADIUS packets contain the following parameters:
NAS-IP-Address: 155.232.92.18
Calling-Station-Id: 22-44-66-00-5A-41
Connect-Info: 0/0 https://monitor.eduroam.ac.za/
Operator-Name: 1eduroam.ac.za
The monitoring system is configured to try and authenticate approximately once every 15 minutes via both national roaming servers. This means when everything is working properly you should see about eight authentication requests per hour.
When authentication first fails for a particular realm, the monitoring system will attempt to determine whether this is a transient problem or a more sustained one. It does this by attempting to log in three times at two-minute intervals before reverting to its normal scheduling. You can read about how this works in naemon's documentation.
The test account information supplied via this website is loaded into the monitoring system via a cron job that runs once an hour during normal working hours (7AM-5PM, Monday-Friday). It is not retried in the event of failure, meaning that it is possible that an update might take several hours to propagate if there are underlying problems.
If your test account details are more complicated than the management page supports, please let us know. We can create manual configurations for more complex scenarios, at the expense of your losing the ability to maintain them in future.
The monitoring system also loads contact details from the database and generates contact objects from them. This allows the monitoring system to send courtesy notifications to the contacts if/when their realm becomes unreachable for an extended period. These are configured to only be sent infrequently (approximately once per week) so as not to be too onerous during extended outages. However, you may get multiple notifications if your RADIUS server responds inconsistently and intermittently sends an Access-Accept.
The monitoring system is an experimental service that may never become a production service. As such, whilst we will endeavour to ensure it's operating correctly, it is not formally supported. Instead, this system is provided as a courtesy to help improve the user experience and as a (hopefully) useful diagnostic tool to aid debugging. It exists as an adjunct to other monitoring.
You should not rely on this monitoring or the notifications it provides to the exclusion of your own monitoring — responsibility for the correct operation of an identity provider always rests with the institution.