Curl: (28) Resolving timed out after 3000 milliseconds

Troubleshooting
1

I’ve tried a solution from the previous thread, but unfortunately, it doesn’t work in my case. DietPi v8.13.2 on RPi 3B+.

I switched my internet provider and I got a modem with different a subnet. Before it was x.x.0.1, now it’s x.x.1.1. In dietpi-config, I changed two things only, static IP and static gateway, so from 192.168.0.20 to 192.168.1.20 and 192.168.0.1 to 192.168.1.1 and that’s it. Didn’t change DNS, it’s Quad9’s 9.9.9.11.

IPv6 is off, proxy and Wi-Fi as well. RPi is connected over ethernet. When I do “Run internet connection test”, it returns [success] Online, but it takes a couple more seconds than before. I also noticed I’m getting an error from the title, and it didn’t appear before. Ping works as well, although it takes a couple seconds more to show results and it was almost instant before. Apt update works too.

All in all, the device seems to be connected to the internet, so I’m not sure why the error from the title is shown and why it takes more time for the commands to “produce” a result? Seems like they can’t “resolve” instantly? Is there any way to fix this? Below is the command from the other thread:

x@DietPi:~# cat /etc/resolv.conf
nameserver 9.9.9.11
x@DietPi:~# readlink -f /etc/resolv.conf
/etc/resolv.conf
1 Like
2

I had issues with one of the alternative Quad9 DNS servers in my browser for DoH. Try the regular one:

echo 'nameserver 9.9.9.9' > /etc/resolv.conf
3

Hm, it’s strange it worked like a charm for the past 5–6 months, yet now suddenly shows an error when modem is switched. Regardless, I picked Quad9 from the list, now it shows like this:

x@DietPi:~# cat /etc/resolv.conf
nameserver 9.9.9.9
nameserver 149.112.112.112

but it’s still the same. Shows the same thing once I ssh’d into it and “slow” commands.

4

Try an alternative to Quad9. For testing use Cloudflare or Google DNS. Maybe your new ISP has some challenges on specific public DNS provider.

5

Also you may try to use the routers IP, which usually has the ISP’s DNS server pre-configured, but acts as a local DNS cache, i.e. is faster compared to using any upstream provider directly.

6

Tried Google, Cloudflare and OpenDNS, unfortunately, still the same.

@MichaIng on the web UI of the router/modem it shows 192.168.1.1 for DNS which is the router’s IP, but again, showing the same error.

7

So you tried using that IP in /etc/resolv.conf? Does it work when you use something other than curl?

getent ahosts dietpi.com
8

how long actually following takes

time curl dietpi.com
9

@MichaIng I prefer not to use ISP’s DNS as it’s slower and people have problems opening some websites, so in various local tech forums, users suggesting switching to some public DNS like those mentioned above. Currently, with Quad9, I’m getting:

x@DietPi:~# getent ahosts dietpi.com
104.21.28.141   STREAM dietpi.com
104.21.28.141   DGRAM
104.21.28.141   RAW
172.67.170.219  STREAM
172.67.170.219  DGRAM
172.67.170.219  RAW

@Joulinar

real    0m5.134s
user    0m0.046s
sys     0m0.017s
10

This is 5 sec, what would be extremely slow. For my systems I get 0.1 sec

root@DietPiProd:~# time curl dietpi.com

real    0m0.145s
user    0m0.025s
sys     0m0.022s
root@DietPiProd:~#
11

Have you measured the hops and packet loss to these resolvers? Install mtr if you don’t have it already and do a mtr -rwc 5 1.1.1.1 then mtr -rwc 5 8.8.8.8 etc.
Then install dnsutils and do a time dig @1.1.1.1 dietpi.com then time dig @8.8.8.8 dietpi.com
It is generally better to have multiple nameserver entries in the resolv.conf for high availability in case of failure.

12

If you can change the upstream DNS of your router, you could still benefit from its cache.

The 5s are due to it being the default timeout for DNS resolution. getent shows the result faster, isn’t it? So it’s probably just an issue with curl? wget, apt etc succeed?

13

Well, my plan is to use Adguard home on this device as a DNS blocker. I will use the upstream DNS in Adguard home, so wanted to solve this issue first.

Anyway, last night before the bed, I returned the initial DNS 9.9.9.11. I just ssh’d to RPi, and it loaded almost instantly without any error shown, so have no idea what fixed that?!

But even now, time curl dietpi.com still shows 5 secs. Also, around 5–6 secs passes before ping commands shows PING dietpi.com (172.67.170.219) 56(84) bytes of data. and then ping time.

@MichaIng I’m not sure is it just an issue with curl, since ping lags quite a bit as well. I tried ping on my VPS which is lower on specs, yet ping shows results instantly. You are correct for getent tho, it shows the results instantly.

14

What about wget?

time wget --spider dietpi.com

And does it work with normal speed when resolving the hostname locally?

time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com
time ping -c1 172.67.170.219
15

wget returned pretty much the same result as curl in the previous posts

real    0m5.487s
user    0m0.112s
sys     0m0.035s

x@DietPi:~# time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com

real    0m0.124s
user    0m0.019s
sys     0m0.032s


x@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=53 time=22.3 ms

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

real    0m0.033s
user    0m0.002s
sys     0m0.009s
16

So it is indeed the system resolver only. Mysterious. Did we actually check for kernel errors already?

dmesg -l 0,1,2,3
17

I’m getting:

x@DietPi:~# dmesg -l 0,1,2,3
[    5.609317] sd 0:0:0:0: [sda] No Caching mode page found
[    5.610013] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    6.655563] sd 1:0:0:0: [sdb] No Caching mode page found
[    6.656236] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[ 4616.571231] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
[ 6242.140344] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
[87337.376218] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
[88196.198096] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
18

Not sure if related but found a 5 years old issue at the RPI GitHub Pi3b+: "kevent 4 may have been dropped" with lan78xx · Issue #2447 · raspberrypi/linux · GitHub

19

I’ve read it, but to be honest, I’m not sure what am I supposed to do. DietPi is on the latest version, RPi is connected over LAN and Wi-Fi is disabled.

edit:

After reboot, it shows first four rows now:

x@DietPi:~# dmesg -l 0,1,2,3
[    5.588436] sd 0:0:0:0: [sda] No Caching mode page found
[    5.589110] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    6.624248] sd 1:0:0:0: [sdb] No Caching mode page found
[    6.624916] sd 1:0:0:0: [sdb] Assuming drive cache: write through
20

that’s fine and should not have any effect