User Experience Insight (UXI) helps you understand and baseline the performance of large, distributed networks, allowing you to identify and troubleshoot problems before users complain. UXI sensors provide insights from an end-user perspective, giving you a starting point for where to investigate issues.
This document explains how the sensor arrived at a conclusion and outlines the steps you should take to troubleshoot further. It covers only the most frequently asked questions.
Note: You do not need to read every section; simply search the page for the specific error of interest.
Sensor connectivity
The "Status" section of the sensor status page displays "Offline".
Troubleshooting Guidelines:
The term "Offline" also means "No Data" because the UXI cloud has not received any data, test results, or events from the sensor.
When you first power on the sensor, it will:
Report to the UXI cloud.
Download and install the latest software update.
Download the required configuration to connect to the network.
Begin testing and reporting results.
This process usually takes 15 minutes but can take up to 45 minutes or more, depending on the connection speed. Once completed, the status light will reflect the sensor status.
The status light descriptions for G-series sensors can be found here.
A steady white light or flashing white light means the device is operating well.
If the status light/LED is orange, it indicates no connectivity to the UXI cloud through any of its configured or available networks. The device will appear offline on the dashboard when the status light/LED is orange.
F-series sensors and G-series sensors with cellular are shipped with pre-provisioned Twilio SIM cards activated and ready to go. However, even if the sensor has cellular capability, it does not guarantee good cellular coverage.
Generally, for each location where you have sensors, it's advisable to have additional onboarding options, such as using an unrestricted Ethernet port, the UXI onboarding app for G-series sensors, or Wi-Fi Easy Connect for G6 sensors. Please see the following document for more information on required reachable URLs for the sensor to function: Required Reachable URLs.
For sensor models without cellular, you will need to onboard the sensors using an unrestricted Ethernet port, the UXI onboarding app for G-series sensors, or Wi-Fi Easy Connect for G6 sensors. Please see the document for more information on required reachable URLs for the sensor to function: Required Reachable URLs.
Note: Sensors without cellular do not send power outage notifications when unplugged or powered off.
Verify the correct sensor is added to the dashboard (sometimes the serial numbers can look very similar to one another).
Identify the sensor status LED color using our Status LED Guide.
If the LED indicates no connectivity, plug the sensor into an unrestricted Ethernet port and ensure the connection is stable.
Make sure the required URLs are accessible: Required Reachable URLs.
Power cycle if necessary. Wait for the status light/LED to go out completely before powering on again. Power the sensor using PoE or the power supply, not both.
G-series only: Optionally use the onboarding app for Android. This will provision the sensor over Bluetooth and display sensor connectivity issues: UXI iOS App.
G6 sensors only: You can optionally use Wi-Fi Easy Connect to onboard your sensors. See all the requirements for Wi-Fi Easy Connect here: Wi-Fi Easy Connect Sensor Onboarding.
G-series only: Factory reset if necessary: How to Factory Reset G5-Series Sensors.
The "Status" section of the sensor status page displays “Offline” intermittently or for a period of time.
The term "Offline" also means "No Data" because the UXI cloud has not received data from the sensor.
When fully zoomed in, any gap in test result data of 10 minutes or more will result in these gaps on the status graph. These gaps do not indicate a sensor error.
The most common reasons for gaps in the status chart:
The sensor spends a lot of time in triage mode, troubleshooting issues on another configured SSID/network.
There are many tests and networks configured, and it takes longer than 10 minutes for the sensor to complete a test cycle.
The sensor was powered off, but the sensor model does not have cellular, or cellular coverage is not good where the sensor is positioned, resulting in no power outage notification being received by the UXI cloud.
The sensor test cycle is described here: User Experience Insight Sensor Test Cycle.
When the sensor runs a test and the test fails, the sensor enters triage mode to find the root cause (network versus application issue). In an example like the one shown, there is no data for parts of the Status graph, likely because the sensor is spending time doing triage on another network.
To eliminate the gaps in the status chart:
Fix the issues on the other networks.
Fix the issues with the sensor configuration.
Reduce the number of tests.
Cellular Connectivity
Sensors that are cellular-capable and have a valid cellular subscription come pre-provisioned with a Twilio SIM, with no activation required.
Cellular connectivity is primarily used to simplify initial onboarding or to communicate with our cloud when the local network loses connectivity to the UXI cloud. The sensor uses its configured Ethernet or Wi-Fi connection to communicate with the UXI cloud first, but if communication fails, it will leverage the cellular connection. The list of connectivity URLs can be found here: Required Reachable URLs.
If the sensor is unable to communicate with the UXI cloud and reach these URLs over Ethernet or Wi-Fi, the sensor can still report issue notifications and receive configuration updates out-of-band via the cellular link. Note that packet captures and screenshots for failed captive portals are not uploaded via the cellular link. Only cellular-enabled sensors are capable of reporting power outages.
Although cellular may be enabled on the device, coverage depends on agreements between Twilio and the mobile service provider, as well as the physical surroundings of the device. When deploying the sensors, it’s best to have, as a backup option, an unrestricted Ethernet port available. G-series sensors can use the onboarding Bluetooth app for Android to get the initial configuration, or G6 sensors can also use Wi-Fi Easy Connect. If using cellular for onboarding, it can take up to an hour for the sensor to get the initial configuration.
Note: Sensors without cellular do not send power outage notifications when they are unplugged or powered off.
Packet Capture Upload In Triage
The following help article describes the sensor packet capture: How Does Packet Capture Work.
There are two common reasons why a pcap might not be available in the triage menu:
The issue has been ongoing for over 30 days, and the sensor pcap mode is set to pcap light, whereby only a packet capture from the initial failure is uploaded.
The sensor does not have connectivity to the UXI cloud. (Note: neither PCAPs nor captive portal failure screens are uploaded via cellular).
To resolve the first issue:
Change the sensor PCAP mode from PCAP light to PCAP full.
PCAP light is the default mode and will only upload a PCAP file when an issue is first discovered.
In PCAP full mode, a PCAP is uploaded every subsequent time the issue is discovered.
The downside of PCAP full mode is that it will use significantly more bandwidth to continuously upload these PCAP files. Therefore, it’s recommended to only use PCAP full mode for a short time.
To resolve the second issue:
Ensure the sensor is connected to a network that can reach the UXI cloud.
Remember, packet captures are not uploaded via cellular.
Wi-Fi
Common Questions | Help Article |
What’s the difference between RSSI seen in the Wi-Fi Environment versus measured in the Wi-Fi section? | |
How is receive bitrate determined? | |
How does the sensor choose which BSSID to connect to? | |
How do I lock the sensor to a specific BSSID? |
Wi-Fi Association
“The Wi-Fi SSID is missing”
The sensor periodically performs a Wi-Fi scan and reports the results in the 'Wireless Environment' section of the sensor status page. When the sensor attempts to connect to a configured wireless network, it checks if the SSID is present in the 'Wireless Environment' scan. If the sensor reports “The Wi-Fi SSID is missing,” this indicates the SSID was not detected in the scan.
On F-series sensors, the packet capture (PCAP) will not be useful for identifying the problem, as probe requests and responses are not captured.
On G-series sensors, an on-demand PCAP should show the results of the probe requests and responses.
One possible solution is to set the SSID to hidden in the configuration in the UXI dashboard (even if the SSID is not hidden). This will allow the sensor to attempt to connect without relying on the Wi-Fi scan.
“The Wi-Fi SSID is present but is missing in the band you configured”
The sensor periodically performs a Wi-Fi scan and reports the results in the 'Wireless Environment' section of the sensor status page. When the sensor attempts to connect to a configured wireless network, it checks if the SSID is present in the 'Wireless Environment' scan. If the sensor reports “The Wi-Fi SSID is missing in band,” this indicates the sensor is configured to test only 2.4 GHz or 5 GHz for the network, and based on the wireless scan, the SSID is present but not in the configured band.
On F-series sensors, the PCAP will not be useful for identifying the problem, as probe requests and responses are not captured.
On G-series sensors, an on-demand PCAP should show the results of the probe requests and responses.
One possible solution is to set the SSID to hidden in the configuration in the UXI dashboard (even if the SSID is not hidden). This will allow the sensor to attempt to connect without relying on the Wi-Fi scan.
“Wi-Fi BSSID is missing”
The sensor periodically performs a Wi-Fi scan and reports the results in the 'Wireless Environment' section of the sensor status page. When the sensor attempts to connect to a configured wireless network, it checks if the SSID is present in the 'Wireless Environment' scan. If the sensor reports “The Wi-Fi BSSID is missing,” this indicates the sensor is locked to test only a specific BSSID, and based on the wireless scan, the BSSID is not present.
You can adjust the sensor configuration to remove the BSSID lock.
It’s possible the AP was rebooted, is down, or did not respond to the probe requests.
“The Wi-Fi BSSID is present but not broadcasting the configured SSID”
The sensor periodically performs a Wi-Fi scan and reports the results in the 'Wireless Environment' section of the sensor status page. When the sensor attempts to connect to a configured wireless network, it checks if the SSID is present in the 'Wireless Environment' scan. If the sensor reports “The Wi-Fi BSSID is present but not broadcasting the configured SSID,” this indicates the sensor is locked to test only a specific BSSID, and based on the wireless scan, the BSSID is part of a different SSID.
You can adjust the sensor configuration to remove the BSSID lock.
It’s possible the AP was rebooted or reconfigured, and the BSSIDs have changed.
“The case of the SSID is incorrect”
The sensor periodically performs a Wi-Fi scan and reports the results in the 'Wireless Environment' section of the sensor status page. When the sensor attempts to connect to a configured wireless network, it checks if the SSID is present in the 'Wireless Environment' scan. If the sensor reports “The case of the SSID is incorrect,” this indicates the SSID is present, but the SSID does not match the configured case.
You can verify this in the wireless environment scan.
This might also indicate that your network configuration is not consistent across various sites, and you should update your SSIDs to be uniform.
“Wi-Fi interface not associated to AP”
When the sensor runs a test and the test fails, it enters triage mode to determine the root cause of the failure. One of the first checks in triage is to ensure the sensor is associated with the network. If the sensor is no longer associated, the error “Wi-Fi interface not associated to AP” is shown.
This could be caused by factors such as roaming, the AP going down, the sensor being disconnected by the AP, or congestion in the RF environment.
This error is of warning severity and only concerning if it happens consistently.
“Wi-Fi association failed”
If the sensor is unable to associate with the network, it will report “Wi-Fi association failed.” This error code is often presented along with other error codes. For example, if there is also an error code that says “The Wi-Fi SSID is missing” and another that says “Wi-Fi association failed,” the root cause is likely “The Wi-Fi SSID is missing.”
If the “Wi-Fi association failed” issue occurs intermittently on its own, it may be due to RF interference.
If the issue is persistent, it may be that the SSID is using a capability not supported by the sensors.
“Wi-Fi authentication failed”
If the sensor is unable to authenticate to the network, it will report “Wi-Fi authentication failed.” This error code is often presented along with other error codes. For example, if there is also an error code that says “The Wi-Fi pre-shared key is incorrect” and another that says “Wi-Fi authentication failed,” the root cause is likely “The Wi-Fi pre-shared key is incorrect.”
Double-check your network settings and re-enter the password if necessary.
802.1X Authentication
“802.1X authentication failed”
This error indicates that the sensor associated with the AP, but was rejected by the RADIUS server. A client does not have much information on why it was rejected by the RADIUS server. You will need to check the RADIUS server logs to find the detailed reason behind the failure. The most common reasons are invalid or expired credentials. You can download the triage packet capture (PCAP) to review the 802.1X request, server, and client exchange. Typically, you will be able to see the failure, but the exact reason behind the failure would be present in the RADIUS server logs.
In the case of a configured 802.1X Ethernet port, it’s possible that the actual switch port to which the sensor is connected may not be configured for 802.1X authentication.
“802.1X authentication timed out”
This error indicates that the sensor associated with the AP, but was unable to complete 802.1X authentication before 60 seconds elapsed. This may suggest that messages are not being properly forwarded to the RADIUS server. You will need to check the RADIUS server logs to determine the detailed reason behind the failure. When reviewing the triage PCAP, this error often shows a correct server and client certificate exchange. Afterward, the EAPOL 4-way handshake is initiated, but the initial EAPOL start packet is not responded to. In this case, the profile used by the sensor to authenticate is correct, but the RADIUS server is not responding to the 4-way handshake request.
“802.1X authentication failed with unknown CA”
The error “802.1X authentication failed with unknown CA” indicates that the sensor does not trust the RADIUS server and therefore did not attempt to connect. The best ways to establish trust are to embed the RADIUS server certificate in the #PKCS12 file or to specify the RADIUS server certificate chain in .pem format and upload it using the advanced option to specify the custom CA. You can refer to the guide here: Custom CA. You can also validate the required certificates from the sensor triage.
Ethernet
“Ethernet carrier is not present”
This error indicates that the sensor is configured to test Ethernet, but it does not detect any connection on the Ethernet interface.
On the switch, you can check the Ethernet port's admin and operational states as well as the duplex modes.
Verify the cable and ensure the sensor is plugged into the expected port.
You can also update the sensor configuration so that the sensor no longer tests Ethernet.
Static IP
You can set a static IP for a sensor in the sensor settings under the 'Configure' options when you add a network to a sensor. This option is available only for IPv4.
Note: The sensor does not have a dedicated management interface. It will communicate with the UXI cloud over any available connection (wired, wireless, or cellular).
If you want to configure a static IP on a wired connection, you need to create the wired network, add it to the sensor for testing, and assign a static IP in the same way as shown in the screenshot.
Unable to allocate static IP
This error indicates that the sensor was unable to set the static IP address. The reason is usually explained in the issue triage. To correct the issue, you will need to update your sensor configuration.
DHCP
In the UXI dashboard, DHCP response time is the total time from when the sensor starts trying to get a lease to when the sensor receives the lease. This time could include retries in case of failures/errors. The DHCP response time includes all initial DHCP discover packets which are potentially not responded to.
The sensor will do the full DORA process every time it joins a network. The sensor explicitly releases the IP when the sensor is finished testing the network by issuing a DHCP release packet before disassociating from the configured SSID (in the case of Wi-Fi testing).
"No response from DHCP server"
The sensor uses a Linux utility for DHCP, and this tool has an exponential backoff algorithm for retries when attempting to get a lease. If after a total of 60 seconds the sensor does not get a response, it is considered a DHCP failure with an error that says "No Response from DHCP Server."
You can confirm the DHCP issue in the issue triage and the attached PCAP. If the device is testing two or more SSIDs that share the same subnet, there may be a network isolation issue whereby the device's initial DHCP lease from the first network is not fully released (or the DHCP release packet is not received) by the time the device is associated with and testing the next network.
It is recommended to separate adjacent L3 networks with distinct routed L3 sub-groups rather than sharing L3 infrastructure between distinct SSIDs, especially when guest networks are involved.
In some cases, logs from the DHCP server will show the DHCP lease is being requested and issued to the sensor, but packet captures from the sensor could show that the DHCP offer is never being received by the device. In such a situation, an Over-The-Air packet capture is recommended to determine where the DHCP offer is being dropped (it could be dropped by a firewall policy somewhere else in the network infrastructure).
High DHCP Response Time
If the sensor can get an address via DHCP, but the time it takes is longer than the threshold set in the dashboard, the dashboard will report a warning or error message that says "High DHCP response time."
You can adjust these thresholds and set them to what is appropriate after measuring the network behavior for a week or more. Thresholds are a rolling average calculation per sensor, per network, and per test. It's recommended to adjust the threshold for the highest values based on your historical data and expand the time period if necessary.
To diagnose the root cause of DHCP issues, it’s usually recommended to request and examine an on-demand packet capture from the sensor status page. Once downloaded, the datagrams PCAP will show you which part of the DORA process is failing or taking a long time to complete.
You should compare the timestamps of the datagrams PCAP with the default PCAP to ensure you are looking at the DORA process when you are connected to a specific network.
High DHCP response times may be due to a misconfigured load balancer or broadcast messages not being forwarded correctly.
Gateway
"Gateway is unreachable"
After getting a lease from DHCP, the sensor checks if it can reach the gateway using ARP. If there is no response, the sensor will report the error "Gateway is unreachable." This usually indicates an L2 forwarding issue.
"No connectivity past gateway"
If the network is configured for external connectivity, the sensor will check if it has external connectivity by checking http://cdn.capenetworks.io/auth for an expected response code.
If the response differs from what is expected, then this issue is raised. The error "No connectivity past gateway" usually indicates there was a timeout reaching this URL. If the issue is transient, it may indicate an outage of your ISP. If the issue is persistent, it may indicate your network does not have internet connectivity.
In this case, you should update the network configuration in the UXI dashboard under the advanced settings and turn external connectivity to false. After updating this setting, it may take 90 minutes for this error to be resolved by the UXI cloud.
This error may also indicate the sensor is being blocked by a tool like Zscaler. For Zscaler, you will need to apply a bypass rule on your Zscaler instance for our required URLs.
“Connectivity URL resolution failure”
If the network is configured for external connectivity, the sensor will check if it has external connectivity by checking cdn.capenetworks.io/auth. The error “Connectivity URL resolution failure” usually indicates there was no DNS response for this URL. If the issue is transient, it may indicate an outage of your DNS.
If the issue is persistent, it may indicate your network does not have internet connectivity and therefore you should update the network configuration in the UXI dashboard under the advanced settings and turn external connectivity to false. After updating this setting, it may take 90 minutes for this error to be resolved by the UXI cloud.
DNS
The DNS test is described here. The DNS test is performed against the primary and secondary DNS servers. Primary and secondary are determined by the order of the nameservers returned in the DHCP lease.
"Primary DNS failing"
This error indicates the DNS test failed only for the primary DNS server. If the issue is transient, it may indicate a brief network or RF issue. If the issue is persistent, it indicates a network configuration issue. The error is only reported after a timeout of 60 seconds, which includes multiple attempts.
"Secondary DNS failing"
This error indicates the DNS test failed only for the secondary DNS server. If the issue is transient, it may indicate a brief network or RF issue. If the issue is persistent, it indicates a network configuration issue. The error is only reported after a timeout of 60 seconds, which includes multiple attempts.
"DNS resolution is failing"
This error indicates the DNS test failed for the primary and secondary DNS servers. This error also indicates DNS also fails when no specific DNS server is specified. If the issue is transient, it may indicate a brief network or RF issue. If the issue is persistent, it indicates a network issue.
"Unable to resolve hostname"
This error indicates the DNS server was reachable, but the server did not provide a resolution. You can view the response in the issue triage. You will likely see no answers to the query. This indicates a DNS server issue. Take note of the nameserver that provided the response.
"High DNS lookup time"
This error indicates the DNS test is successful in under 60 seconds, but the result is higher than the threshold setting. You can update the threshold under settings > thresholds.
Thresholds are a rolling average calculation per sensor, per network, and per test. It's recommended to adjust the threshold for the highest values based on your historical data and expand the time period if necessary. If this issue is constant, you can also validate the DNS measurement by requesting an on-demand PCAP.
Captive Portal
Read the following article to learn how to record a captive portal: Captive Portal Setup.
To test if a captive portal is present, every test cycle the sensor will check if it can reach http://cdn.capenetworks.io/authand get "Success" in the result.
Note: This URL cannot be changed (even if you change the DNS lookup URL). The reason is this page has specific text for the sensor to get and parse to verify it successfully reached the URL. If a captive portal is present, the sensor should be redirected to a captive portal when it browses to this URL.
There are three possible outcomes:
The sensor can reach this URL and get "success" in the response. In this case, the sensor will continue with its test cycle. This may result in the captive portal pill on the dashboard not appearing at all, appearing grey, or captive portal test results appearing far apart. This is because the network has not prompted the sensor to test a captive portal, and therefore, the sensor was not required to run the captive portal script (maybe due to MAC caching from a previous test cycle).
If the sensor cannot reach this URL and a captive portal configuration is not assigned to the network, the sensor will report "Unexpected Captive Portal or Proxy." This error may also indicate the sensor is being blocked by a tool like Zscaler. For Zscaler, you will need to apply a bypass rule on your Zscaler instance for our required URLs.
If the sensor cannot reach this URL and a captive portal is assigned to the network, the sensor will run the captive portal test.
When a captive portal test is run, the first step is to load the captive portal webpage. The error "Captive portal landing page inaccessible" indicates the captive portal web page did not load. To diagnose the error, look at the datagrams PCAP to see what captive portal server responded to the request, then investigate the captive portal server or network issue.
Once the sensor loads the captive portal page, the sensor will begin to replay the captive portal script step-by-step. The error "Captive portal login failed" indicates the captive portal script did not complete successfully and failed at one of the configured steps. This can also happen if all the captive portal steps have been completed, but the sensor is redirected back to the initial login page. Triage indicates the step where the captive portal script is not working.
In addition, triage attempts to capture a screenshot of the issue. Screenshots are only available if the sensor can upload over wired or wireless. Screenshots are not uploaded over cellular.
If all steps were executed successfully but afterward the sensor was not able to reach http://cdn.capenetworks.io/auth, the sensor will report the error "No connectivity past captive portal."
The captive portal should only contain basic commands like click and type, and the credentials should be static and be able to be used by multiple sensors. You may need to create a service account specifically for the sensors to authenticate.
One common issue for captive portal issues is missing steps in the captive portal script. For example, a script may contain steps to enter a username and password, but there is still another button to click on the page the sensor was presented with that is not in the recording. Another possible situation is that the credentials used to authenticate to the captive portal have expired. So the sensor goes through all the steps correctly, but the login fails.
To troubleshoot these issues, it’s usually best to examine triage for where the test is failing and, if necessary, record the captive portal again using the steps outlined in the help article. It’s also advisable to clear the browser cache before making the recording.
If the sensor successfully runs the captive portal script, you may see a threshold warning that says "High Captive Portal Load Time."
This error indicates the sensor was able to successfully run the captive portal script, but the time taken to load the captive portal and complete the login was higher than the desired threshold. To resolve this error, update the captive portal thresholds. If the error is persistent, download an on-demand PCAP and examine the datagrams to see which captive portal server is taking longer to respond to the request.
Captive Portal on Ethernet
A captive portal can be assigned to a wired network. There are no known limitations (beyond the normal captive portal limitations). However, this has not been extensively tested. Captive portal recordings on Ethernet must also be recorded using the HPE Aruba Networking recorder Chrome plugin and can only be added by engineering via support.
Services & Applications
The internal or external test status is grey
If a test status is grey, it usually indicates "no data." There are many reasons why the test may not be running.
Check if the sensor has reported other test results. The sensor may have been powered off.
If a sensor is having trouble performing network tests such as association, authentication, DHCP, DNS, or captive portal, the sensor will not attempt to test the internal and external tests. You must resolve these issues before internal or external tests can be attempted.
Check the test type and whether the network has a proxy configured. If the test type is a generic test or a VOIP MOS test, the test is usually skipped. This is because these tests rely on ICMP and TCP ping, which are not typically possible through a proxy.
Check the test assignment. Tests are assigned per group and per network.
"Internal service is unavailable" or "External service is unavailable"
The "Service is unavailable" error message is often the result of a failed TCP or ICMP ping.
You can validate this in the issue triage.
If the issue is transient, this error may indicate an application issue.
If the issue is persistent, this error may indicate an application issue or that the test is misconfigured.
To troubleshoot:
Check your test target to make sure the URL or IP you entered is correct.
If testing a TCP port, ensure the port number in the test configuration is correct. Update the port if necessary.
If testing ICMP, ensure ICMP is not blocked on your network. Uncheck ICMP in the test configuration if necessary.
The test may be configured to run on a network where the test is not available. Check the network the test is running on and update the test configuration if necessary. Group and network selection is described here.
Check if the network has a proxy, but the proxy is missing from the UXI network configuration. Note that it’s usually not possible to run a ping through a proxy, but if you set the option to force ping in the network settings, the sensor will attempt to run it anyway.
"SSL Error"
When the sensor performs a webserver test and the option to validate the SSL certificate is enabled, the sensor will check that the SSL certificate returned is trusted and valid. If the certificate is not trusted or valid, an SSL error is returned. In the issue triage, the curl output can help you identify the specific reason for the SSL error.
If you have something on the network that performs SSL inspection/decryption, you can provide a trusted certificate to support. The preferred format is base64 encoded .pem, but if it's in another format, it can be converted. The certificate is assigned per network, so any sensor testing that network will use that certificate. Also note the URLs required for the sensor to reach the UXI cloud should not require SSL inspection: Which URLs Do I Need to Make Accessible for My Sensor to Function.
You can optionally adjust the webserver test template to disable SSL validation. After making this change, it may take up to 90 minutes for the SSL error to no longer be reported.
"HTTP timeout" or "HTTPS timeout"
This error indicates the sensor attempted to run an HTTP GET, but the request timed out after 25 seconds. You can validate the timeout in the issue triage and triage packet capture.
If this issue happens intermittently, it may be due to RF interference or other wireless factors. If the issue is persistent, double-check the test configuration URL. One possible reason for this issue is the application has determined the sensor is a bot and has decided not to respond to the request.
Consider applying the rate limit and frequency options to the test template, simplifying the test to check only TCP connectivity using the generic test template, or expanding the test to be a web-based interaction with web app testing.
"Unexpected HTTP status code" or "Unexpected HTTPS status code"
This error indicates the sensor attempted to run an HTTP GET, but the response was not HTTP response codes 200 or 204. You can validate the response code received in the issue triage.
Typically this issue is an application issue. If the issue is persistent, double-check the test configuration URL. You may also consider expanding the test to be a web-based interaction with web app testing.
"High packet loss," "High latency," or "High jitter"
These issues are examples of threshold issues. Thresholds are successful tests, but the results violate the threshold settings. Thresholds are a rolling average calculation per sensor, per network, and per test.
It's recommended to adjust the threshold for the highest values based on your historical data and expand the time period if necessary.
Latency, jitter, and packet loss are all measurements from ICMP or TCP Ping tests.
If these threshold issues happen across only one service, it may indicate an application issue. If this issue happens intermittently or across multiple applications, it may be due to RF interference or other wireless factors.
To troubleshoot persistent threshold issues, double-check your test configuration. If testing multiple TCP ports, make sure all the port numbers in the test template are correct. If the issue is ongoing, you can also request an on-demand packet capture from the sensor to validate the issue.
"Low internal VoIP MOS" or "Low external VoIP MOS"
The following documents describe the VoIP MOS test template:
These issues are examples of threshold issues. Thresholds are successful tests, but the results violate the threshold settings. Thresholds are a rolling average calculation per sensor, per network, and per test. It's recommended to adjust the threshold for the values based on your historical data and expand the time period if necessary.
The VoIP MOS results range from 1 to 4.4 and are calculated from the average latency, jitter, and packet loss of TCP packets tagged with the appropriate DSCP/TOS values for voice. The formula used is based on ITU-T Recommendation G.107.
If this issue happens intermittently or across multiple applications, it may be due to RF interference or other wireless factors. To troubleshoot persistent threshold issues, double-check your test configuration. If the issue is ongoing, you can also request an on-demand packet capture from the sensor to validate the issue.