Probing Tools Troubleshooting
The Probing Tools are designed to help verify connectivity, diagnose network issues, and ensure that configurations applied from the cloud are correctly reflected on the device. They provide automated tests such as Ping, TCP ping, and HTTP/HTTPS connectivity checks, and generate detailed reports for each task.
These tools are especially useful when:
- A probing task assigned from the cloud does not work as expected or fails to report.
- A probing tool report shows connectivity failure for a specific target.
- You need to confirm that the configuration applied to the device matches the configuration stored in the cloud.
For a complete reference on Probing Tools, please see the official documentation: Probing Tools Reference Guide
When to use these tools?
- When a probing task assigned from the cloud does not work as expected or does not report.
- When a probing tool report shows connectivity failure for a specific target.
- To verify that the configuration applied to the device matches the configuration in the cloud.
Troubleshooting steps
- Cloud
- UCI
- Run-Time
- Testing
Cloud Configuration Verification
This section details how to check the Probing Tool configurations made and applied from the cloud.
Access the CE Terminal
Follow these steps to gain access to the CE device via the Command Line Interface.
sudo su -
The sudo su - command starts a shell session with superuser privileges, enabling execution of tasks that require elevated permissions.
Verify the Last Applied Configuration
This command is used to view the details of the last successfully applied Probing Tool configuration from the stored response JSON file. The jq filter focuses on the networkDiagnosticsConfig section.
cat /tmp/last_config_response.json | jq .networkDiagnosticsConfig
This example output shows the last configuration done on diagnostics.
Example Response:
{
"taskId": "427665448e1f4ed6a7a511d285dd357b",
"taskName": "test1",
"sourceInterface": "eth0",
"sourceIPAddress": "192.168.1.105",
"templateId": "691ef0e83f1f4a667e0f750f",
"taskCycle": "daily",
"remark": null,
"taskDateTime": "2025-11-29T00:00:00.000+00:00",
"template": {
"id": "691ef0e83f1f4a667e0f750f",
"templateName": "test",
"targets": [
{
"value": "1.1.1.1",
"tests": [
{
"testType": "ping",
"ports": []
},
{
"testType": "tcpping",
"ports": [
80
]
}
]
}
],
"remark": null
}
},
{
"taskId": "c4c9ad35047a4495a17d5f472607b2bf",
"taskName": "test1",
"sourceInterface": "eth0",
"sourceIPAddress": "172.20.10.5",
"templateId": "691ef0e83f1f4a667e0f750f",
"taskCycle": "daily",
"remark": null,
"taskDateTime": "2025-11-28T20:25:00.000+00:00",
"template": {
"id": "691ef0e83f1f4a667e0f750f",
"templateName": "test",
"targets": [
{
"value": "1.1.1.1",
"tests": [
{
"testType": "ping",
"ports": []
},
{
"testType": "tcpping",
"ports": [
80
]
}
]
}
],
"remark": null
}
}
Verify the Last Probing Tool Report
This command is used to view the last execution report for a specific task (e.g., test1). Replace test1 with the actual taskName if needed.
cat last_probing_tool_report_test1_request.json | jq
Example Response:
{
"deviceId": "69257f24b2a73a153e4f8edf",
"deviceType": "CE",
"startedAt": "2025-12-01T11:50:00",
"taskId": "3f32bb726a2a46ee95c5bde183ebd905",
"taskName": "test1",
"targets": [
{
"value": "1.1.1.1",
"tests": [
{
"testType": "ping",
"executedAt": "2025-12-01T11:50:00",
"result": {
"output": "PING 1.1.1.1 (1.1.1.1): 56 data bytes\n64 bytes from 1.1.1.1: seq=0 ttl=53 time=74.582 ms\n\n--- 1.1.1.1 ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss\nround-trip min/avg/max = 74.582/74.582/74.582 ms",
"status": "success"
}
},
{
"testType": "tcpping",
"executedAt": "2025-12-01T11:50:00",
"port": 80,
"result": {
"output": "TCP PING 1.1.1.1 (1.1.1.1) tcp port 80\nBinding source interface: eth0\n1.1.1.1: seq=1 time=279.042 ms\n--- 1.1.1.1 tcp ping statistics ---\n1 pings, 1 success, 0 failed, 0.0% loss, total run time: 279.449 ms\nrtt min/ave/max/range/jitter = 279.042/279.042/279.042/0.000/0.000 ms",
"status": "success"
}
}
]
}
],
"completedAt": "2025-12-01T11:50:00"
}
Q:1 How do I interpret the status field in test results?
The status field indicates the outcome of each probing test. Possible values: success → The test executed correctly, and connectivity was verified (e.g., ping reply received, TCP port open). failed → The test did not succeed, meaning connectivity issues, unreachable host, or blocked port. error → The test could not be executed due to misconfiguration or system-level problems. In the example provided, both ping and tcpping show "status": "success", confirming that the target (1.1.1.1) is reachable and responding as expected.
Q:2 What information is shown under targets?
The targets section provides details about the specific endpoints being tested: value → The target IP address or domain name (e.g., 1.1.1.1). tests → A list of diagnostic tests performed on the target, including: testType → The type of test (e.g., ping, tcpping, http, https). executedAt → Timestamp when the test was run. port (for TCP/HTTP/HTTPS tests) → The port number being checked (e.g., 80). result → Contains detailed output of the test (response times, packet loss, RTT statistics) and the status field showing success or failure. This section essentially maps which targets were tested, how they were tested, and what the results were, making it the core of the probing report.
UCI Configuration Verification
This section focuses on verifying the Probing Tool configuration stored in the UCI system.
Verify Probing Tool Configuration Details
Check the Probing Tool configuration using the Unified Configuration Interface.
uci show probing_tool
Example Response
probing_tool.427665448e1f4ed6a7a511d285dd357b=task
probing_tool.427665448e1f4ed6a7a511d285dd357b.schedule='00 00 * * *'
probing_tool.427665448e1f4ed6a7a511d285dd357b.time='2025-11-29T00:00'
probing_tool.427665448e1f4ed6a7a511d285dd357b.template='691ef0e83f1f4a667e0f750f'
probing_tool.427665448e1f4ed6a7a511d285dd357b.task_name='test1'
probing_tool.427665448e1f4ed6a7a511d285dd357b.src_ip='192.168.1.105'
probing_tool.427665448e1f4ed6a7a511d285dd357b.interface='eth0'
probing_tool.691ef0e83f1f4a667e0f750f=template
probing_tool.691ef0e83f1f4a667e0f750f.name='test'
probing_tool.691ef0e83f1f4a667e0f750f.targets='1_1_1_1_691ef0e83f1f4a667e0f750f'
probing_tool.1_1_1_1_691ef0e83f1f4a667e0f750f=target
probing_tool.1_1_1_1_691ef0e83f1f4a667e0f750f.target='1.1.1.1'
probing_tool.1_1_1_1_691ef0e83f1f4a667e0f750f.ping='1'
probing_tool.1_1_1_1_691ef0e83f1f4a667e0f750f.tcpping='80'
Run-Time Configuration Verification
Run the following command to check the scheduled tasks for the Probing Tool in the system's cron table.
Check Scheduled Tasks
crontab -l
The lines containing run_probing_tool_task.sh correspond to the scheduled Probing Tool tasks.
00 01 * * * /usr/bin/upload_logs.sh
00 00 * * * /usr/bin/run_probing_tool_task.sh 427665448e1f4ed6a7a511d285dd357b
25 20 * * * /usr/bin/run_probing_tool_task.sh c4c9ad35047a4495a17d5f472607b2bf
Q:1 Can multiple probing tasks be scheduled?
Yes, multiple probing tasks can be scheduled simultaneously. Each task is represented by a separate line in the cron table, with its own task ID and execution time. Example: 00 00 * * * /usr/bin/run_probing_tool_task.sh 427665448e1f4ed6a7a511d285dd357b, 25 20 * * * /usr/bin/run_probing_tool_task.sh c4c9ad35047a4495a17d5f472607b2bf, The first task runs daily at 00:00 (midnight). The second task runs daily at 20:25 (8:25 PM). This allows administrators to schedule different probing tasks for different times, ensuring continuous monitoring and diagnostics across multiple targets.
Test Verification
Use these commands for manual verification of connectivity, mirroring the functions of the Probing Tool.
TCP Port Test
To check if a specific TCP port is open and reachable on a target, use tcpping
tcpping -c 1 <ip/domain> <port>
Example:
tcpping -c 80 1.1.1.1
Example Output:
TCP PING 1.1.1.1 (1.1.1.1) tcp port 443
1.1.1.1: seq=1 time=54.827 ms
1.1.1.1: seq=2 time=73.118 ms
1.1.1.1: seq=3 time=67.356 ms
1.1.1.1: seq=4 time=65.772 ms
1.1.1.1: seq=5 time=58.242 ms
1.1.1.1: seq=6 time=67.877 ms
1.1.1.1: seq=7 time=76.468 ms
1.1.1.1: seq=8 time=64.737 ms
1.1.1.1: seq=9 time=61.158 ms
1.1.1.1: seq=10 time=74.858 ms
1.1.1.1: seq=11 time=61.892 ms
1.1.1.1: seq=12 time=64.625 ms
HTTP Host Test
To check HTTP connectivity (e.g., to a web server on port 80).
httping -c 1 -p 80 <ip/domain>
Example:
httping -c 1 -p 80 1.1.1.1
Example Output:
PING 1.1.1.1:80 (/):
connected to 1.1.1.1:80 (218 bytes), seq=0 time=149.36 ms
--- http://1.1.1.1/ ping statistics ---
1 connects, 1 ok, 0.00% failed, time 1150ms
round-trip min/avg/max = 149.4/149.4/149.4 ms
HTTPS Host Test
To check HTTPS connectivity, often involving SSL/TLS negotiation.
httping -l -c 1 -p 443 <ip/domain>
Example:
httping -l -c 1 -p 443 1.1.1.1
Example Output:
PING 1.1.1.1:443 (/):
connected to 1.1.1.1:443 (491 bytes), seq=0 time=265.22 ms
--- https://1.1.1.1/ ping statistics ---
1 connects, 1 ok, 0.00% failed, time 1270ms
round-trip min/avg/max = 265.2/265.2/265.2 ms
Standard Ping Test
To check basic ICMP connectivity (Layer 3 reachability).
ping -c 1 ip
Example:
ping -c 1 8.8.8.8
Example Output:
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=117 time=1.222 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.222/1.222/1.222 ms
Q:1 Why use port 443 for HTTPS testing?
Port 443 is the default port for HTTPS traffic, which includes SSL/TLS encryption. Testing connectivity on port 443 ensures that: The device can establish secure connections to web servers. SSL/TLS negotiation is successful. Firewalls or security policies are not blocking encrypted traffic. This is critical for verifying secure communication paths, especially when applications or services require HTTPS.
Q:2 Why is HTTPS latency usually higher than HTTP?
HTTPS involves additional steps compared to HTTP: SSL/TLS handshake – Establishing encryption requires key exchange and certificate validation. Encryption/Decryption overhead – Data packets are encrypted before sending and decrypted upon receipt. These processes add extra milliseconds to the round-trip time. As a result, HTTPS latency is typically higher than HTTP, even when both use the same server and network path.