Bug#1006724: network-manager: DNS information not cleaned correctly when switching of networks
Vincent Danjean
Version: 1.36.0-2
Severity: normal
Hi,
When I change of location with my laptop (putting it in suspend-to-ram
during the transfert), I found several times that the network become slow.
Looking more in details, I discovered that network-manager does not cleanup
correctly the DNS information of the previous (wired) connection. As I have
specific settings, the network-manager connection is not the same at work and
at home (specific Mac fixed at home, forced fixed IPv6 at work, ...)
The DNS information still present in /etc/resolv.conf comes from DHCP
information (at work or at home) that are kept when the connexion is switched
by network-manager.
Even when I disable the connexion, the DNS information are kept.
Here is the current situation (with anonymisation of IP and dnsdomain) where
I manually disable the wired connexion (so I do not have network access for
now):
vdanjean@eyak:/run/resolvconf/interface$ nmcli
docker0: connecté à docker0
"docker0"
bridge, XX:XX:XX:XX:XX:5D, sw, mtu 1500
inet4 172.17.0.1/16
route4 169.254.0.0/16 metric 1000
route4 172.17.0.0/16 metric 0
inet6 fe80::42:45ff:fe7a:55d/64
3C:DC:BC:D0:26:00: déconnecté
"Silk"
1 connexion disponible
bt (bluez), 3C:DC:BC:D0:26:00, hw
enx98fc84e13b03: déconnecté
"Realtek RTL8153"
2 connexions disponibles
ethernet (r8152), XX:XX:XX:XX:XX:03, connexion automatique, hw, mtu 1500
en-wifi: déconnecté
"Intel 8265 / 8275"
3 connexions disponibles
wifi (iwlwifi), XX:XX:XX:XX:XX:29, connexion automatique, hw, mtu 1500
p2p-dev-en-wifi: déconnecté
"p2p-dev-en-wifi"
wifi-p2p, hw
veth315cdd3: non-géré
"veth315cdd3"
ethernet (veth), XX:XX:XX:XX:XX:A7, sw, mtu 1500
lo: non-géré
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: AAA.AAA.24.30 BBB.BBB.1.22
domains: mywork1.fr mywork2.fr
servers: AAAA:AAAA:AAAA:AAAA:4 BBBB:BBBB:BBBB:BBBB::7
servers: AAA.AAA.24.30 BBB.BBB.1.22
domains: mywork1.fr mywork2.fr
servers: AAAA:AAAA:AAAA:AAAA:4 BBBB:BBBB:BBBB:BBBB::7
servers: AAA.AAA.24.30 BBB.BBB.1.22
domains: mywork1.fr mywork2.fr
servers: AAAA:AAAA:AAAA:AAAA:4 BBBB:BBBB:BBBB:BBBB::7
Utilisez « nmcli device show » pour obtenir des informations complètes sur les >
Consultez les pages de manuel nmcli(1) et nmcli-examples(7) pour les détails co>
vdanjean@eyak:/run/resolvconf/interface$ cat NetworkManager
search mywork1.fr mywork2.fr
nameserver AAA.AAA.24.30
nameserver BBB.BBB.1.22
nameserver AAAA:AAAA:AAAA:AAAA:4
nameserver BBBB:BBBB:BBBB:BBBB::7
vdanjean@eyak:/run/resolvconf/interface$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.
nameserver AAA.AAA.24.30
nameserver BBB.BBB.1.22
nameserver AAAA:AAAA:AAAA:AAAA:4
search mywork1.fr mywork2.fr
Only if I restart NetworkManager, then these outdated informations go out:
vdanjean@eyak:/run/resolvconf/interface$ sudo systemctl restart NetworkManager
vdanjean@eyak:/run/resolvconf/interface$ cat NetworkManager
search home.fr sub1.home.fr sub2.home.fr
nameserver 10.77.0.2
nameserver fd77:53::1
nameserver 192.168.77.1
vdanjean@eyak:/run/resolvconf/interface$
If I disable my home connextion (that NetworkManager connects automatically on restart),
I come back to the previous nmcli state (ie no active connexion) as before, but, this time,
/run/resolvconf/interface/NetworkManager do not exists and the "DNS
configuration:" section in nmcli is not printed.
So, it seems that sometimes NetworkManager forgets to clean DNS information
(as shown by nmcli) when switching between networks connexion. As manual
restart of the NetworkManager deamon allows one to fix that.
Regards,
Vincent
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel
Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages network-manager depends on:
ii adduser 3.118
ii dbus 1.14.0-1
ii libaudit1 1:3.0.7-1
ii libbluetooth3 5.62-2
ii libc6 2.33-7
ii libcurl3-gnutls 7.81.0-1
ii libglib2.0-0 2.70.4-1
ii libgnutls30 3.7.3-4+b1
ii libjansson4 2.13.1-1.1
ii libmm-glib0 1.18.6-2
ii libndp0 1.6-1+b1
ii libnewt0.52 0.52.21-5+b1
ii libnm0 1.36.0-2
ii libpsl5 0.21.0-1.2
ii libreadline8 8.1.2-1
ii libselinux1 3.3-1+b1
ii libsystemd0 250.3-2
ii libteamdctl0 1.31-1
ii libudev1 250.3-2
ii policykit-1 0.105-33
ii udev 250.3-2
Versions of packages network-manager recommends:
ii dnsmasq-base [dnsmasq-base] 2.86-1.1
ii libpam-systemd 250.3-2
ii modemmanager 1.18.6-2
ii ppp 2.4.9-1+1
ii wireless-regdb 2021.08.28-1
ii wpasupplicant 2:2.9.0-23
Versions of packages network-manager suggests:
ii iptables 1.8.7-1
pn libteam-utils <none>
Versions of packages network-manager is related to:
ii isc-dhcp-client 4.4.2-P1-1
-- no debconf information
Dietmar
Version: 1.36.4-2
Followup-For: Bug #1006724
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Hi,
I discovered the same behavior with my mobile vis usb tethering.
Switching between cable and wifi at home works well. Using my phone, the DNS
entry is updated. Going back to cable or wifi, the DNS from phone isn't removed
Dietmar
-- System Information:
Debian Release: bookworm/sid
APT policy: (500, 'unstable')
Foreign Architectures: i386
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages network-manager depends on:
ii dbus 1.14.0-1
ii libaudit1 1:3.0.7-1+b1
ii libbluetooth3 5.64-1
ii libc6 2.33-7
ii libcurl3-gnutls 7.82.0-2
ii libglib2.0-0 2.72.0-1+b1
ii libjansson4 2.13.1-1.1
ii libmm-glib0 1.18.6-2
ii libnewt0.52 0.52.21-5+b1
ii libnm0 1.36.4-2
ii libreadline8 8.1.2-1
ii libsystemd0 250.4-1
ii libteamdctl0 1.31-1
ii libudev1 250.4-1
ii policykit-1 0.105-33
ii udev 250.4-1
Versions of packages network-manager recommends:
ii dnsmasq-base [dnsmasq-base] 2.86-1.1
pn modemmanager <none>
ii wireless-regdb 2021.08.28-1
Versions of packages network-manager suggests:
ii iptables 1.8.7-1
pn libteam-utils <none>
Versions of packages network-manager is related to:
-- no debconf information
Dietmar Czekay
Visti Andresen
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1268
Upstream bug report:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/995
--
--------------------------
Visti Andresen
Ztove ApS
Landbrugsvej 10
5260 Odense S
Tlf.: 23 86 23 65
Homepage: https://ztove.com
---------------------------
Baptiste Jonglez
I can confirm that this bug still happens with Network-Manager 1.38.2 in bookworm.
Upstream has recently merged the fix mentioned by Visti, and has
backported it to 1.36 and 1.38.
So, here is the recap:
- the bug has been introduced in 1.35.1-dev
- the bug has been fixed in 1.39.8-dev
- the backported fix will be released in 1.38.4 (not yet released)
- the backported fix will be released in 1.36.6 (not yet released)
For bookworm, Debian can either backport the patch manually, or wait for
1.38.4 to be released and pull that in.
I notice that bullseye-backports has 1.38.0, it will probably also need an
update or a manual backport.
Thanks,
Baptiste