The User Experience Insight sensor can be configured to test a maximum of 4 networks in total. This could be 4 SSIDs up to 1 SSID + 3 Ethernet networks if testing multiple ethernet VLANs. We have wired-only testing available for sensors here. You can contact the UXI support team to enable this feature at support@capenetworks.com.

The sensor will connect to a network and run Core Tests followed by the Internal and External tests configured for that network. The sensor will only run one test at a time, but the testing process is continuous and runs in a round-robin fashion as illustrated below.

Core network tests check the network environment, network services, and external connectivity. 

These tests include:

  • AP Scan: Examines the Wi-Fi environment around the sensor and collects BSSIDs, RSSI values, channel information, and related information 

  • SSID Check: Checks whether the configured SSIDs on the sensor are available in the Wi-Fi environment 

  • AP Association: Determines if the sensor can and how long it takes to associate with the configured SSID/access point

  • Allocate IP: Tests if the sensor is able to obtain an IP address using DHCP (skipped if a static IP address is configured)

  • Gateway: Tests if the provided (DHCP) or configured (static) gateway is reachable by the sensor

  • Primary DNS: Tests if the primary nameserver is able to resolve cdn.capenetworks.io

  • Secondary DNS: Tests if the secondary nameserver is able to resolve cdn.capenetworks.io

  • External Connectivity: Checks if the sensor can connect to http://cdn.capenetworks.io/auth (confirms if the sensor has external connectivity)

Once all the core tests have been successfully completed, the sensor will run the internal and external tests that have been configured for the network.  See the following articles for information on the available predefined tests and custom test templates that can be configured.

When all the tests have been completed for a network, the sensor will release the IP address if it was obtained from DHCP and de-authenticate from the network, and move on to the next network to test.

Tests such as YouTube, Dropbox, Netflix, and iPerf can be configured to run at predefined frequencies. During the sensor test cycle, the sensor will determine if it has to run these tests based on how long it has been since the last time these tests were executed.

When an error is encountered with a test, the sensor will automatically attempt to triage the issue by repeating the sequence of procedures leading up to the test failure. This can help you drill down to the step where the issue occurred. This triage process happens in sequence with the test cycle and will, therefore, delay further testing until it has completed its analysis.

When the sensor is doing any test for the first time, it will check Ethernet then Wi-Fi, and LTE network. Hence sometimes in triage, we will see the sensor is performing the test on a wired interface whether wired is configured or not.


A test cycle duration on the sensor or agent depends on the number of internal and external tests configured on it and the number of ongoing issues happening on it. The best way to see this time is to select the last hour in the timeframe and hover over into WiFi metrics test results to check the test cycle duration and the time gap between the two tests.

For an agent, the test cycle delay is 5 mins that means it waits for 5 mins after the completion of the previous cycle before starting the next one.

Did this answer your question?