I'm trying to connect my computer to the internet via a new router, and it is refusing to work in the most baffling way I've ever encountered.

  1. If I just connect to the wifi network in the normal way,

    Computer --(Wifi)--> Router

    then I can ping the router without problems. But I cannot ping

    PING ( 56(84) bytes of data.

    Needless to say, I also can't access any other websites.

  2. If I instead use ethernet,

    Computer --(Ethernet)--> Router

    then things are exactly the same as (1), showing it's not a wifi issue.

  3. I then connected two additional phones to the router, like this

    Computer --(Wifi)--> Router
    Phone 1  --(Wifi)--> Router
    Phone 2  --(Wifi)--> Router

    Both phones could access the internet fine, and all three devices could ping each other and the router, but the computer still couldn't access the internet.

  4. I tried connecting the computer via USB tethering, using a phone as an intermediary:

    Computer --(USB tethering)--> Phone --(Wifi)--> Router

    The computer still couldn't connect to the internet. But note that when I switched the phone to mobile data,

    Computer --(USB tethering)--> Phone --(Mobile Data)--> Mobile Network

    things worked fine, which shows the tethering setup was not at fault.

Things I have tried

  • Using other routers (in the past). They have all worked.

  • I have ensured that the computer's wireless regulatory domain is set correctly.

  • Rebooting the router.

  • I am not allowed to reset the router.

  • Faking the computer's MAC address. This made no difference, except when using ethernet, now I couldn't even connect to the router at all.

  • Using mtr. If I run mtr, I get

     1. _gateway
     3. (waiting for reply)

    I recognise as the address of the router. But it never gets any further than that, and certainly doesn't make it to dns.google.

  • Disabling TCP window scaling as suggested on the Arch Wiki. This was a complete shot in the dark. It also didn't work.

  • Running a Debian LiveUSB instead of Arch Linux.

  • Lowering the mtu from 1500 to 128. [added]

Other useful information [added]

  • The contents of /etc/resolv.conf:

     # Generated by NetworkManager
     options edns0 trust-ad
  • The contents of NetworkManager.conf:

  • The system log upon connecting via ethernet:



It seems this router has it in for my computer no matter what I do. Somehow it even recognises my computer when it's hiding behind my phone, with a fake MAC address, and with a fresh operating system. At this point, my best guess is that some hardware identifying information is somehow getting into the ping packets, and that something after the router is blacklisting it. So, the questions are the obvious ones:

  • What could be causing it not to work?
  • How do I make it work?
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – terdon
    Sep 20, 2021 at 9:23

2 Answers 2


Thanks to the discussion in chat, I managed to solve my problem and learn some things too.


There are two nasty things going on here, both of them to do with a network switch lying between my router and the Internet:

Computer --> Router --> Switch --> Internet

  1. The switch is blocking ping packets.

    This means that tools like ping, traceroute, tracepath and mtr wouldn't work even if I could connect to the internet, so they are not useful as diagnostic tools in this case. Apparently, some adminstrators disable these tools for "security reasons", though in my case they just ended up sowing lots of confusion. Because I had never seen this in the wild before, or even heard of it being done, I didn't consider it as an option. The lesson to learn here is that you can't always rely on ping to be available.

    Note that the router itself handles ping packets fine. This explains why I could ping any other device connected to the same router, but nothing else.

    (Actually, this reasoning might be a bit too naïve. According to @Cbhihe in chat, the router could be doing the blocking after all. I haven't been able to tell, but the above picture is still a useful model for what's going wrong.)

By itself however, this isn't the cause of the problem. It merely frustrates attempts to investigate it. But given that the switch is evil in one way, it's probably evil in other ways too. This brings us to...

  1. The local DHCP server wasn't communicating with my DHCP client properly.

    Every computer needs a DHCP client so it can be assigned an IP address when it's connected to a network. Mine was NetworkManager's internal dhcp client, as evidenced by dhcp=internal in NetworkManager.conf. It turns out that this DHCP client is quite basic. Although it has always worked in the past, it didn't work with this DHCP server. The result was that the IP addressing information on my computer wasn't being set correctly.

    I don't know exactly what wasn't set correctly. Certainly, my computer had received a valid IP address, as showed by ip addr, otherwise I couldn't have pinged it from my phone. But something else must have been wrong, because the switch was not appeased, and this caused it to drop all my IP packets.

    Note that the loopback address in /etc/resolv.conf is not at fault. It just reflects the fact I use dnsmasq for DNS caching, as evidenced by dns=dnsmasq in NetworkManager.conf. The idea is that dnsmasq listens on for DNS requests, checks if they're in its cache, and if not forwards them to the real DNS server. I had turned this on a long time ago as a micro-optimisation. The real DNS server was set to a sensible value, so it seems DNS was not directly a factor here. I still couldn't communicate with the DNS server to resolve anything, but that was because of the problems already mentioned, not because it was set incorrectly.


The root of the problem is my DHCP client. I swapped it out for the more featureful dhclient instead, and things worked. I still could not ping, but I had internet access, which is what matters.

A better configuration

After some more configuration, I decided to swap out dnsmasq for the newer systemd-resolved, and things are still working. My NetworkManager.conf now reads

dns=systemd-resolved   # Not strictly necessary, but helpful to remind me

Of these, dhclient requires no setting up, while systemd-resolved requires

systemctl start systemd-resolved
systemctl enable systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

Confirmed your solution worked for me as well. Slightly different scenario, but ultimately the issue was NetworkManager's DHCP client. I couldn't port forward from my router (GoogleWifi/Nest) because my server (with NetworkManager) wouldn't show up as a device to choose from. Added dhclient, changed the config to reflect the new client. Tapped the screen to refresh, boom it was there.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .