Curl: (28) Resolving timed out after 3000 milliseconds RPi3

Troubleshooting
1

Creating a bug report/issue

Required Information

  • DietPi version | G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=13 G_DIETPI_VERSION_RC=2 G_GITBRANCH='master' G_GITOWNER='MichaIng' G_LIVE_PATCH_STATUS[0]='applied' G_LIVE_PATCH_STATUS[1]='not applicable'

  • Distro version | bullseye 0

  • Kernel version | Linux RPi3 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux

  • SBC model | RPi 3 Model B (aarch64) or (EG: RPi3)

  • Power supply used | Anker USB and an smartphone power-usb-adapter

  • SD card used | SanDisk or SSD via USB

Additional Information (if applicable)

  • installed is OpenSSH, Docker (portainer, pihole)

  • Can this issue be replicated on a fresh installation of DietPi?

Yes, same issue on the old/existing installation and the new one with the same raspi.
← If you sent a “dietpi-bugreport”, please paste the ID here →

  • 7995545e-754d-41fc-b922-2eb109866c2f

Steps to reproduce

When I log in to the DietPi there is a pause in scrolling between LAN IP and the team member names. Doesn’t matter if I log in via dietpi or root user.

─────────────────────────────────────────────────────
 DietPi v8.13.2 : 19:50 - Do 02.02.2023
 ─────────────────────────────────────────────────────
 - Device model : RPi 3 Model B (aarch64)
 - CPU temp : 44 °C / 111 °F : Optimal temperature
 - LAN IP : 192.168.0.222 (eth0)
curl: (28) Resolving timed out after 3000 milliseconds
 ─────────────────────────────────────────────────────

 DietPi Team     : https://github.com/MichaIng/DietPi#the-dietpi-project-team
 Image by        : DietPi Core Team (pre-image: from scratch)
 Patreon Legends : Camry2731, Chris Gelatt
 Website         : https://dietpi.com/ | https://twitter.com/DietPi_
 Contribute      : https://dietpi.com/contribute.html
 Web Hosting by  : https://myvirtualserver.com

Except of this error message during login I realized that the docker containers are not proper working. E.G. traefik-container cannot get a letsencrypt certificate. I checked the forum here with this error code and checked the resolv.conf. But unfortunately the other forum entries doesn’t solve this issue.

root@RPi3:/home/dietpi# cat /etc/resolv.conf 
nameserver 9.9.9.9
nameserver 149.112.112.112

I also run a speedtest:

root@RPi3:/home/dietpi# curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python3 -
Retrieving speedtest.net configuration...
Testing from M-net (82.x.x.x)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by meerfarbig GmbH & Co. KG (Frankfurt) [176.80 km]: 30.016 ms
Testing download speed................................................................................
Download: 2.18 Mbit/s
Testing upload speed......................................................................................................
Upload: 2.27 Mbit/s

The same on a linux laptop in the same network:

Retrieving speedtest.net configuration...
Testing from M-net (82.x.x.x)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Popsite.info (Frankfurt) [176.80 km]: 12.051 ms
Testing download speed................................................................................
Download: 50.03 Mbit/s
Testing upload speed......................................................................................................
Upload: 7.90 Mbit/s

The raspi is connected via LAN directly to my Fritzbox. I’m not sure when this issue happens the first time. I realized it today when I started to replace the SD Card with an external USB-SSD.

2

can you share following

time wget --spider dietpi.com
time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com
time ping -c1 172.67.170.219
3 
root@RPi3:/home/dietpi# time wget --spider dietpi.com
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-02 20:54:23--  http://dietpi.com/
Auflösen des Hostnamens dietpi.com (dietpi.com)… 2606:4700:3032::ac43:aadb, 2606:4700:3030::6815:1c8d, 172.67.170.219, ...
Verbindungsaufbau zu dietpi.com (dietpi.com)|2606:4700:3032::ac43:aadb|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://dietpi.com/ [folgend]
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-02 20:54:28--  https://dietpi.com/
Verbindungsaufbau zu dietpi.com (dietpi.com)|2606:4700:3032::ac43:aadb|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.


real	0m5,415s
user	0m0,125s
sys	0m0,052s

root@RPi3:/home/dietpi# time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com

real	0m0,087s
user	0m0,035s
sys	0m0,025s


root@RPi3:/home/dietpi# time ping -c1 172.67.170.219
PING 172.67.170.219 (172.67.170.219) 56(84) bytes of data.
64 bytes from 172.67.170.219: icmp_seq=1 ttl=58 time=9.36 ms

--- 172.67.170.219 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.364/9.364/9.364/0.000 ms

real	0m0,023s
user	0m0,006s
sys	0m0,009s
4

ping @MichaIng can you have a look pls

5

To me it looks like the DNS resolution is taking so long. Can you verify:

time getent hosts dietpi.com
time wget --spider -T 3 dietpi.com
6

Having exact the same issue:

time getent hosts dietpi.com

real	0m5.008s
user	0m0.001s
sys	0m0.005s

and

time wget --spider -T 3 dietpi.com

Spider mode enabled. Check if remote file exists.
--2023-02-03 09:02:06--  http://dietpi.com/
Resolving dietpi.com (dietpi.com)... failed: Connection timed out.
wget: unable to resolve host address ‘dietpi.com’

real	0m3.014s
user	0m0.007s
sys	0m0.009s
7

could you try a different DNS server within dietpi-config. Try Google DNS or Cloudflare for comparison.

Just to get an idea how fast it should be :wink:

root@DietPiProd:~# time getent hosts dietpi.com
2606:4700:3032::ac43:aadb dietpi.com
2606:4700:3030::6815:1c8d dietpi.com

real    0m0.059s
user    0m0.000s
sys     0m0.013s
root@DietPiProd:~#
8

With the DNS Server like in my first post:

dietpi@RPi3:~$ time getent hosts dietpi.com
2a06:98c1:3120::4 dietpi.com
2a06:98c1:3121::4 dietpi.com

real	0m0,030s
user	0m0,002s
sys	0m0,011s

dietpi@RPi3:~$ time wget --spider -T 3 dietpi.com
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-03 16:26:55--  http://dietpi.com/
Auflösen des Hostnamens dietpi.com (dietpi.com)… fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen.
wget: Host-Adresse »dietpi.com« kann nicht aufgelöst werden

real	0m3,063s
user	0m0,021s
sys	0m0,021s

With Google DNS:

root@RPi3:/home/dietpi# cat /etc/resolv.conf 
nameserver 8.8.8.8
nameserver 8.8.4.4

root@RPi3:/home/dietpi# time wget --spider dietpi.com
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-03 16:30:55--  http://dietpi.com/
Auflösen des Hostnamens dietpi.com (dietpi.com)… 2a06:98c1:3121::3, 2a06:98c1:3120::3, 188.114.97.3, ...
Verbindungsaufbau zu dietpi.com (dietpi.com)|2a06:98c1:3121::3|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://dietpi.com/ [folgend]
Spider-Modus eingeschaltet. Es wird geprüft, ob die Datei auf dem Server existiert.
--2023-02-03 16:31:00--  https://dietpi.com/
Verbindungsaufbau zu dietpi.com (dietpi.com)|2a06:98c1:3121::3|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Datei auf dem Server existiert und könnte weitere Verweise enthalten,
aber Rekursion ist abgeschaltet -- kein Download.


real	0m5,348s
user	0m0,134s
sys	0m0,039s

root@RPi3:/home/dietpi# time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com

real	0m0,113s
user	0m0,029s
sys	0m0,028s

root@RPi3:/home/dietpi# time ping -c1 172.67.170.219
PING 172.67.170.219 (172.67.170.219) 56(84) bytes of data.
64 bytes from 172.67.170.219: icmp_seq=1 ttl=58 time=9.48 ms

--- 172.67.170.219 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.483/9.483/9.483/0.000 ms

real	0m0,024s
user	0m0,004s
sys	0m0,011s

It feels faster but the issue with curl: (28) Resolving timed out after 3000 milliseconds still happens.

9

I changed now to Cloudfare and it’s faster:

root@RPi3:/home/dietpi# time ping -c1 172.67.170.219
PING 172.67.170.219 (172.67.170.219) 56(84) bytes of data.
64 bytes from 172.67.170.219: icmp_seq=1 ttl=58 time=9.44 ms

--- 172.67.170.219 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.437/9.437/9.437/0.000 ms

real	0m0,024s
user	0m0,000s
sys	0m0,014s
root@RPi3:/home/dietpi# time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com

real	0m0,082s
user	0m0,034s
sys	0m0,022s
root@RPi3:/home/dietpi# time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com

real	0m0,117s
user	0m0,033s
sys	0m0,024s

But the issue is still there.

10

use this one to test

11

So it really was the DNS resolution.

The tests in your last post didn’t involve any DNS resolution, so this doesn’t count :smile:.

Above this wasn’t affected, only wget and curl it seems. So valid tests are:

time wget --spider -T 3 dietpi.com
time curl -I -m 3 dietpi.com

Can you show:

grep '^hosts:' /etc/nsswitch.conf

And this doesn’t help, does it?

apt install --reinstall libidn2-0 libunistring2
12 
root@RPi3:/home/dietpi# grep '^hosts:' /etc/nsswitch.conf
hosts:          files dns

apt install --reinstall libidn2-0 libunistring2

Does not solve the issue with curl during log in.

13

Even I’m not in favour of this. But for testing, can you switch DietPi local DNS to PiHole instead of a global public DNS.?

And just out of interest, you are running Docker to host PiHole only?

14

DietPi has the IP 192.168.0.222. Therefore I setup the DietPi DNS setting to this IP. On the same machine Docker, Portainer and Pihole is installed. In the future I plan to install Traefik and a few container.

With the PiHole as the DNS for DietPi it looks better. The curl message is gone.

15

Pi-hole has a DNS cache. @Joulinar do you know whether this cache is cleared on restart? Would be interesting to know whether Pi-hole as well takes long for the resolution on the very first query.

16

I’m not 100% sure. Something to test.

@cc13 keep in mind your DietPi system is using PiHole as upstream DNS now. This has some downside because as soon as there are issues on Docker, the container or PiHole itself, DNS resolution inside DietPi is not working anymore and you would need to change/ adjust the upstream DNS setting. Maybe a challenge if you are going to refresh the container. Ah and if not already done, you would need to exclude Docker from being DietPi controlled. Otherwise, Docker will be stopped on updates or backups.

Btw: some more testing

apt install dnsutils
dig @1.1.1.1 dietpi.com | grep "Query time"
dig @8.8.8.8 dietpi.com | grep "Query time"
dig @9.9.9.9 dietpi.com | grep "Query time"
dig @192.168.0.222 dietpi.com | grep "Query time"
17

That’s correct. I see pihole as the DNS for DietPi as a temp solution, not for all time. BTW, the speedtest is now (with Pihole as DNS) as fast as expected.

root@RPi3:/home/dietpi# dig @1.1.1.1 dietpi.com | grep "Query time"
;; Query time: 28 msec
root@RPi3:/home/dietpi# dig @8.8.8.8 dietpi.com | grep "Query time"
;; Query time: 16 msec
root@RPi3:/home/dietpi# dig @9.9.9.9 dietpi.com | grep "Query time"
;; Query time: 24 msec
root@RPi3:/home/dietpi# dig @192.168.0.222 dietpi.com | grep "Query time"
;; Query time: 4 msec

Tomorrow I will take a new medium, install DietPi fresh and check the DNS before and after Docker installation.

18

Querry times on dig seems to be fine. They are as expected.

19

With a fresh installation (on SSD-USB-Medium) I run in the same issue:

curl: (28) Resolving timed out after 3000 milliseconds

No Docker, no Pihole installed in my LAN (blank dietpi). DNS is:

dietpi@RPi3:~$ cat /etc/resolv.conf 
nameserver 1.1.1.1
nameserver 1.0.0.1

Any idea? I changed the dietpi.txt after flashing the img and before the first boot. If needed I can share it.

20

we had 3-4 cases the last years where curl was taking that much time to resolve DNS request while all other DNS request activities were going smooth. But we never found a solution on this. @MichaIng correct me if I’m wrong.