Processed: Re: Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
Processing control commands: > severity -1 important Bug #973701 [network-manager] network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean Severity set to 'important' from 'serious' > tag -1 -confirmed Bug #973701 [network-manager] network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean Removed tag(s) confirmed. -- 973701: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973701 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
Control: severity -1 important
Control: tag -1 -confirmed
Hi Michael!
On 2020-11-22 at 21:04 (+01), Matteo F. Vescovi wrote:
[...]
> I'm still digging in to find the culprit (possibly, a particular version
> of NM or MM that introduced the issue) but I need some more tests with
> alternative setups to fully understand the situation (seems like systems
> with both Wi-Fi and WWAN are affected).
FTR, I mainly use a 4G WWAN connection with an integrated module in my
ThinkPad. Sometimes, I also use home/office Wi-Fi.
I just found few minutes to do some more testing and I discovered that
the weird behavior happens only when an OpenVPN connection is in place,
using any of the connections available (in my case, I was used to set
automatic VPN authentication on WWAN connection).
If I disable the OpenVPN connection before disconnecting WiFi or WWAN
connections, everything works just fine; but if I leave it on (as it
should be, letting the system to manage the situation), the resolv.conf
file got completely wiped, as Cristian reported.
So, probably, the culprit here is the network-manager-openvpn{-gnome}
package, more than NM itself. Should the bug report be re-assigned to
it, then? Let me know, please.
Hope this helps, somehow.
Cheers.
--
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A
signature.asc
Description: PGP signature
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
On Sun, 22 Nov 2020, Matteo F. Vescovi wrote: > On 2020-11-04 at 21:09 (+01), Cristian Ionescu-Idbohrn wrote: > > [...] > > > IMO, my remarks and comments are all _but_ snide and stupid. The > > problem here, as I see it, is this maintainer's _arrogant_ attitude. > > Michael, sorry to say, but Cristian is right: > > I see no snide and stupid comments to the bug report and I'm > actually affected by this weird behaviour since a week or so, I must > admit. Yes, I'm not alone. I noticed this odd behaviour months ago but did not report it, as I expected that kind of _arrogant_ reaction. > I'm still digging in to find the culprit (possibly, a particular > version of NM or MM that introduced the issue) For me, it does not appear ModemManager has anything to do with this, but I can't rule that out. > but I need some more tests with alternative setups to fully > understand the situation (seems like systems with both Wi-Fi and > WWAN are affected). I can reproduce this in another way too. My laptop has both a wifi and a wired chip. When I stick in the cable, the same problem occurs: I loose the DNS configuration in /etc/resolv.conf. I can add that manually, but that should _not_ be expected. Another peculiar behaviour is that if I poweroff connected to the wifi and startup wired connected, I end up having to disconnect the cable and connect it back again to be able to get things (sort of) working again. In both cases (wired/wireless) I rely on the router's DHCP to provide the proper DNS configuration. That may need another bug report, if anyone else is able to reproduce. Cheers, -- Cristian
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
Hi! On 2020-11-04 at 21:09 (+01), Cristian Ionescu-Idbohrn wrote: [...] > IMO, my remarks and comments are all _but_ snide and stupid. The > problem here, as I see it, is this maintainer's _arrogant_ attitude. Michael, sorry to say, but Cristian is right: I see no snide and stupid comments to the bug report and I'm actually affected by this weird behaviour since a week or so, I must admit. I'm still digging in to find the culprit (possibly, a particular version of NM or MM that introduced the issue) but I need some more tests with alternative setups to fully understand the situation (seems like systems with both Wi-Fi and WWAN are affected). I'm gonna let you know my findings in the real hope to fix the problem as soon as possible, as it's quite annoying. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
On Tue, 3 Nov 2020, Michael Biebl wrote: > Am 03.11.2020 um 22:58 schrieb Cristian Ionescu-Idbohrn: > > On Tue, 3 Nov 2020, Michael Biebl wrote: > > > > > > This bug report doesn't contain any relevant information to be > > > useful > > > > Bisides the expected comment, what "relevant information" would I > > need to provide to make this bug report useful? I'd be more than > > happy to provide it. > > Anything which would make this bug report more more useful. Leave > out any snide remarks and stupid comments if you can. One more thing. "snide remarks and stupid comments"? What kind of comments are tolerated in these bug reports or on the mailinglists? In this particular case, I find out that rebooting makes my networkmanager problems go away, but restarting the service _breaks_ the OS. IMO, my remarks and comments are all _but_ snide and stupid. The problem here, as I see it, is this maintainer's _arrogant_ attitude. Period. I'd like to see the leader's comment this, but I doubt he will. -- Cristian
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
On Wed, 4 Nov 2020, Michael Biebl wrote: > > Is NM the sole application touching /etc/resolv.conf? > No other application adding entries to /etc/resolv.conf which NM > doesn't know about? I don't know. Is there a way to find out? The mark in /etc/resolv.conf: # Generated by NetworkManager clearly points to NetworkManager. Is: dbus-daemon[1092]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found. expected behaviour? -- Cristian
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
On Tue, 3 Nov 2020, Michael Biebl wrote: > > Anything which would make this bug report more more useful. Leave > out any snide remarks and stupid comments if you can. Alright, one stupid thing is the subject line. Should be: # systemctl restart NetworkManager.service instead (cut/paste error). That empties the contents of: /etc/resolv.conf -> /run/NetworkManager/resolv.conf I can reliably reproduce that. More info: This is a laptop and I'm using its wireless network interface, configured to use dhcp to get the parameters from my home router. The primary dns is the router itself, 192.168.0.1. Besides, I locally configured an additional (secondary) dns 9.9.9.9. `nmcli' confirms that: # nmcli ... DNS configuration: servers: 192.168.0.1 9.9.9.9 interface: wlo1 Still, /etc/resolv.conf is emptied after a service restart. Looking at the journal, I see: Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4987] dhcp4 (wlo1): option dhcp_lease_time => '4294967295' --> Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4987] dhcp4 (wlo1): option domain_name_servers => '192.168.0.1 192.168.0.1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4988] dhcp4 (wlo1): option host_name=> 'debian' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4988] dhcp4 (wlo1): option ip_address => '192.168.0.2' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4988] dhcp4 (wlo1): option next_server => '192.168.0.1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4989] dhcp4 (wlo1): option requested_broadcast_address => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4989] dhcp4 (wlo1): option requested_domain_name => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4989] dhcp4 (wlo1): option requested_domain_name_servers => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4989] dhcp4 (wlo1): option requested_domain_search => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4990] dhcp4 (wlo1): option requested_host_name => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4990] dhcp4 (wlo1): option requested_interface_mtu => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4990] dhcp4 (wlo1): option requested_ms_classless_static_routes => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4991] dhcp4 (wlo1): option requested_nis_domain => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4991] dhcp4 (wlo1): option requested_nis_servers => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4991] dhcp4 (wlo1): option requested_ntp_servers => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4991] dhcp4 (wlo1): option requested_rfc3442_classless_static_routes => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4992] dhcp4 (wlo1): option requested_root_path => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4992] dhcp4 (wlo1): option requested_routers=> '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4992] dhcp4 (wlo1): option requested_static_routes => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4992] dhcp4 (wlo1): option requested_subnet_mask => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4993] dhcp4 (wlo1): option requested_time_offset => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4993] dhcp4 (wlo1): option requested_wpad => '1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4993] dhcp4 (wlo1): option routers => '192.168.0.1' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4993] dhcp4 (wlo1): option subnet_mask => '255.255.255.0' Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.4994] dhcp4 (wlo1): state changed unknown -> bound Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.5042] device (wlo1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed') Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.5101] device (wlo1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed') Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.5111] device (wlo1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed') Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.5129] manager: NetworkManager state is now CONNECTED_LOCAL Nov 04 09:47:04 debian NetworkManager[2085]: [1604479624.5207] manager: NetworkManager state is now CONNECTED_SITE Nov 04 09:47:04 debian NetworkManager[2085]:
Bug#973701: [Pkg-utopia-maintainers] Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
On Tue, 3 Nov 2020, Michael Biebl wrote: > > This bug report doesn't contain any relevant information to be useful Bisides the expected comment, what "relevant information" would I need to provide to make this bug report useful? I'd be more than happy to provide it. -- Cristian
Bug#973701: [Pkg-utopia-maintainers] Bug#973701: network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean
Control: tags -1 + moreinfo Am 03.11.20 um 16:45 schrieb Cristian Ionescu-Idbohrn: Package: network-manager Version: 1.27.91-1 Severity: grave /etc/resolve.conf includes the expected configuration (WRT nameservers) on bootup. After upgrading network-manager and restarting it, /etc/resolve.conf (which is a symlink to /run/NetworkManager/resolv.conf) is basically wiped out. Includes only this: # Generated by NetworkManager Rebooting brings things to normal. Still, this isn't wintendo. I'd expect better. There are some workarounds (suggested in some other bug reports) that bring the system back to an usable state, but far away from perfect (dhclient wlan0). Duplicated home router nameserver addresses in /etc/resolv.conf: nameserver 192.168.0.1 nameserver 192.168.0.1 which is not what my configuration is. This bug report doesn't contain any relevant information to be useful
Processed: Re: [Pkg-utopia-maintainers] Bug#973701: network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean
Processing control commands: > tags -1 + moreinfo Bug #973701 [network-manager] network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean Added tag(s) moreinfo. -- 973701: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973701 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#973701: network-manager: 'systemctl restart ModemManager.service' wipes /etc/resolve.conf (almost) clean
Package: network-manager Version: 1.27.91-1 Severity: grave /etc/resolve.conf includes the expected configuration (WRT nameservers) on bootup. After upgrading network-manager and restarting it, /etc/resolve.conf (which is a symlink to /run/NetworkManager/resolv.conf) is basically wiped out. Includes only this: # Generated by NetworkManager Rebooting brings things to normal. Still, this isn't wintendo. I'd expect better. There are some workarounds (suggested in some other bug reports) that bring the system back to an usable state, but far away from perfect (dhclient wlan0). Duplicated home router nameserver addresses in /etc/resolv.conf: nameserver 192.168.0.1 nameserver 192.168.0.1 which is not what my configuration is. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (59, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager depends on: ii adduser 3.118 ii dbus 1.12.20-1 ii libaudit11:2.8.5-3.1 ii libbluetooth35.55-1 ii libc62.31-4 ii libcurl3-gnutls 7.72.0-1 ii libglib2.0-0 2.66.1-2 ii libgnutls30 3.6.15-4 ii libjansson4 2.13.1-1 ii libmm-glib0 1.14.6-0.1 ii libndp0 1.6-1+b1 ii libnewt0.52 0.52.21-4+b2 ii libnm0 1.27.91-1 ii libpam-systemd 246.6-2 ii libpsl5 0.21.0-1.1 ii libreadline8 8.0-4 ii libselinux1 3.1-2+b1 ii libsystemd0 246.6-2 ii libteamdctl0 1.31-1 ii libudev1 246.6-2 ii libuuid1 2.36-3+b2 ii policykit-1 0.105-29 ii udev 246.6-2 ii wpasupplicant2:2.9.0-15 Versions of packages network-manager recommends: ii crda 4.14+git20191112.9856751-1 ii dnsmasq-base [dnsmasq-base] 2.82-1 ii iptables 1.8.5-3 ii modemmanager 1.14.6-0.1 pn ppp Versions of packages network-manager suggests: ii isc-dhcp-client 4.4.1-2.1+b2 pn libteam-utils -- no debconf information Cheers, -- Cristian
