9

I am running Arch Linux on a Raspberry Pi.

Suddenly:

  1. I am unable to ping to a website.
  2. I am unable to access a website from the browser.

I have two more computers (all running Arch Linux) connected to the Internet, where I can ping and use the Internet. Also, /etc/resolv.conf is identical on the other computers:

nameserver 10.230.252.252
nameserver 203.147.88.2
nameserver 8.8.8.8
search domain.name

I can use VNC. I can also ping to 8.8.8.8. When trying to access DuckDuckGo on Chromium I get:

This site can’t be reached
duckduckgo.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

I have an active Internet connection. What's wrong?

  • Can you ping 10.230.252.252? Can you establish a network connection to it on port 53 (nc -z 10.230.252.252 53)? Same two questions for the other IP addresses. – DopeGhoti May 10 '19 at 15:53
  • Yes, I can ping to 10.230.252.252 and the other two IP addresses . But there's a problem running netcat. I don't really have netcat installed - and I can't access the internet to install netcat. – S.Goswami May 10 '19 at 15:57
  • My laptop is one the same network - from which I am posting this question. Which has the same resolv.conf file. – S.Goswami May 10 '19 at 16:04
  • Do you have telnet? You can use that as an alternative to nc. – DopeGhoti May 10 '19 at 16:10
  • 1
    Other network services can sometimes override what you have specified in resolv.conf. Check to see if any of these services are running: wiki.archlinux.org/index.php/… – Brad Johnson May 10 '19 at 17:35
21

Although I've never had problem with my other x86_64 PC all running Arch Linux, this frequently happens till date with Arch Linux ARM when running NetworkManager.

The problem is like you are connected to wifi, but you can't ping or use the internet but you can access all the computers on the local network, and even use remote desktop sharing software.

There is a high chance that something went wrong while your ping or your browser tries to resolve the host. I can think of 3 solutions:

Solution 1

I believe this is a problem on the thousands of the Raspberry Pi systems running Archlinux ARM and using NetworkManger.

In my case /etc/resolv.conf was a broken symlink to ../run/systemd/resolve/stub-resolv.conf.

NetworkManager can't populate the symlink, and the /etc/resolv.conf is empty. We have to:

  1. Remove the broken symlink:
# rm /etc/resolv.conf
  1. Create an /etc/NetworkManager/conf.d/dns.conf file with the contents:
[main]
dns=none
main.systemd-resolved=false
  1. Restart NetworkManager:
sudo systemctl restart NetworkManager

This should fix the issue, if not follow Solution 2.


Solution 2

In case the above didn't fix the issue for you, you can temporarily populate /etc/resolv.conf by:

sudo systemctl restart systemd-resolved && sudo systemctl stop systemd-resolved

The reason this works is because probably something is messing up the /etc/resolv.conf file. The above command should overwrite the contents, but again, you should look at what causing the issue.


Solution 3

If you can't get your /etc/resolv.conf back, just create a new /etc/resolv.conf (delete if an empty old one or symbolic link exists) and paste the code:

search domain.name
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1

Note, in the first line, you can also use your router's IP address, for example (nameserver 192.168.43.1 in my case) which will make other systems pingable on the same network. It's not a good idea to generate resolv like this, but I had a bad time with the NetworkManager's auto-generated resolv. Systemd-resolvd also generates wrong ones, even on my PC.

A bit weird, here I am using google's primary dns and cloudflare's primary dns, you can use 8.8.8.8 with 8.8.4.4 or 1.1.1.1 with 1.0.0.1.


Although that step works, but you may want to stop NetworkManager from overwriting the file whenever it restarts:

Add this entry to /etc/NetworkManager/NetworkManager.conf

[main]
dns=none
systemd-resolved=false

They worked for my installations on Raspberry Pi 3 model B. Hope this will work for you, too.

| improve this answer | |
  • 3
    Thanks, disabling systemd-resolved fixed it for me. I had the same issue with the same setup: Fresh vanilla Raspberry Pi 3b running Arch Linux ARM. Maybe you should file a bug report. Seems like it doesn't work like it's supposed to. – Minding Jan 1 at 0:59
  • Yes, the bug exists till date and sometimes even restarting systemd-resolved works! And the problem occurs on ArchLinux ARM only. I have posted the issue in the forum archlinuxarm.org/forum/viewtopic.php?f=15&t=14188 – S.Goswami Jan 1 at 7:01
  • 1
    F yeah! been banging my head about this issue. Solution 3 worked for me! – Ruelos Joel Jun 30 at 4:02
6

I've just had problem with same effects. Check if time is set properly. DNSSEC seems to be enabled by default and blocking requests due to "expired" certificates.

Some other problems related to this can be diagnosed with journalctl -u systemd-resolved -b -0.

| improve this answer | |
  • Thank you for the suggestion. I kept my pi with the broken internet connection (DNS look up error?) and didn't fix it. But today I turned it on... The time is Ok indeed. And I don't know why it's working fine!!! It's super weird. – S.Goswami May 27 '19 at 13:43
4

I had this issue on Raspberry Pi 4 running Arch Linux.

The symptoms were that there was no DNS, producing the ping error message.

I observed by calling date that the time was severely off, about two days in the past.

I made sure that time synchronisation was on with systemctl status systemd-timesyncd but noticed from the output of timedatectl timesync-status that the service didn't have an IP address for the NTP server (it said Server: Null).

Using jaku255's tip of checking journalctl -u systemd-resolved -b -0, I saw that time synchronisation didn't work because DNS was failing:

DNSSEC validation failed for question ntp.org IN DS: signature-expired

It's a bit of a deadlock: DNS doesn't work because the time is wrong and the time is wrong because DNS doesn't work.

Attempting to set the time manually, I issued

timedatectl set-time "2020-02-29 10:51:55"

but this produced an error:

Failed to set time: Automatic time synchronization is enabled

To fix this, I temporarily (hehe^^) disabled time synchronization with

timedatectl set-ntp 0

and called timedatectl set-time again, this time successfully.

Afterwards, I reactivated time synchronization with timedatectl set-ntp 1 and made sure using timedatectl timesync-status that synchronisation works now:

Server: 212.69.166.153 (0.arch.pool.ntp.org)

Also, ping and curl work fine now with DNS succeeding.

| improve this answer | |
  • Thank you, this was a life saver – Ahufford May 4 at 3:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.