No dns resolution after closing a vpn/pptp connection

Bug #1778946 reported by Emmanuel DA MOTA
176
This bug affects 33 people
Affects Status Importance Assigned to Milestone
ppp (Debian)
New
Unknown
ppp (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

step to reproduce

set a VPN connection configured to connect a Microsoft vpn server (pptp)

internet acces is ok

enable the vpn connection using the applet on the top right corner of the desktop

internet still ok
ping works

disable the vpn connection

ping doesn't works with a host but works if i specify an ip address

ping: xx.net: Nom ou service inconnu

As a workaround, i disable the ethernet link and re-enable it

name resolution is now ok

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: network-manager 1.10.6-2ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Jun 27 18:09:30 2018
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2014-06-03 (1484 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
IpRoute:
 default via 192.168.0.254 dev eth0 proto dhcp metric 20100
 169.254.0.0/16 dev eth0 scope link metric 1000
 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
RfKill:

SourcePackage: network-manager
UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH
 eth0 ethernet connected /org/freedesktop/NetworkManager/Devices/2 Connexion filaire 1 94806bba-1c68-46b6-87f4-a3eeeeaff6dd /org/freedesktop/NetworkManager/ActiveConnection/6
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- -- --
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.10.6 connected (site only) started limited enabled enabled enabled enabled enabled

Revision history for this message
Emmanuel DA MOTA (vilain-mamuth) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Ivan Danov (idanov) wrote :

Before start pptp vpn:

$ ls -laF /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 714 jun 30 18:26 /run/systemd/resolve/stub-resolv.conf

After start pptp vpn:

$ ls -laF /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 714 jun 30 18:26 /run/systemd/resolve/stub-resolv.conf

After stop pptp vpn:

$ ls -laF /run/systemd/resolve/stub-resolv.conf
-rw------- 1 root root 714 jun 30 18:26 /run/systemd/resolve/stub-resolv.conf

File /run/systemd/resolve/stub-resolv.conf is readable only for root user.
And DNS is accessible only for root user.

$ ping google.com
ping: google.com: Temporary failure in name resolution
$ sudo ping google.com
PING google.com (172.217.169.110) 56(84) bytes of data.
64 bytes from sof02s31-in-f14.1e100.net (172.217.169.110): icmp_seq=1 ttl=55 time=0.999 ms
..........

Revision history for this message
Emmanuel DA MOTA (vilain-mamuth) wrote :

seems related to the file /etc/ppp/ip-up.d/0000usepeerdns on line 23-24

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
mv -f "$REALRESOLVCONF.tmp" "$REALRESOLVCONF"

the cp command doesn't preserve file ownership

Will Cooke (willcooke)
no longer affects: openvpn-systemd-resolved (Ubuntu)
tags: added: rls-cc-incoming
Revision history for this message
Sebastien Bacher (seb128) wrote :

It would be a bug in "ppp" which provides that file then and worth reporting to Debian because it's coming from there directly

Revision history for this message
Will Cooke (willcooke) wrote :

This upstream bug suggests that the problem can be resolved by installing resolvconf:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378363

I will test this, but I'm having problems with VPNs on this network atm.

Revision history for this message
Will Cooke (willcooke) wrote :

I spoke to stgraber a bit, he said that the resolvconf thing is probably a red herring.

Revision history for this message
Rasmus Pedersen (sundowndk) wrote :

Installing resolveconf fixed it for me, now DNS resolv works after PPTP disconnects.

Revision history for this message
Will Cooke (willcooke) wrote :

Also confirming that installing resolvconf makes DNS work once the VPN is disconnected.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

cp -a is supposed to preserve ownership. -a means "-dR --preserve=all".

Could someone look at what happens, by displaying more than just the /run/systemd/resolve/stub-resolv.conf file? All files in /run/systemd/resolve/ are relevant here.

This has more smells of being affected my UMASK and probably other settings, otherwise it wouldn't be a perm 600 file.

Nevertheless, running 0000usepeerdns is wrong in all cases, especially with NetworkManager. That file probably should go; replaced by something that will use systemd-resolved's interfaces instead if they are available, and definitely never runs when NetworkManager is running.

Revision history for this message
Sebastien Bacher (seb128) wrote :

tagging as rls-cc-notfixing, while good to fix it impacts a non default plugin and we don't think it's important enough to be actively tracked by desktop

tags: added: rls-cc-notfixing
removed: rls-cc-incoming
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ppp (Ubuntu):
status: New → Confirmed
Changed in resolvconf (Ubuntu):
status: New → Confirmed
Revision history for this message
Will Cooke (willcooke) wrote :

Sorry for the delay here.

Is this what you were interested in @cyphermox?

While VPN is up:

$ ls -lha /run/systemd/resolve/
total 16K
drwxr-xr-x 3 systemd-resolve systemd-resolve 140 Nov 28 12:29 .
drwxr-xr-x 20 root root 460 Nov 28 12:28 ..
drwx------ 2 systemd-resolve systemd-resolve 80 Nov 28 12:29 netif
-rw-r--r-- 1 systemd-resolve systemd-resolve 647 Nov 28 12:29 resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 712 Nov 28 12:29 stub-resolv.conf
-rw------- 1 root root 712 Nov 28 12:27 stub-resolv.conf.pppd-backup.ppp0
-rw-r--r-- 1 root root 728 Nov 28 12:29 stub-resolv.conf.tmp

After VPN is closed:

$ ls -lha /run/systemd/resolve/
total 12K
drwxr-xr-x 3 systemd-resolve systemd-resolve 120 Nov 28 12:32 .
drwxr-xr-x 20 root root 460 Nov 28 12:28 ..
drwx------ 2 systemd-resolve systemd-resolve 60 Nov 28 12:32 netif
-rw-r--r-- 1 systemd-resolve systemd-resolve 647 Nov 28 12:32 resolv.conf
-rw------- 1 root root 712 Nov 28 12:27 stub-resolv.conf
-rw-r--r-- 1 root root 728 Nov 28 12:29 stub-resolv.conf.tmp

Attached are the files after the VPN is shutdown.

Revision history for this message
Douglas Kosovic (dkosovic) wrote :

I can confirm the issue is the following line in /etc/ppp/ip-up.d/0000usepeerdns as previously mentioned :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

The variable expansion of that line is :
cp -a /run/systemd/resolve/stub-resolv.conf /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0

I had to modify the shebang line of that script from :
  #!/bin/sh -e
to :
  #!/bin/sh
to get past that line and output debugging output I inserted, which included :

ls -l /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 720 Jan 17 21:47 /run/systemd/resolve/stub-resolv.conf

ls -l /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0
-rw------- 1 root root 720 Jan 17 21:47 /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0

So 'cp -a' isn't copying the permissions. Oddly, $? is 0 after running that 'cp -a' line, therefor seems correct, also umask is 0022, so I'm not sure what is going wrong.

Anyway a fix seems to be to change the following line in /etc/ppp/ip-up.d/0000usepeerdns from :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

For Ubuntu 18.04 setups that have the pppconfig package installed, the following lines in /etc/ppp/ip-up.d/0dns-up probably should be changed from :

/bin/cp -Lp "$RESOLVCONF" "$RESOLVBAK" || exit 1
/bin/cp -Lp "$TEMPRESOLV" "$RESOLVCONF" || exit 1
chmod 644 "$RESOLVCONF" || exit 1

to:

/bin/cp -Lp "$RESOLVCONF" "$RESOLVBAK" || exit 1
chmod 644 "$RESOLVBAK" || exit 1
/bin/cp -Lp "$TEMPRESOLV" "$RESOLVCONF" || exit 1
chmod 644 "$RESOLVCONF" || exit 1

Revision history for this message
Douglas Kosovic (dkosovic) wrote :

Correction the following line in /etc/ppp/ip-up.d/0000usepeerdns probably should be changed from :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp -Lp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

Revision history for this message
Douglas Kosovic (dkosovic) wrote :

Sorry ignore comment #16 as the following line in /etc/ppp/ip-up.d/0000usepeerdns will exit because of the '#!/bin/sh -e' shebang line:

cp -Lp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

So my original suggestion of replacing the following line:

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

was correct and won't prematurely exit.

Revision history for this message
Douglas Kosovic (dkosovic) wrote :

I wasn't able to redirect the stderr from the following line in /etc/ppp/ip-up.d/0000usepeerdns (probably because of something pppd is doing) :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

So I modified the cp.c source from the coreutils package and redirected stderr to a file.

The error message I now see is :

cp: failed to preserve ownership for '/run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0': Operation not permitted

cp.c is using the lchown() function which is failing with that message.

Looks like only preserving ownership is failing as I tried the following and it works:

cp --preserve=mode,timestamps "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

The way /run is mounted might be the reason why 'cp -a' and lchown() is failing.

Ignore what I said able $? being 0 after the cp -a line. Doing the following line confirms $? is 1 :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE" || echo ERROR $? >> /tmp/usepeerdns-up.log

Revision history for this message
Douglas Kosovic (dkosovic) wrote :

Comment 6 and 7 in the upstream GNOME NetworkManager-pptp bug report :
    https://bugzilla.gnome.org/show_bug.cgi?id=785771#c6
are relevant to this bug (but not the 'cp -a' issue).

As mentioned, the following exit in /etc/ppp/ip-up.d/000resolvconf when the interface is managed by NM, seems the right solution.

    case "$6" in
      nm-pptp-service-*|nm-l2tp-service-*|/org/freedesktop/NetworkManager/PPP/*)
        # NetworkManager handles it
        exit 0
        ;;
    esac

Perhaps the exit should be added to /etc/ppp/ip-up.d/0000usepeerdns for instances when resolvconf package isn't installed?

Changed in network-manager (Ubuntu):
assignee: nobody → Till Kamppeter (till-kamppeter)
importance: Undecided → Medium
Revision history for this message
Paul Smith (psmith-gnu) wrote :

Although this problem is easy to fix once you know what to do, I don't know if it should be only "Medium" importance because the impact is massive: no DNS is available. If you're not technically inclined enough to know to go poking around /etc/resolv.conf if DNS breaks, you would never be able to figure out what was wrong with your system and you can't search the internet to find a solution...

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

As I see the comments here, the fix is to modify the file /etc/ppp/ip-up.d/0000usepeerdns according to comments #17 and #19. /etc/ppp/ip-up.d/0000usepeerdns is part of the ppp package, so the bug needs to be fixed in the ppp package.

Changed in network-manager (Ubuntu):
status: Confirmed → Invalid
Changed in resolvconf (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Attached is the debdiff with the proposed fix of comment #19 applied. Someone with appropriate upload rights to Disco, please upload it.

I could not actually test it as I have no access to a Microsoft VPN,

I do not see any regression though. I can access Canonical's VPNs and while having activated one and also after deactivating it I always have DNS correctly working.

To the original poster: As soon as this is in Disco (or building the fixed package by yourself) please test whether this helps. If the fixed package does not solve your problem, we will try the proposed "cp -a ..." fixes.

tags: added: patch
Mathew Hodson (mhodson)
Changed in ppp (Ubuntu):
importance: Undecided → Medium
no longer affects: network-manager (Ubuntu)
no longer affects: resolvconf (Ubuntu)
Changed in ppp (Debian):
status: Unknown → New
Revision history for this message
Mariano Draghi (chaghi) wrote :

I've manually applied the patch proposed in comment #22 to my Ubuntu 18.10 desktop, and I can confirm that it fixes the issue for me. I haven't seen any regression either, although my testing has been very limited so far.

I've been experiencing this bug ever since Ubuntu 18.04 when disconnecting from my employer's Fortinet SSLVPN (I'm using the network-manager-fortisslvpn package). My previous workaround was to force my wifi up again (even if it was not down) after closing the VPN connection (nmcli c up $my-ssid).

Revision history for this message
Simon Quigley (tsimonq2) wrote :

Uploaded to Eoan.

If this needs to be SRUed, please adjust the bug description to follow the template: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

Thanks!

Changed in ppp (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ppp - 2.4.7-2+4.1ubuntu2

---------------
ppp (2.4.7-2+4.1ubuntu2) eoan; urgency=medium

  * debian/extra/ip-up.d/0000usepeerdns: Added NetworkManager check, which
    lets the script exit when NetworkManager is in use (LP: #1778946).

 -- Till Kamppeter <email address hidden> Fri, 08 Feb 2019 17:37:29 +0100

Changed in ppp (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Chris (cnizzardini) wrote :

Can confirm. Work-around is to turn off WiFi and re-enable it.

Distributor ID: Ubuntu
Description: Ubuntu 18.04.3 LTS
Release: 18.04
Codename: bionic

Revision history for this message
pdecat (pdecat) wrote :
Download full text (3.2 KiB)

I too have been facing this issue since a few releases, and still face it on Ubuntu 19.10 (resolvconf not installed as it causes other issues):

# sudo rm /run/systemd/resolve/stub-resolv.conf.tmp

# sudo systemctl restart NetworkManager

# ls -la /etc/resolv.conf /run/systemd/resolve/
lrwxrwxrwx 1 root root 39 Dec 23 16:31 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

/run/systemd/resolve/:
total 8
drwxr-xr-x 3 systemd-resolve systemd-resolve 100 Jan 14 13:01 .
drwxr-xr-x 21 root root 480 Jan 14 06:59 ..
drwx------ 2 systemd-resolve systemd-resolve 60 Jan 14 13:01 netif
-rw-r--r-- 1 systemd-resolve systemd-resolve 613 Jan 14 13:01 resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 731 Jan 14 13:01 stub-resolv.conf

# nmcli connection up vpn.mydomain.com
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/10)

# ls -la /etc/resolv.conf /run/systemd/resolve/
lrwxrwxrwx 1 root root 39 Dec 23 16:31 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

/run/systemd/resolve/:
total 16
drwxr-xr-x 3 systemd-resolve systemd-resolve 140 Jan 14 13:01 .
drwxr-xr-x 21 root root 480 Jan 14 06:59 ..
drwx------ 2 systemd-resolve systemd-resolve 60 Jan 14 13:01 netif
-rw-r--r-- 1 systemd-resolve systemd-resolve 613 Jan 14 13:01 resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 731 Jan 14 13:01 stub-resolv.conf
-rw------- 1 root root 731 Jan 14 13:01 stub-resolv.conf.pppd-backup.ppp0
-rw-r--r-- 1 root root 753 Jan 14 13:01 stub-resolv.conf.tmp

# nmcli connection down vpn.mydomain.com
Connection 'vpn.mydomain.com' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/10)

# ls -la /etc/resolv.conf /run/systemd/resolve/
lrwxrwxrwx 1 root root 39 Dec 23 16:31 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

/run/systemd/resolve/:
total 12
drwxr-xr-x 3 systemd-resolve systemd-resolve 120 Jan 14 13:02 .
drwxr-xr-x 21 root root 480 Jan 14 06:59 ..
drwx------ 2 systemd-resolve systemd-resolve 60 Jan 14 13:01 netif
-rw-r--r-- 1 systemd-resolve systemd-resolve 613 Jan 14 13:01 resolv.conf
-rw------- 1 root root 731 Jan 14 13:01 stub-resolv.conf
-rw-r--r-- 1 root root 753 Jan 14 13:01 stub-resolv.conf.tmp

# cat /etc/resolv.conf
cat: /etc/resolv.conf: Permission denied

# ping -c1 www.google.com
ping: www.google.com: Name or service not known

# sudo chmod a+r /etc/resolv.conf

# ping -c1 www.google.com
PING www.google.com (216.58.201.228) 56(84) bytes of data.
64 bytes from par10s33-in-f4.1e100.net (216.58.201.228): icmp_seq=1 ttl=56 time=4.52 ms

--- www.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.522/4.522/4.522/0.000 ms

My work-around is to disable both up and down 0000usepeerdns scripts:

# sudo dpkg-divert --divert /etc/ppp/ip-down.d/0000usepeerdns.bak --rename /etc/ppp/ip-down.d/0000usepeerdns

# sudo dpkg-divert --...

Read more...

Revision history for this message
Martin Dindoffer (mdindoffer) wrote :

Will this get backported to Bionic please? Or do we have to wait for the 20.4 LTS release?

Revision history for this message
Marius Gedminas (mgedmin) wrote :
Download full text (5.2 KiB)

Unfortunately the fix doesn't work and Ubuntu 19.10 with ppp 2.4.7-2+4.1ubuntu4.1 is still affected. I've added a bunch of

    logger -t 0000usepeerdns -- doing stuff

commands to /etc/ppp/ip-up.d/0000usepeerdns and /etc/ppp/ip-down.d/0000usepeerdns.

Here's what I see when /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf (which is the standard Ubuntu configuration) and /run/systemd/resolve/stub-resolv.conf is owned by systemd-resolve:systemd-resolve:

$ journalctl -b SYSLOG_IDENTIFIER=0000usepeerdns -f

kov. 18 22:16:44 blynas 0000usepeerdns[29590]: running /etc/ppp/ip-up.d/0000usepeerdns ppp0 0 10.46.37.85 192.0.2.1 7c4ea6b5-3f8b-4874-a81a-c4712fa17787
kov. 18 22:16:44 blynas 0000usepeerdns[29592]: the real resolv.conf is /run/systemd/resolve/stub-resolv.conf
kov. 18 22:16:44 blynas 0000usepeerdns[29595]: created /run/systemd/resolve/stub-resolv.conf.tmp
kov. 18 22:16:44 blynas 0000usepeerdns[29597]: -rw-r--r-- 1 systemd-resolve systemd-resolve 719 Mar 18 22:16 /run/systemd/resolve/stub-resolv.conf
                                               -rw-r--r-- 1 root root 749 Mar 18 22:16 /run/systemd/resolve/stub-resolv.conf.tmp

This indicates that the script aborted early due to the `#!/bin/sh -e` shebang line, as I had more logging statements. The failing command must've been the cp -a.
Disconnecting produces

kov. 18 22:16:49 blynas 0000usepeerdns[29785]: running /etc/ppp/ip-down.d/0000usepeerdns ppp0 0 10.46.37.85 192.0.2.1 7c4ea6b5-3f8b-4874-a81a-c4712fa17787
kov. 18 22:16:49 blynas 0000usepeerdns[29791]: -rw-r--r-- 1 systemd-resolve systemd-resolve 719 Mar 18 22:16 /run/systemd/resolve/stub-resolv.conf
                                               -rw------- 1 root root 719 Mar 18 22:16 /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0
kov. 18 22:16:49 blynas 0000usepeerdns[29797]: moved /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0 to /run/systemd/resolve/stub-resolv.conf
kov. 18 22:16:49 blynas 0000usepeerdns[29803]: -rw------- 1 root root 719 Mar 18 22:16 /run/systemd/resolve/stub-resolv.conf
kov. 18 22:16:49 blynas 0000usepeerdns[29805]: all is well!

Now if I apply a manual fix of the form

    sudo chmod a+r /etc/resolv.conf

and then connect to the VPN again, I'll see that the script runs successfully to the end

kov. 18 22:18:17 blynas 0000usepeerdns[30617]: running /etc/ppp/ip-up.d/0000usepeerdns ppp0 0 10.46.37.85 192.0.2.1 7c4ea6b5-3f8b-4874-a81a-c4712fa17787
kov. 18 22:18:17 blynas 0000usepeerdns[30619]: the real resolv.conf is /run/systemd/resolve/stub-resolv.conf
kov. 18 22:18:17 blynas 0000usepeerdns[30622]: created /run/systemd/resolve/stub-resolv.conf.tmp
kov. 18 22:18:17 blynas 0000usepeerdns[30627]: -rw-r--r-- 1 root root 719 Mar 18 22:16 /run/systemd/resolve/stub-resolv.conf
                                               -rw-r--r-- 1 root root 749 Mar 18 22:18 /run/systemd/resolve/stub-resolv.conf.tmp
kov. 18 22:18:17 blynas 0000usepeerdns[30636]: backed up /run/systemd/resolve/stub-resolv.conf to /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0
kov. 18 22:18:17 blynas 0000usepeerdns[30638]: -rw-r--r-- 1 root root 719 Mar...

Read more...

Revision history for this message
Marius Gedminas (mgedmin) wrote :

The workaround I now use is to modify the cp -a command in /etc/ppp/ip-up.d/0000usepeerdns to look like this:

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE" || {
    rm -f "$REALRESOLVCONF.pppd-backup.$PPP_IFACE" "$REALRESOLVCONF.tmp"
    exit 1
}

Revision history for this message
Antanas Budriūnas (antanasb) wrote :

Ubuntu 18.04.4 LTS, same problem: DNS_PROBE_FINISHED_BAD_CONFIG after disconnecting from MS VPN.
I can confirm that workaround by Marius Gedminas from comment #30 works as expected.

Revision history for this message
Qinglin Cheng (slic) wrote :

The problem is still there on Ubuntu 18.04.4 LTS. The workaround from comment #30 works for me.

$ apt show ppp
Package: ppp
Version: 2.4.7-2+4.1ubuntu5
Status: install ok installed

Revision history for this message
Tomasz Kontusz (tomasz-kontusz) wrote :

The patch from #19 (which is now in Ubuntu) is not enough - there are still problems with network-manager-sstp, which calls pptp with "nm-sstp-service-*".

If there's no better workaround, can the 0000userpeerdns and 000resolveconf scripts at least bail on all "nm-*-service-*"?

Revision history for this message
Eivind Naess (eivnaes) wrote :

I concur with @tomasz-kontusz. This is a problem for users of network-manager-sstp. Attaching a patch that I've tested with network-manager-sstp

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.