[SOLVED] security/etpro-telemetry: sensor_info.py timeout prevents telemetry widget from loading after 26.1.6 upgrade

[rory-tester]

After upgrading from 25.7.11 to 26.1.6, the dashboard fails to load the telemetry widget.

Backend Log files show: Timeout(120) executing : proof point et status

Note that if you log in to the console shell and execute the script /usr/local/opnsense/scripts/etpro_telemetry/sensor_info.py directly, it will run successfully and show status "ok", however timing the script execution shows that it takes 2 minutes and 31 seconds

OPNsense 26.1.6 (amd64).
Intel® Atom™ C3758 @ 2.20 GHz (6 cores, 6 threads)
Network Intel® I350

Running as a VM under ESXi 7.0u3 with PCI passthrough of ethernet

[OPNsense-bot]

Thank you for creating an issue.
Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

The easiest option to gain traction is to close this ticket and open a new one using one of our templates.

[rory-tester]

Reverted back to 25.7.10 - works as expected. Note the same sensor_info.py script runs in 2 seconds in 25.7, whereas it takes 2 minutes and 30 seconds in 26.1

[rory-tester]

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.

Issue not closed since I do not know if this is expected behavior given IPv6 being unconfigured on LAN interface.