GNOME Bugzilla – Bug 785771
do not replace /etc/resolv.conf when ignore-auto-dns is true
Last modified: 2020-11-12 14:25:54 UTC
Created attachment 356845 [details] [review] ignore-auto-dns patch With NetworkManager-pptp, if ignore-auto-dns is true, the pppd usepeerdns option shouldn't be used as it results in /etc/resolv.conf being replaced. e.g. when the "Automatic (VPN) Addresses Only" mode is enabled in the the IPv4 GUI settings, NM_SETTING_IP_CONFIG_IGNORE_AUTO_DNS or "ignore-auto-dns" is true. Please find attached a proposed patch to fix the issue.
I faced with taht problem. If I set in /etc/NetworkManager/system-connections/connectionName "ignore-auto-dns=true" the network-manager still call pppd with usepeerdns option and /etc/resolv.conf being replaced with VPN network DNS servers. I think the problem could be in this code (8964dbe8 release: bump version to 1.12.0): src/ppp/nm-ppp-manager.c: > /* Always ask for DNS, we don't have to use them if the connection > * overrides the returned servers. > */ > nm_cmd_line_add_string (cmd, "usepeerdns");
> With NetworkManager-pptp, if ignore-auto-dns is true, the pppd usepeerdns > option shouldn't be used as it results in /etc/resolv.conf being replaced. which component is replacing /etc/resolv.conf? ppd (as spawned by the VPN plugin), should never replace /etc/resolv.conf directly. In particular, pppd is not supposed to run /etc/ppp/ip-up (when spawned by NetworkManager, or a VPN plugin of NetworkManager). Instead, nm-pptp plugin reports the DNS information to NetworkManager, and only NetworkManager decides what to write to /etc/resolv.conf. (In reply to Igor Deyashkin from comment #1) > I think the problem could be in this code (8964dbe8 release: bump version to > 1.12.0): > src/ppp/nm-ppp-manager.c: > > /* Always ask for DNS, we don't have to use them if the connection > > * overrides the returned servers. > > */ > > nm_cmd_line_add_string (cmd, "usepeerdns"); src/ppp/nm-ppp-manager.c is in NetworkManager, while comment 0 talks about pptp plugin: https://gitlab.gnome.org/GNOME/NetworkManager-pptp/blob/master/src/nm-pptp-service.c
Actually I haven't much understanding what and how is going on =/ I made args logging by replacing /usr/bin/pppd and /usr/bin/pptp by bash script wrappers. As I see, NetworkManager calls to pppd by string like that: > pppd hook > pty /sbin/pptp <remote-ip> --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-19444 ipparam nm-pptp-service-19444 nodetach lock usepeerdns noipdefault nodefaultroute noauth user <user> remotename <remote-ip> refuse-eap refuse-pap refuse-chap require-mppe-128 mppe-stateful lcp-echo-failure 0 lcp-echo-interval 0 plugin /usr/lib/pppd/2.4.7/nm-pptp-pppd-plugin.so Then pptp called > pptp hook > <remote-ip> --nolaunchpppd --loglevel 0 --logstring nm-pptp-service-19444 Then /etc/ppp/ip-up.d/00-dns.sh called with $USEPEERDNS=1 So, seems like all starts from networkmanager. Because it calls pppd with usepeerdns then pppd set $USEPEERDNS=1 and then pptp updating /etc/resolv.conf in the /etc/ppp/ip-up.d/00-dns.sh script. I am using arch, and > local/networkmanager 1.12.0-1 (gnome) > local/networkmanager-pptp 1.2.6-1 > local/ppp 2.4.7-4 > local/pptpclient 1.10.0-1
Igor, I'm not sure if you tried my patch that was attached in comment 0 for networkmanager-pptp ? My workplace no longer has a PPTP VPN server, so I'm not able to reproduce the issue. I vaguely remember Fedora and Ubuntu didn't have the issue but other Linux distros did.
Douglas, thank you, but I didn't try it. The main reason is that I can't afford to spend more time at this moment to this issue. I just started to use linux and have to learn some more about using stuff builded manualy from source in the right way. I can live with that bug(?) some more time. The main reason I wrote here is to point devs attention to that bug. And if it is not a bug - to learn what I am doing wrong. Besides that your patch can't be used "as is" because there is no more source code you patching. At least I didn't find it.
I've come back to this issue due to a different /etc/resolv.conf bug on Ubuntu and Debian, but is applicable to this bug. I worked out why NetworkManager isn't used to handle /etc/resolv.conf in some cases, but pppd is when 'usepeerdns' is specified in the ppp options file. On Debian and Ubuntu, the resolvconf package which installs /sbin/resolvconf and the /etc/ppp/ip-up.d/000resolvconf file isn't always installed. Extract from /etc/ppp/ip-up.d/000resolvconf : [ -x /sbin/resolvconf ] || exit 0 [ "$USEPEERDNS" ] || exit 0 case "$6" in nm-pptp-service-*|nm-l2tp-service-*|/org/freedesktop/NetworkManager/PPP/*) # NetworkManager handles it exit 0 ;; esac On Debian/Ubuntu if resolvconf isn't installed, then NetworkManager doesn't handle /etc/resolv.conf, instead /etc/ppp/ip-up.d/0000usepeerdns script does. You can view the 0000usepeerdns script here : https://salsa.debian.org/debian/ppp/blob/master/debian/extra/ip-up.d/0000usepeerdns I've had a look at Arch Linux and none of the scripts under /etc/ppp/ have a conditional for NetworkManager to handle /etc/resolv.conf. So I think this patch to only conditionally specify 'usepeerdns' in the generated ppp options is valid for Linux distros that aren't using NetworkManager to handle /etc/resolv.conf for one reason or another.
When NetworkManager runs other services (e.g. pppd; for VPN plugins, pppoe or WWan), then these other services should never directly configure resolve.conf. They shall return the information back to NetworkManager, and NetworkManager configures /etc/resolv.conf according to it's configuration. In particular, NetworkManager is interested in the DNS settings, even if ignore-auto-dns is specified. It may later ignore the information, but it still shall request it in the first place. That's why I think the patch is wrong. It seems pppd always wants to invoke scripts like /etc/ppp/ip-up. But I think that is a misfeature and possibly there should be a way for NM to prevent that. The ip-up script shouldn't do anything in combination with NetworkManager. The Debian patch to exit when the interface is managed by NM, seems the right solution. > On Debian/Ubuntu if resolvconf isn't installed, then NetworkManager doesn't > handle /etc/resolv.conf, instead /etc/ppp/ip-up.d/0000usepeerdns script does. Well, that depends on the configuration of NetworkManager ("main.dns" and "main.rc-manager" settings in `man NetworkManager.conf`). If you don't install resolvconf, there are still many options how NM can handle /etc/resolv.conf and most of them are applicable to Debian/Ubuntu as well.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).