Unfortunately I don’t have an USB-Ethernet-Adapter…
Let me summarize:
RPi3 with Ethernet
RPi Zero W with Wifi
Both run in the same curl issue with a fresh installed system. If I setup the upstream DNS to the local PiHole or to the Fritzbox (and then PiHole) it works fine. If I connect the RPi Zero W via Wifi with my smartphone hotspot it looks good. By end of this week I can start a test with this RPi Zero W and another ISP. Probably with another RPI Zero W and an older RPi too.
What I also can do is to remove the PiHole setup from the RPi and from the Fritzbox. I know with e.g. Cloudflare as an upstream DNS PiHole should not impact the setup. Just for testing.
That’s so strange. With the same setup (worked on Friday) back behind the original ISP (from the first days) I run in the curl issue again.
It’s the same ISP company, but the difference is: The access is working via “DS-Lite-Tunnel” shown in the Fritz!Box. The working ISP is not showing this in the Fritz!Box. And if I remember right, the working one get a public IP4 address.
I’ve been trying to track this down and reading all the posts and I think this last comment on being IP version related might be onto something. I have IPv6 disabled through dietpi-config and can confirm there are no IPv6 addresses on any interface, but curl and wget tests fail resolving DNS in the 3000 milliseconds timeframe however if I force them to use IPv4 only they process like a regular DNS lookup and under 1000 milliseconds. I’m running v8.15.2.
dietpi@Main:~$ time wget --spider -T 3 dietpi.com
URL transformed to HTTPS due to an HSTS policy
Spider mode enabled. Check if remote file exists.
--2023-03-23 14:21:01-- https://dietpi.com/
Resolving dietpi.com (dietpi.com)... failed: Connection timed out.
wget: unable to resolve host address ‘dietpi.com’
real 0m3.108s
user 0m0.063s
sys 0m0.042s
dietpi@Main:~$ time wget --inet4 --spider -T 3 dietpi.com
URL transformed to HTTPS due to an HSTS policy
Spider mode enabled. Check if remote file exists.
--2023-03-23 14:21:10-- https://dietpi.com/
Resolving dietpi.com (dietpi.com)... 172.67.170.219, 104.21.28.141
Connecting to dietpi.com (dietpi.com)|172.67.170.219|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Remote file exists and could contain further links,
but recursion is disabled -- not retrieving.
real 0m0.730s
user 0m0.103s
sys 0m0.044s
dietpi@ADSB-Main:~$ time curl -I -m 3 dietpi.com
curl: (28) Resolving timed out after 3000 milliseconds
real 0m5.118s
user 0m0.021s
sys 0m0.057s
dietpi@ADSB-Main:~$ time curl --ipv4 -I -m 3 dietpi.com
HTTP/1.1 301 Moved Permanently
Date: Thu, 23 Mar 2023 14:22:11 GMT
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Thu, 23 Mar 2023 15:22:11 GMT
Location: https://dietpi.com/
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=GwG1w1glYCXlIGp31GiCXxVNUhwiamoOOpnouuzn%2FKAnmxSQ5Do%2B8Co8WsnnlM42NIZrpTdbXWJm6m0Pp8DyIi6KjsUG8ROjuH8m3EzBQr9gXo8xgbCMAn0vDy%2Fo"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
X-Content-Type-Options: nosniff
Server: cloudflare
CF-RAY: 7ac75336e94a8c59-EWR
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
real 0m0.118s
user 0m0.020s
sys 0m0.047s
Sorry for the late reply. Can you verify that directly after you added the -4 and when it resolved fast, that it again resolves slowly or times out when you remove the -4 flag again? It may be just a coincidence that the issue solved itself when you added the -4 while the reason is different, e.g. that on a global scale a switch of the route was needed. … On the other hand very unlikely as you have the same result with curl and wget.
Otherwise, can you test:
time getent ahosts dietpi.com
cat /etc/resolv.conf
the letter to assure that only one IPv4 address is given as nameserver.
And does apt update resolve deb.debian.org immediately?
Haven’t visited this in some time but appears this has been resolved in 8.17.2 that I just recently installed on a new pi. No delays on the banner thus far and no delays running any of the resolver tests.
I setup a new RPi 4 with a fresh 8.20.1 Bookworm image behind the same internet provider. First I run in the same issue:
DietPi v8.20.1 : 5 APT updates available
─────────────────────────────────────────────────────
- Device model : RPi 4 Model B (aarch64)
- CPU temp : 52 °C / 125 °F : Running warm, but safe
- LAN IP : 192.168.0.222 (eth0)
curl: (28) Resolving timed out after 3000 milliseconds
This morning the curl issue doesn’t appear and I thought all is good. Since then I installed a view docker containers and recognized an issue with the IPV6 connection on this system. E.g. I’m using a cron-job to update my IPV4 and IPV6 address to an external provider hosting a web-address for me. For that the following URL’s are used:
https://ip6.seeip.org/
https://v6.ident.me/
Both did not work and no IPV6 address was sent back to me. After rebooting the system the curl issue was showing again, but the second URL is working fine and give me an IPV6 address back if I curl them.
Any what I can check why IPV6 run in an issue and after a reboot it looks better. If needed I can create/send log files.
PS: The 5 apt updates are not shown this morning. Will update now.
