Curl: (28) Resolving timed out after 3000 milliseconds

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 to and to and that’s it. Didn’t change DNS, it’s Quad9’s

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
x@DietPi:~# readlink -f /etc/resolv.conf

1 Like

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

echo 'nameserver' > /etc/resolv.conf

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

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

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

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.

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

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

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

getent ahosts

how long actually following takes

time curl

@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   STREAM   DGRAM   RAW  STREAM  DGRAM  RAW


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

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

root@DietPiProd:~# time curl

real    0m0.145s
user    0m0.025s
sys     0m0.022s

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 then mtr -rwc 5 etc.
Then install dnsutils and do a time dig @ then time dig @
It is generally better to have multiple nameserver entries in the resolv.conf for high availability in case of failure.

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?

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 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 still shows 5 secs. Also, around 5–6 secs passes before ping commands shows PING ( 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.

What about wget?

time wget --spider

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

time curl --resolve ''
time ping -c1

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 ''

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

x@DietPi:~# time ping -c1
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=53 time=22.3 ms

--- 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

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

dmesg -l 0,1,2,3

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

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

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.


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

that’s fine and should not have any effect