0.20.1: Could not resolve host.

[armond-avanes]

Describe the bug
I have a brand new docker installation of the latest version (0.20.1), and all my speedtest runs are failing with "Could not resolve host." error message with no error or debug information in the docker logs. The only error message that I see is when I click on the failed test and on its details dialog. I've set all the newly introduced env variables (SPEEDTEST_SCHEDULE, SPEEDTEST_SERVERS, etc).

I tried to extract the servers list by the instructions explained in the following release notes and got a long list:
https://github.com/alexjustesen/speedtest-tracker/releases/tag/v0.20.0

Regardless of whether I include the entire list or just a random server, all I get is the same error message explained above.

Environment (please complete the following information):

• OS: Raspberry OS
• Architecture: arm64
• Browser: Chrome (on MacOS)
• Version: 0.20.1

NOTE: Before the most recent updates in the past couple of days, I've been running Speedtest-tracker for the several months (docker) with zero issues on the same hardware and under the same database config (mysql).

[alexjustesen]

This means your container could not reach the internet, specifically it attempts to reach Cloudflare 1.1.1.1 to check for an good WAN connection.

https://docs.speedtest-tracker.dev/help/error-messages

[armond-avanes]

@alexjustesen I can ping 1.1.1.1 and any other server (either name or IP) from inside the container. The ping time is between 9-13ms for 1.1.1.1 which is pretty good.

[alexjustesen]

Can you check your container logs and see if they provide any more information? I'm doing a pretty simple GET request so I'd be surprised if that was the reason for it failing.

https://github.com/alexjustesen/speedtest-tracker/blob/main/app/Jobs/Speedtests/ExecuteOoklaSpeedtest.php#L48-L63

[armond-avanes]

That's exactly the issue that I don't get any error details in the logs. Here is the entire log, I'm attaching here:

[migrations] started
[migrations] 01-nginx-site-confs-default: executing...
[migrations] 01-nginx-site-confs-default: succeeded
[migrations] done
───────────────────────────────────────
      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝
   Brought to you by linuxserver.io
───────────────────────────────────────
To support the app dev(s) visit:
speedtest-tracker: https://github.com/sponsors/alexjustesen
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID:    1000
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: v0.20.1-ls27
Build-date: 2024-06-07T18:52:14+00:00
───────────────────────────────────────
    
Setting resolver to  192.168.1.1
Setting worker_processes to 4
generating self-signed keys in /config/keys, you can replace these with your own keys if required
....
-----
Waiting for DB to be available
[custom-init] No custom files found, skipping...
[ls.io-init] done.

Can you add some error logging to the catch block? At least to print the value of $th variable you're catching there...

[armond-avanes]

@alexjustesen I believe I found the root cause.

You're actually doing HTTP GET on 1.1.1.1 and my router is blocking DNS over HTTP (DoH) access so that all the connected devices query the router itself for DNS. As a side effect, HTTP GET 1.1.1.1 is blocked from the client (along with some other DNS servers like 8.8.8.8) although the router itself is using 1.1.1.1 for the DNS queries. I've seen this behavior on other routers as well and that's for having full control on what the clients are accessing (and to deny if a client should not access a URL/website/domain).

Is it possible that you "ping 1.1.1.1" in your code instead of HTTP GET ? This will fix the problem and you can still tell whether there is an active internet connection or not.

[adrianmusante]

I have the same error. I tried rollback version to 0.19.0 and works again.
The ping to 1.1.1.1 fails, I think is blocked by my ISP. However, the ping to 8.8.8.8 (Google DNS) does work. It's possible to use a domain or hostname to check connectivity instead of ip?

[armond-avanes]

Maybe this can be something configurable via environment variables so that people can change if the default doesn't work in their current network configuration.

[armond-avanes]

I'm also curious to know the reason for introducing the connection checking part in 0.20.x versions. After all, when you hit the actual speedtest servers and if there isn't any active connection, you're going to get the same error message as you get here in the case of 1.1.1.1. The previous versions without this check were all working fine and as expected, so not sure why we need this check. Maybe I'm missing something here...

[alexjustesen]

PR incoming which switches the HTTP get request to a ping, but in a nutshell this was to provide better error messages for when the host's internet connection was down.