[Pkg-utopia-maintainers] Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean

[Cristian Ionescu-Idbohrn]

On Mon, 23 Nov 2020, Matteo F. Vescovi wrote:
> 
> FTR, I mainly use a 4G WWAN connection with an integrated module in my
> ThinkPad. Sometimes, I also use home/office Wi-Fi.

In my case, I use the laptop mostly at home, wired and wireless, same 
router, dhcp aquired dns, no 4G involved.

> 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).

No vpn involved here.

> 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.

Your use case is different, I'd say.

My use case is:

* boot the laptop with the ethernet cable connected
* check the ip address, routes, resolv.conf (generated by nm);
  everything's fine, as expected
* disconnect the ethernet cable (expecting the wifi to take over;
  it does, except for resolv.conf

I took the time to enable nm debug:

	# nmcli g l level DEBUG

while connected with the ethernet cable, and stopped it:

	# nmcli g l level ERR

after I got the wifi connection.

Used `journalctl' to generate a text syslog-file, and went through it.
Identified this sequence of messages:

,----
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.7867] dns-mgr: (device_ip_config_changed): queueing DNS updates (1)
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.7867] dns-mgr: (device_ip_config_changed): DNS configuration did not change
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.7868] dns-mgr: (device_ip_config_changed): no DNS changes to commit (0)
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.8162] dns-mgr: (device_state_changed): queueing DNS updates (1)
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.8163] dns-mgr: (update_routing_and_dns): queueing DNS updates (2)
| Nov 24 10:50:57 NetworkManager[1091]: <info>  [1606211457.8171] policy: set 'accesspoint' (wlo1) as default for IPv4 routing and DNS
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.8177] dns-mgr: (update_routing_and_dns): DNS configuration changed
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.8178] dns-mgr: (update_routing_and_dns): no DNS changes to commit (1)
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.8178] dns-mgr: (device_state_changed): DNS configuration changed
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.8179] dns-mgr: (device_state_changed): committing DNS changes (0)
| Nov 24 10:50:57 NetworkManager[1091]: <debug> [1606211457.8179] dns-mgr: update-dns: updating resolv.conf
`----

I interpret that this way: dns-mgr is confused; it concludes something 
has changed, queues DNS updates, concludes nothing has changed and 
does not commit anything (after first cleaning up resolv.conf).

I both cases (wired, wireless), the primary dns is my router's lan ip 
(served with dhcp).  In the wireless case, I locally added a secondary 
(external, public) dns ip.


Cheers,

-- 
Cristian