DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

kleido_1984 · 2025-09-02 22:33:21

Hello,

On my Arch Linux system I am experiencing a DNS issue that only happens on Wi-Fi.

- Ethernet connection works fine (DNS resolving OK).
- Phone hotspot (same router) works fine.
- Direct Wi-Fi connection to my home router connects, but DNS fails (websites cannot be resolved).

What I have tried:
- Changed DNS servers to 1.1.1.1 / 8.8.8.8 in NetworkManager.
- Disabled IPv6 temporarily.
- Checked /etc/resolv.conf, it looks correct.
- DNS works when using Ethernet or hotspot, but fails only when Wi-Fi is connected directly to my router.

seth · 2025-09-03 08:46:31

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
resolvectl status
ip a; ip r
dig archlinux.org
stat /etc/resolv.conf
cat /etc/resolv.conf

kleido_1984 · 2025-09-03 10:37:25

bluetooth.service                        | bluetooth.target.wants
dbus-org.bluez.service                   | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service   | system
fstrim.timer                             | timers.target.wants
getty@tty1.service                       | getty.target.wants
iwd.service                              | multi-user.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
nvidia-hibernate.service                 | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-suspend.service.wants
nvidia-resume.service                    | systemd-suspend-then-hibernate.service.wants
nvidia-suspend.service                   | systemd-suspend.service.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
reflector.service                        | multi-user.target.wants
reflector.timer                          | timers.target.wants
remote-fs.target                         | multi-user.target.wants
sshd.service                             | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
systemd-userdbd.socket                   | sockets.target.wants
timeshift-login.service                  | default.target.wants
wireplumber.service                      | pipewire.service.wants

 resolvectl status
Failed to get global data: Could not activate remote peer 'org.freedesktop.resolve1':
activation request failed: unknown unit


1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    altname enxxxxxxxxxxxxxx
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.xxx/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
       valid_lft 85613sec preferred_lft 85613sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic noprefixroute
       valid_lft 470196sec preferred_lft 469596sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

default via 192.168.0.xxx dev wlan0 proto dhcp src 192.168.0.xxx metric 600 
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.xxx metric 600 

; <<>> DiG 9.20.12 <<>> archlinux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17157
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;archlinux.org.             IN      A

;; ANSWER SECTION:
archlinux.org.      60      IN      A       95.217.163.246

;; Query time: 111 msec
;; SERVER: 192.168.0.xxx#53(192.168.0.xxx) (UDP)
;; WHEN: Wed Sep 03 12:31:44 CEST 2025
;; MSG SIZE  rcvd: 58

stat /etc/resolv.conf
  File: /etc/resolv.conf
  Size: 132             Blocks: 8          IO Block: 4096   regular file
Device: 259,6   Inode: 4195584     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-09-03 12:13:04.243845562 +0200
Modify: 2025-09-03 12:13:04.159844999 +0200
Change: 2025-09-03 12:13:04.192845220 +0200
 Birth: 2025-09-03 12:13:04.159844999 +0200

# Generated by NetworkManager
search [your_domain]
nameserver 192.168.0.xxx
nameserver xxxx:xxxx:x:x::xx
nameserver xxxx:xxxx:x:x::xxx

I managed to fix the connection, but speed was very low. Tried to restart NetMaN, and i lose connection again. Right now still no connection . Something wrong with this resolve and wifi-sec.psk , coz when i try to connect using nmcli it said property key missing and i need to set connection manually writing key to the wifi-sec.psc than connection was up but still was no resolution with DNS name.

Last edited by kleido_1984 (2025-09-03 14:32:49)

V1del · 2025-09-03 13:23:06

NetworkManager and iwd are conflicting services, disable one, keep the other. If you want NetworkManager to use iwd as it's backend, see https://wiki.archlinux.org/title/Networ … Fi_backend but keep iwd's service disabled

Also please wrap outputs in [code][/code] tags in the future and edit your post in this regard.

Last edited by V1del (2025-09-03 13:23:51)

kleido_1984 · 2025-09-03 15:19:48

I understand. Thank you. The problem is now, when wired connected and wifi , wifi is working correctly, but when i unplug wired, wifi stop to resolve.

seth · 2025-09-03 15:25:27

seth wrote:

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855

when wired connected and wifi , wifi is working correctly

what makes you think you're routing over the wifi at this point at all?

Ftr, https://en.wikipedia.org/wiki/Private_network - these IPs are completely meaningless outside you LAN, you're not revealing anything.

kleido_1984 · 2025-09-03 19:05:48

seth wrote:

seth wrote:
Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
when wired connected and wifi , wifi is working correctly
what makes you think you're routing over the wifi at this point at all?
Ftr, https://en.wikipedia.org/wiki/Private_network - these IPs are completely meaningless outside you LAN, you're not revealing anything.

The “mystery” is that the DHCP client inside NetworkManager sometimes injects its own route metric when it receives the lease.

So even if everything is working fine, DHCP may push an odd metric 20600. This happens because:

NetworkManager sets a default metric if none is configured but even if configured i think.

But if multiple interfaces (wired + Wi-Fi) exist, NM raises Wi-Fi’s metric so Ethernet always wins.

Sometimes the metric calculation is inconsistent → I end up with absurd values like 20600.

That line (default via … metric 20600) overrides my good route and breaks DNS/traffic.

seth · 2025-09-03 19:43:56

NM prefers ethernet over wifi, but that doesn't explain any failures here.
Where is the "good route" coming from? Does anything that is *not* NetworkManager configure your resolver? Or other aspects of the network?
Don't try to fight NM, configure the necessary values there or configure NM to leave concerned NICs or your resolver alone.

kleido_1984 · 2025-09-03 20:27:31

The “good route” is also from NetworkManager — but only when i force a sane metric. The “bad” 20600 comes from NM’s auto-metric logic, not from another service.
I confirmed no other service (systemd-networkd, dhcpcd, connman) is touching routes or DNS — NM + systemd-resolved are the only ones active.
Solution was to configure NM directly (conf.d overrides and per-profile settings), so it stops applying the 20600 metric and unreliable DNS.

Last edited by kleido_1984 (2025-09-03 20:27:44)

seth · 2025-09-03 22:23:08

There're no good or bad metrics, NM is supposed to juggle the connections for you, preferring to route over existing wired connections and only resort to wireless once the wired connection drops out.

There're effectively three scenarios:
1. there's a wired and a wifi connection and the wired one should have the lower metric
2. there's only a wired connection and the metric becomes irrelevant
3. there's only a wifi connection and the metric becomes irrelevant

What *exactly* happens instead?

kleido_1984 · 2025-09-04 21:31:55

Problem: When only Wi-Fi is up, NetworkManager sometimes installs the Wi-Fi default route with a huge metric (20600). Then ip route show default is empty or shows metric 20600 and DNS/traffic fail, even though DHCP gave me an address+GW.

Expected: with only Wi-Fi, route should have a normal/usable metric (e.g., 600).

What I tried:
• Per-connection and global overrides: /etc/NetworkManager/conf.d/99-default-route-metric.conf with
ipv4.route-metric=600 and ipv6.route-metric=600 (plus wifi.backend=iwd)
• Per-connection ipv4/ipv6.route-metric 600, never-default no
• Ensured systemd-resolved stub resolv.conf in place
• Set net.ipv6.conf.wlan0.accept_ra=2 so NM can manage v6 routes

Symptoms remain: after systemctl restart NetworkManager and nmcli con up Wi-Fi, Wi-Fi sometimes comes back with proto dhcp metric 20600 (v4), and v6 default route can be missing or later appear with high metric. When wired is also up, routing prefers wired as expected.

What makes NM pick 20600 here despite explicit per-profile and global metrics? Is there another NM policy/dispatcher/RA interaction overriding metrics after DHCP/RA?

I'm running only NetworkManager with iwd and systemd-resolved on Arch. When both wired (enp5s0) and Wi-Fi (wlan0) are up, I get multiple IPv6 default routes from RA on Wi-Fi — one with metric 20600, one with 1024 — and sometimes the high-metric one gets used, even though wired is active.

I’ve tried:

Setting ipv6.route-metric via nmcli and conf.d

Dispatcher scripts to override metrics

Forcing accept_ra = 2 on wlan0

Removing old NM profiles, reconnecting clean

Nothing sticks — RA routes keep reappearing with wrong metrics. NM doesn’t reliably prioritize wired, and traffic sometimes routes over Wi-Fi even when Ethernet is fine.

Looking for a persistent, clean fix.

Last edited by kleido_1984 (2025-09-05 00:01:19)

seth · 2025-09-05 07:07:13

Don't. Paraphrase!
Illustrate the problematic status quo.

A route w/ a large metric is not a problem per se when it's the only route (because it's at the same time the cheapest route) what's supposed to be the case when there's only one (the wifi) NIC/route tbw.

kleido_1984 · 2025-09-05 14:15:34

seth wrote:

Don't. Paraphrase!
Illustrate the problematic status quo.
A route w/ a large metric is not a problem per se when it's the only route (because it's at the same time the cheapest route) what's supposed to be the case when there's only one (the wifi) NIC/route tbw.

When Wi-Fi (wlan0) is the only active interface, NetworkManager often assigns a default route with a high metric (20600) — for both IPv4 (DHCP) and IPv6 (RA) — resulting in broken or missing routing.

Symptoms:

IP4.GATEWAY: -- (no IPv4 gateway shown via nmcli)

No default IPv4 route even though DHCP assigns IP

Multiple IPv6 default routes via RA (e.g. metric 1024 and 20600), and the wrong one is sometimes used

DNS fails, routing is inconsistent, or traffic just doesn’t go out

When Ethernet is also up, routing prefers it — as expected

The real issue seems to be:

During interface transitions (e.g., unplug Ethernet), NetworkManager + iwd fail to fully reacquire a proper IPv4 lease.

This leads to:

No default via for IPv4

Only IPv6 routes being present — sometimes both valid and invalid ones

NM assigning fallback automatic metrics (like 20600) due to incomplete or stale config

Dispatcher scripts can fix metrics only when valid routes exist — but can't recover from a missing DHCP lease.

Current Status

When both Ethernet and Wi-Fi are active, routing behaves as expected.

When Wi-Fi is alone, routing often fails due to:

Missing IPv4 default route

Invalid metric on RA routes (1024 vs 20600)

NM sometimes preferring the wrong IPv6 route

Scripts help tune things post-connection, but can't prevent the underlying DHCP/RA fallback issue.

Last edited by kleido_1984 (2025-09-05 14:29:34)

kleido_1984 · 2025-09-05 14:23:29

iwd manages WiFi state more aggressively than wpa_supplicant, causing faster state transitions that can interrupt DHCP. The combination of iwd + NetworkManager + same subnet routing creates a perfect storm for DHCP client confusion.
The architectural issue is NetworkManager's assumption that same-subnet interfaces represent network changes requiring lease abandonment - a behavior that made sense for laptop roaming but breaks multi-homed setups.It can be that ?

Last edited by kleido_1984 (2025-09-05 14:29:26)

seth · 2025-09-10 14:28:05

iwd manages WiFi state more aggressively than wpa_supplicant

https://wiki.archlinux.org/title/Iwd#iwd_keeps_roaming

I'll try this one list time: don't paraphrase, nothing in #13 is particularly help- or useful.
Illustrate the condition w/ the actual system information.
Make sure to read https://bbs.archlinux.org/viewtopic.php?id=57855

Arch Linux

#1 2025-09-02 22:33:21

DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#2 2025-09-03 08:46:31

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#3 2025-09-03 10:37:25

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#4 2025-09-03 13:23:06

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#5 2025-09-03 15:19:48

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#6 2025-09-03 15:25:27

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#7 2025-09-03 19:05:48

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#8 2025-09-03 19:43:56

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#9 2025-09-03 20:27:31

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#10 2025-09-03 22:23:08

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#11 2025-09-04 21:31:55

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#12 2025-09-05 07:07:13

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#13 2025-09-05 14:15:34

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#14 2025-09-05 14:23:29

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

#15 2025-09-10 14:28:05

Re: DNS resolution fails only on Wi-Fi (works on Ethernet and hotspot)

Board footer