name resolution (dnsmasq) fails to send queries out after suspend/resume reconnects the interface

[Pauli]

[Impact]

 * suspend/resume (which involves disconnection of network devices) leads to dnsmasq failures.

[Test Case]

 * suspend/resume on 16.04 or 16.10 when using dnsmasq, and see failures upon resume.

[Regression Potential]

 * The fix was NMU'd in Debian in the version immediately after 16.10's. I believe the regression potential is very low as this is a clear bug-fix from upstream.

---

Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)

Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b

I didn't yet test if applying that patch to ubuntu package works. I will try the patch in a few hours.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)

[Pauli (paniemin)]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834722

[Pauli (paniemin)]

I tested the linked patch. DNS queries work now after suspend and resume.

[Pauli (paniemin)]

It appears there is a crash bug in the patch which needs a minor change:

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Updated patch including the crash fix" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Harald Rudell (harald-rudell)]

A package that fixes the problem Ubuntu 16.10 amd64

built like:
mkdir --parents 161119-dnsmasq-base
cd 161119-dnsmasq-base
apt-get source dnsmasq-base
sudo apt-get build-dep dnsmasq-base
wget https://launchpadlibrarian.net/292578501/rebind-after-suspend.diff
patch --strip=0 <rebind-after-suspend.diff
cd dnsmasq-2.76
dch -i
debuild -us -uc -b
cd ..
sha256sum dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb
90816ff1e2dad6002576967b9ad02bfa3780fe4ea0419db0cedacf4b1dff5bc0 dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb
sudo dpkg --install dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb

[Harald Rudell (harald-rudell)]

Install like

wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+attachment/4780245/+files/dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb

sha256sum dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb
90816ff1e2dad6002576967b9ad02bfa3780fe4ea0419db0cedacf4b1dff5bc0 dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb

sudo dpkg --install dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb

# all your problems are gone

[Andrew (am-public-o)]

I have this problem as well on Lenovo Thinkpad X230i both with WLAN and wired connections.

dnsmasq-base/xenial-updates,xenial-security,now 2.75-1ubuntu0.16.04.1 amd64 [installed,automatic]
  Small caching DNS proxy and DHCP/TFTP server

I will try the patched version and see how it goes.

[Andrew (am-public-o)]

An update from me. I still experienced no DNS resolve a couple of times on first boot up with the patched version. I am using Xenial 16.04 by the way.

~$ uname -r
4.4.0-53-generic

~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

[Andrew (am-public-o)]

I can confirm that for this bug, I am not affected directly by suspend / resume actions. But the DNS still randomly fails during normal operation of the machine.

If I kill dnsmasq PID and restart it from the command line, then it works again.

sudo /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.1.1 --cache-size=0 --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d &

[Richard (ismail-a)]

This bug is about the socket being cached even when it goes way when the interface is recreated because of:
- standby/resume
- unplug the network cable
- ip l … down; ip l … up

If the network interface is never taken down, and you still have dns problems, it is not this bug but something else

[Richard (ismail-a)]

17.04 fails dns on boot of a fresh install, for example
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1650794
it has dnsmasq-base 2.76-5

[George Shuklin (george-shuklin)]

I dig a bit around and found that this bug affects installation where network interface is connected through USB. PCI-devices are not affected.

Symptom: if computer suspends and resumes, 'ip link' command shows increased interface number (1,2,3,4,...,11,etc).

[Dmitry Gutov (dgutov)]

Installed the patched version from #7, and it works great!

Killed the dnsmasq process and suspended/resumed twice to test it.

Dell XPS 15 9550 owner here. Just upgraded to 16.10. Never seen this bug with 16.04, *or* with 16.04.2 (with HWE updates).

[Donny (luxliquidus)]

Dell XPS 15 9550 user with Ubuntu 16.04.2 LTS here... I ran across this in the last week or few as well. The patch from #7 seems to fix it.

[Adam Monsen (meonkeys)]

I think this may be a regression. I installed 16.04.1 a few weeks ago and it was working fine (dnsmasq worked after resume). I now have a 100% repro of the bug.

Workaround: sudo pkill dnsmasq

I'm now running 16.04.2 (64-bit). I'm using a Dell XPS laptop. CPU is an Intel Core i7-6560U. Plenty of free disk & RAM.

[D (360-dennis)]

I think i am affected due to this bug too, XPS13-9350 with 16.04.2. I didn't have the bug until i went to the linux-generic-hwe-16.04, with kernel 4.8.

will the patch be included in patches for 16.04?

[Nish Aravamudan (nacc)]

It would appear that Debian fixed this in 2.76-4.1, which should be in 17.04. I will provide SRUs for 16.04 and 17.04 this week.

[Paul Smith (psmith-gnu)]

Just to add a note: this issue also occurs when using VPNs: I use NetworkManager OpenVPN and when I start up the connection I can't resolve DNS hosts from the VPN DNS server until I run "sudo killall -HUP NetworkManager" or similar. This has to be done every time the VPN goes down / comes back up.

[Jens Gersdorf (jens-gersdorf)]

I am another Dell XPS 15 owner who is affected by this bug using 16.10. Please incorporate the fix as soon as possible, as the normal end user (e.g. my wife) is not willing to kill dnsmasq each time the notebook wakes up from suspend.

[Nish Aravamudan (nacc)]

I uploaded the fix today to 16.04 and 16.10, will need to go through the SRU process.

[Brian Murray (brian-murray)]

Hello Pauli, or anyone else affected,

Accepted dnsmasq into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/dnsmasq/2.76-4ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Pauli, or anyone else affected,

Accepted dnsmasq into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/dnsmasq/2.75-1ubuntu0.16.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Simon Jones (simon-jones-blackpepper)]

Hi,
I've installed and tested the proposed dnsmasq (2.76-4ubuntu0.1) yakkety and it has solved the suspend/resume problem on my Dell XPS 13, 16.10.

Many thanks,
Simon

[Evan Broder (broder)]

I've installed this package on Xenial, and it fixes this issue for me (specifically, with openvpn).

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

I have tested the package in yakkety and fixed the issue for me too. In my case it appeared when switching wifi connection between two APs which shared the DHCP server.

[Aron Xu (happyaron)]

Adding a network-manager task here to have it tracked because reports flows in to the package a lot, but marking as invalid since the cause is actually in dnsmasq.

[Eugene San (eugenesan)]

I have merged in another bug(s) and updated the name of the bug to be a bit more "user friendly".

[Paul Smith (psmith-gnu)]

Just curious if there's more work needed here before this fix moves out of proposed and into standard updates for xenial / yakkety, or if not then is there a timeline when that transition is normally expected?

I'm currently recommending to users that they reset NetworkManager by hand when they have a DNS error: once this package makes it into the normal update queue then I can just tell them to update their systems.

Thanks!

[Thomas Ward (teward)]

Given the current state of Zesty and the proximity to a release day I believe we need patience here heh.

[Nish Aravamudan (nacc)]

Hi Paul,

https://wiki.ubuntu.com/StableReleaseUpdates is the standard reference.

It takes at least 7 days in -proposed before the SRU team will release it.

Thanks,
Nish

[Robie Basak (racb)]

The verification of the Stable Release Update for dnsmasq has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package dnsmasq - 2.76-4ubuntu0.1

---------------
dnsmasq (2.76-4ubuntu0.1) yakkety; urgency=medium

  * Add two upstream patches to fix binding to an interface being
    destroyed and recreated. LP: #1639776.
      + 2675f2061525bc954be14988d64384b74aa7bf8b
      + 16800ea072dd0cdf14d951c4bb8d2808b3dfe53d

 -- Nishanth Aravamudan <email address hidden> Tue, 28 Mar 2017 10:36:48 -0700

[Launchpad Janitor (janitor)]

This bug was fixed in the package dnsmasq - 2.75-1ubuntu0.16.04.2

---------------
dnsmasq (2.75-1ubuntu0.16.04.2) xenial; urgency=medium

  * Add two upstream patches to fix binding to an interface being
    destroyed and recreated. LP: #1639776.
      + 2675f2061525bc954be14988d64384b74aa7bf8b
      + 16800ea072dd0cdf14d951c4bb8d2808b3dfe53d

 -- Nishanth Aravamudan <email address hidden> Mon, 27 Mar 2017 17:22:13 -0700

[ALinuxUser (buntulongername-new)]

I've installed dnsmasq-base_2.75-1ubuntu0.16.04.2 (on Linux Mint), installed the 1.2.6 version of Network Manager and . . my VPN still didn't work; the problem (that I had with network-manager 1.2.6 and the older version of dnsmasq) wasn't solved. Still, my problem didn't begin after suspend/resume but rather with boot. Reverting back, once again, to the 1.2.2 version of Network Manager makes everything work again.

[GammaPoint (brad-malone)]

This bug fix corrected my VPN leaks in Ubuntu 16.10, but I've since upgraded to 17.04 (fresh install) and I'm seeing DNS leaks again. Should this issue be fixed in Zesty already, or is that coming later?

[Lukas Dzunko (lukas-d)]

I am running Ubuntu 16.04.2 LTS and I updated all packages to latest stable version including dnsmasq-base (2.75-1ubuntu0.16.04.2). VPN connection is still not working. Wireshark show that all queries are forwarded to local DNS server instead of one defined by VPN. This is not only information leak bud it also break DNS resolution at all. I am getting "resolve call failed: Query timed out" from systemd-resolve and "no servers could be reached" from host command.

I downgraded network-manager manager again to 1.2.2-0ubuntu0.16.04.4 and it start working fine. Wireshak show that all DNS queries (at least during time i was monitoring it) are forwarded to correct DNS server defined by VPN server.

Is there a way how to expedite this ? This bug is affecting lot of users and guys are considering to not stick with Ubuntu as work machine. If there is no clear way how to fix this then please downgrade network-manager and network-manager-gnome back to 1.2.2* version in stable tree. Especially the second one is important as it will resolve problems with GUI and was removed from Ubuntu repository right after update was introduced ...

[Paul Smith (psmith-gnu)]

I think the problems being reported by NJ and Lukas at least, are different issues and you should file a new report about them. I can't say about GammaPoint because the description there ("DNS leaks") is not understandable to me.

This issue has the following characteristics: DNS lookups fail, often with an error of REFUSED. Restarting dnsmasq and/or "pkill -HUP NetworkManager" fixes the problem.

If your issue doesn't meet those characteristics (particularly if it isn't fixed by restarting dnsmasq or sending SIGHUP to NetworkManager to restart it) then it's probably not this bug and you should open a new bug.

[Lukas Dzunko (lukas-d)]

Hello Paul. DNS leak mean that DNS queries still hit local DNS server while VPN connection is active. DNS resolver should query only DNS servers defined by VPN while connection is active.

I did following test:

- upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 (dnsmasq-base=2.75-1ubuntu0.16.04.2)
- restated my laptop to ensure clean start
- connected to VPN using openconnect / network-manager-openconnect-gnome

Observed results -> DNS queries are forwarded only to DNS servers defined by LAN connection (this is wrong / connection not working at all)

- "killall dnsmasq"
- dnsmasq get automatically restarted by system

Observed results -> most of the the queries are forwarded to DNS servers defined by VPN, but lot of queries get forwarded to DNS servers defined by LAN connection (this is still wrong / DNS leaks, attacker can hijack connection even if VPN is enabled)

- I downgraded back to network-manager to 1.2.2-0ubuntu0.16.04.4 (dnsmasq-base stay same)
- restated my laptop to ensure clean test
- connected to same VPN using openconnect

Observed results -> DNS queries are forwarded only to DNS servers defined by VPN connection. There are no leaks to LAN DNS server (this is correct behavior).

==============

DNS leaks are bad for several reasons. Most important ones are that it provide visibility of host names to possibly un-trusted network and give ability to hijack connection. When I connect to VPN server I expect that all traffic hit only particular vpn server / gateway. If there is query to "secure-company-server.example.com" and this hit DNS on LAN then we are instantly leaking secured names. If LAN DNS server respond to this (or response is spoofed) then connection will be made outside of VPN environment. This effectively kill security of VPN connection ...

==============

FYI: I am currently in environment where DHCP set DNS servers but policy deny connection to them (don't ask why). Therefore is much more visible if queries get forwarded to LAN DNS server just because they never get responded ... this may be reason why some of folks here claim that fix is working. If LAN DNS server respond with something then there is no visibility of problem ...

==============

FYI2: all tests for this update was monitored by wireshark. ... just to not confuse with previous "fyi" comment

==============

Lukas

[Shawn B (kantlivelong)]

I also have the same issue as Lukas.

Occurs:
  VPN Connects using redirect gateway
  VPN DNS is not used
  Local DNS unavailable
  No DNS queries work

Expected:
  VPN Connects using redirect gateway
  VPN DNS is used
  Local DNS unavailable

Temporary workaround:
  sudo pkill dnsmasq

[Paul Smith (psmith-gnu)]

It sounds like a different bug to me, if changing networkmanager fixes it without changing dnsmasq. I would file a new Launchpad bug with all the details you can provide. You can add a comment to this issue with a link.

In particular, please specify:
* If you're using IPv4 vs. IPv6
* If you have checked or unchecked the "Use this connection only for resources on its network"
* If you have this checked, try unchecking it and see if that makes a difference
* When you say "DNS lookups" please be clear about whether the hostnames being looked up are public (e.g., www.google.com or whatever), on your local LAN, or in the network accessed via the VPN. Does it make a difference which one you choose?
* Are you using fully-qualified hostnames, or relying on the DNS domain search path? Does it make a difference if you do it differently?

FYI, if you choose "Use this connection only for resources on its network" then different DNS lookups going to different servers is expected: the decision is made based on the DNS domain name; lookups for hosts with domains that are served via the VPN (as determined by information obtained from the DHCP response when you got an IP address over the VPN) will be sent to DNS servers in the VPN (again, based on DHCP). Lookups for hosts with domains that are not registered by the VPN will not be sent to the VPN's DNS server.

I assume (but have not tried) that if you don't check that box then all DNS lookups would go to the VPN DNS servers. However, this does mean that no local LAN hostnames can be resolved since your local DNS server will not be consulted. It also means if you have multiple VPN connections going, only one of them will have DNS available.

If you either use fully-qualified hostnames, and/or you ensure that the VPN's DNS domains come first in the search path, then I don't think there should be a security issue (unless you don't trust your normal DNS server, but that's an entirely different situation).

[Nish Aravamudan (nacc)]

Lukas, thank you for the detailed information. However

On Mon, Apr 24, 2017 at 9:33 AM, Lukas Dzunko <email address hidden> wrote:
> Hello Paul. DNS leak mean that DNS queries still hit local DNS server
> while VPN connection is active. DNS resolver should query only DNS
> servers defined by VPN while connection is active.

You seemed to have ignored Paul's message and instead provided context
which should go in a different bug.

This bug was for name resolution failing after suspend/resume. It had
nothing directly to do with VPNs. Please file a new bug.

On Mon, Apr 24, 2017 at 9:33 AM, Lukas Dzunko <email address hidden> wrote:
> Hello Paul. DNS leak mean that DNS queries still hit local DNS server
> while VPN connection is active. DNS resolver should query only DNS
> servers defined by VPN while connection is active.
>
> I did following test:
>
> - upgraded network-manager to 1.2.6-0ubuntu0.16.04.1 (dnsmasq-base=2.75-1ubuntu0.16.04.2)
> - restated my laptop to ensure clean start
> - connected to VPN using openconnect / network-manager-openconnect-gnome
>
> Observed results -> DNS queries are forwarded only to DNS servers
> defined by LAN connection (this is wrong / connection not working at
> all)
>
> - "killall dnsmasq"
> - dnsmasq get automatically restarted by system
>
> Observed results -> most of the the queries are forwarded to DNS servers
> defined by VPN, but lot of queries get forwarded to DNS servers defined
> by LAN connection (this is still wrong / DNS leaks, attacker can hijack
> connection even if VPN is enabled)
>
> - I downgraded back to network-manager to 1.2.2-0ubuntu0.16.04.4 (dnsmasq-base stay same)
> - restated my laptop to ensure clean test
> - connected to same VPN using openconnect
>
> Observed results -> DNS queries are forwarded only to DNS servers
> defined by VPN connection. There are no leaks to LAN DNS server (this is
> correct behavior).
>
> ==============
>
> DNS leaks are bad for several reasons. Most important ones are that it
> provide visibility of host names to possibly un-trusted network and give
> ability to hijack connection. When I connect to VPN server I expect that
> all traffic hit only particular vpn server / gateway. If there is query
> to "secure-company-server.example.com" and this hit DNS on LAN then we
> are instantly leaking secured names. If LAN DNS server respond to this
> (or response is spoofed) then connection will be made outside of VPN
> environment. This effectively kill security of VPN connection ...
>
> ==============
>
> FYI: I am currently in environment where DHCP set DNS servers but policy
> deny connection to them (don't ask why). Therefore is much more visible
> if queries get forwarded to LAN DNS server just because they never get
> responded ... this may be reason why some of folks here claim that fix
> is working. If LAN DNS server respond with something then there is no
> visibility of problem ...
>
> ==============
>
> FYI2: all tests for this update was monitored by wireshark. ... just to
> not confuse with previous "fyi" comment
>
> ==============
>
> Lukas
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1639776
>
...

[Paul Smith (psmith-gnu)]

Shawn B it sounds like your issue might be related to this one, since it's fixed by restarting dnsmasq. Do you have the newer dnsmasq version (you need dnsmasq-base 2.76-4ubuntu0.1 or better)?

Just to note: it's definitely true that this bug will impact VPN users; that's how I ran into it. Basically, anything that causes changes to DNS configuration will hit this: so starting / stopping VPN and also suspend / resume.

However, if your problem is solved by switching versions of NetworkManager then it's not this bug. Also if the problem is NOT solved by restarting dnsmasq then it's not this bug.

In general, the above version of dnsmasq definitely fixes _this_ bug, so if you have that version and you're still seeing problems then it's not _this_ bug. You should file a new issue in Launchpad, with all the details you can obtain.

Feel free to add a comment here with a link to the bug you create so people can follow it if they come here first.

[Shawn B (kantlivelong)]

@Paul

dnsmasq is 2.75-1ubuntu0.16.04.2 and I don't see anything newer within my repo. Has the pkg been updated for 16.04?

pkg info:
https://pastebin.com/aximAJxc

Mint 18.1 (Ubuntu 16.04.2) x64

[Paul Smith (psmith-gnu)]

Yes, that version is OK (I'm on 16.10 so mine is a bit newer). If you check /usr/share/doc/dnsmasq-base/changelog.Debian.gz on your system you should see info related to this bug in that changelog.

[Shawn B (kantlivelong)]

Ah yes. This is indeed referenced in the changelog on the system.

Not sure what I should do next though. Open a new bugid or continue here?

[Lukas Dzunko (lukas-d)]

Paul, Nish ... VPN problem was initially reported as #1671606 . This bug get closed as duplicate to this one. I am not against opening new bug but we need some kind of statement "why?" ... I don't want to open bug which may get duplicated again to this one.

I will test proposal from Paul to see if "Use this connection only for resources on its network" make difference ... FYI: Local resources are un-trusted on networks like network in hotels. So there should be no leaks while secure connection is in place.

[Ing. Radomír Polách (exander77)]

I have a fully updated Ubuntu 17.04 and when I connect to VPN /var/run/NetworkManager/resolv.conf does not get updated with DNS. Any fix soon?

[Ing. Radomír Polách (exander77)]

I did some testing, it affects PPTP, but does not seem to affect OpenVPN.

[Colin Law (colin-law)]

@exander77 this bug is specifically about a failure after suspend/resume. If your issue does not relate to suspend/resume it is a different bug.

[Ing. Radomír Polách (exander77)]

@colin-law That's bullshit, #1671606 was closed as duplicated of this:
DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606

[Colin Law (colin-law)]

@exander77 there is no need for personal abuse here. In that case the description of this bug should have been updated to include that. However I see there is debate on that bug about whether it is fixed by the version of dnsmasq which fixes this bug. If not then it is definitely a different bug. I suggest opening a new bug. It will not get duplicated to this one if the dnsmasq fix does not fix the problem. There is no point commenting further on this bug as it is marked as fixed so no-one will do anything about it.

[Lukas Dzunko (lukas-d)]

Here is bug report for DNS VPN problems -> #1688018 ... as requested.

[Christian Reis (kiko)]

FWIW I continue to face this issue specifically when suspending while using the mobile broadband connection(predictable interface name wwp0s29u1u4i6) on my x220. I noticed this thread:

  https://mail.gnome.org/archives/networkmanager-list/2016-September/msg00000.html

Which notes this command is a workaround:

  busctl call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager
Reload "u" 4

and a link to an upstream bug at https://bugzilla.redhat.com/show_bug.cgi?id=1367772 -- I do wonder whether the fix we've adopted has diverged from what's recommended there, since it's reported to fix the OP's issue.

[Christian Reis (kiko)]

Hmm, just noticed this is likely the same patch merged here -- well, I'm running the latest Xenial packages:

ii dnsmasq-base 2.75-1ubuntu0.16.04.1 amd64 Small caching DNS proxy and DHCP/TFTP server
ii network-manager 1.2.6-0ubuntu0.16.04.1 amd64 network management framework (daemon and userspace tools)

And I am still seeing the same behaviour.

[xtonic (deflexor)]

Have the same issue on 17.04
In order to make dns resolution work again one should type after resume:
sudo systemctl restart systemd-resolved.service

[litinoveweedle (litinoveweedle)]

Any updates for this one? After half year? on LTS? Are you serious?

Please note, that this bug #1672491 , ##1639776 and many other could be easily patched, just by applying patches:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=16800ea072dd0cdf14d951c4bb8d2808b3dfe53d

to dnsmasq package. If someone just could move the lazy ass and at least follow other distros like Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1373485

I will post non constructive and frustrating post to all regarding bugs, so hopefully someone will feel ashamed and finally fix it. Otherwise I would like to ask you: step down as maintainers and orphan given package so someone else who knows how to patch source could take over from you - because you are doing no good by doing nothing!

[Colin Law (colin-law)]

@litinoveweedle this bug is marked fixed. If you are still seeing a similar symptom then I suggest opening a new bug.