[SOLVED] Telemetry widget fails to load after upgrade from 25.7 to 26.1.6

[UserRory]

After upgrading the telemetry widget fails to load.

The backend log has this message:
2026-04-12T06:35:20-07:00 Error configd.py Timeout (120) executing : proofpoint et status

If I log into the console shell and execute the sensor_info.py script manually, it will succeed, but it is takeing 2 minutes and 30 secons - longer than the indicated 120 second timeout.

Script ouptput indicates sensor_status is "active" and the final script status is "okay"

[UserRory]

Ended up reverting back to 25.7

Note that the same sensor_info.py script executes in 2 seconds on 25.7; I believe the python environment was updated as part of the upgrade; perhaps this has something to do with the issue?

[UserRory]

Had some time to test more - as nice as 26.1 is it is just a bit too early for me.

1) Firewall rule migration tool failed with some of my rules
2) Suricata IPS showing 1 CPU @ 100% utilization
3) Telemetry widget fails to load / sensor_info.py timeout issue (reproducible on 26.1.2 - 26.1.6)
4) Scheduled firewall rules not working (known issue)

If I have time I might try to do a clean install and restore config to see if that behaves any better. Wondering if others had better luck vs upgrade.

[UserRory]

Solved the issue.

As noted, the sensor_info.py script did succeed, but took 2 minutes 30 seconds to execute, which exceeded the 120 second timeout.

Running the script as "python3 -m trace --trace ./sensor_info.py" showed that the culprit was:

connection.py line 73 sock.connect(sa), which paused for 2 minutes and 30 seconds before succeeding.

This indicated to me that it was likely that the script was first trying to connect with IPv6, timing out, and reverting to IPv4.

I do not run IPv6 on my internal networks, so I found the (new?) setting under system>settings>general to "prefer IPv4 over IPv6" when both are present.

Note that m ISP supports both IPv4 and IPv6, so apparently the fact that the WAN interface had an IPv6 address, even though the LAN interface did not configure IPv4 was enough for the software to consider IPv6 was configured and to try to use that address.

Selecting "prefer IPv4 over IPv6" solved the issue.