Speedtests fail with "Could not resolve host.".

[bigrichwood]

Describe the bug
All speedtests fail with the error "Could not resolve host."

0.20.2 is the last working version. 0.20.3 and 0.20.4 both fail with the same errors.

To Reproduce
Steps to reproduce the behavior:

1. run a speedtest, manual or scheduled.

Expected behavior
Speedtest shouldn't fail, it does.

Environment (please complete the following information):
Proxmox with Debian 12LXC running Docker, all fully up to date.

Docker, with the following compose.yaml:

version: "3.9"
services:
linuxserver:
image: lscr.io/linuxserver/speedtest-tracker:latest
volumes:
- ./data:/config
environment:
- DB_CONNECTION=sqlite
- PGID=1000
- PUID=1000
- PUBLIC_DASHBOARD=TRUE
- PRUNE_RESULTS_OLDER_THAN=28
- SPEEDTEST_SCHEDULE=17 * * * *
- APP_KEY=--deleted--
ports:
- 8080:80
restart: unless-stopped
container_name: speedtest-tracker
networks: {}

Additional context
From within the container itself connectivity is fine:

root@86dfde98255e:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=55 time=20.608 ms
64 bytes from 1.1.1.1: seq=1 ttl=55 time=17.068 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 17.068/18.838/20.608 ms

root@86dfde98255e:/# ping www.speedtest.net
PING www.speedtest.net (104.17.148.22): 56 data bytes
64 bytes from 104.17.148.22: seq=0 ttl=55 time=16.543 ms
64 bytes from 104.17.148.22: seq=1 ttl=55 time=15.555 ms
^C
--- www.speedtest.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 15.555/16.049/16.543 ms
root@86dfde98255e:/#

[alexjustesen]

Please see closed issues with the same title

[alexjustesen]

This looks like the cache might not have been reset, can you restart your container and ensure it's running 0.20.4?

[KGBist2000]

same here, not working with v0.20.4, also after full clean install of container.

[bigrichwood]

I take it back.

For me at least lscr.io/linuxserver/speedtest-tracker:latest is currently pointing to 0.20.3 (v0.20.3-ls29), although I'm sure I had 0.20.4 earlier, but can't remember if I specified latest or a fixed version in my compose file.

However forcing it to lscr.io/linuxserver/speedtest-tracker:0.20.4, redeploying, and then restarting the LXC it's running within appears to resolve the errors when there's no SPEEDTEST_PING_URL defined.

However there's definately something weird going on with the connectivity tests in 0.20.3 and above as if I define a host that I can quite definitely ping from the container, the errors are back. Setting and manual ping tests shown below.

SPEEDTEST_PING_URL=1.1.1.1

root@f24ed2b78674:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=55 time=28.334 ms
64 bytes from 1.1.1.1: seq=1 ttl=55 time=13.769 ms
64 bytes from 1.1.1.1: seq=2 ttl=55 time=12.529 ms
^C
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 12.529/18.210/28.334 ms
root@f24ed2b78674:/#

[alexjustesen]

@bigrichwood can you try setting a different IP or using a domain name?

[bigrichwood]

I tried all the following, and get exactly the same errors.

8.8.8.8
www.google.com
192.168.0.1 (my default gateway)
192.168.0.133 (the LXC running docker)
127.0.0.1

[alexjustesen]

For now don't set a ping url and that check should be bypassed. If the issue continues it might be CLI based and not related to the internet check. Also don't forget to restart the container after setting a new value so the cache is updated.

[bigrichwood]

It works fine if I don't define a test URL.

Interestingly, if I set it to use a FQDN I can see the DNS looking taking place in the logs of my DNS server, so it's getting at least that far.

[Chacsam]

solved for me with 0.20.4

[alexjustesen]

@bigrichwood if you're able to dig more into it some ISPs block these types of look-ups. I don't think it's an application error anymore since you can disable the check. Going to close this out one.

[bigrichwood]

It's not an ISP issue as it can't even ping within my own network, or to localhost. If I get a chance this evening I'll fire a packet sniffer up on an internal host, point it at that, and see if it's failing to ping, or failing to interpret the results correctly.

…

On Mon, 10 Jun 2024 at 15:48, Alex Justesen ***@***.***> wrote: @bigrichwood <https://github.com/bigrichwood> if you're able to dig more into it some ISPs block these types of look-ups. I don't think it's an application error anymore since you can disable the check. Going to close this out one. — Reply to this email directly, view it on GitHub <#1510 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASK24DT2PMWZLJ3K3SYPNOTZGW4CJAVCNFSM6AAAAABJA7B26OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJYGU3DSNZXGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[KGBist2000]

after again clean install of v0.20.4 container and delete following line from docker-compose file, its working now.

• SPEEDTEST_PING_URL="google.de"

[bigrichwood]

I can confirm that it's not actually pinging.

Pings from the LXC and from within the speedtest-tracker container all show up on a packet sniffer as expected, pings generated from the SPEEDTEST_PING_URL in the app do not.

To be honest this doesn't bother me that much as I've just disabled the check. But I'm happy to do more testing if you want to get to the bottom of what's breaking it.

[alexjustesen]

@bigrichwood if you don't mind digging I don't have a way to test LXC. Once you have findings open a new issue as I usually don't keep tabs on closed ones.