Network manager does not resolve dns names

Bug #1675353 reported by Wolf Rogner
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
New
Undecided
Unassigned

Bug Description

NM seems completely broken in 16.10.

I use NM, wifi and several VPN connections.

Expected behaviour:

1. Connect NM to default wlan -> name resolution works without interuption and permanently
2. Connection to Cisco Anyconnect (via openconnect) -> DNS servers sent via DHCP should be added to the resolver list, name resolution should work in destination network, routes adjusted accordingly
3. Connect NM to foreign network (WPA2) -> DNS resolution sent via DHCP should be taken as default

Current behaviour:

NM starts dnsmasq by default (I commented the start line to fix issues). DNS resolution stops after some minutes.

Removing dnsmasq fron NetworkManager.conf (as I did) allows for name resolution except for web browsers (neither Firefox nor Chromium use the systemd.resolver).

5 minutes of inactivity on the network suffice for the name resolution to stop working. Have to reestablish network connection (sudo resolveconf -u does not work).

This violates expectation 1

NM connects via openconnect. In the settings I added additional DNS servers and domain searches. They are ignored by dnsmasq. Name resolution does not work.

*Worksaround* -> enter IP-addresses in /etc/hosts.

dig @server-ip returns the correct IP address for target services but Firefox and Chromium do not utilize these services. dnsmasq does not return the correct address.

This violates expectation 2

Entering a foreign but known network, DNS resolution stops after a while (5 minutes inactivity suffice).

Summarizing:

a. DNS resolution using VPN connections does not work (I use openvpn, openconnect and pptp).
b. dnsmasq does not resolve dns names correctly in wlan situations
c. dnsmasq conflicts with systemd.resolver
d. Firefox and Chromium ignore systemd.resolver
e. removing dnsmasq from NetworkManager.conf releaves the issue a little (resolution drop-outs do not occur so frequently)

Comparison to plain Debian demonstrated that Debian does not start dnsmasq. This led to the elimination of my dns=dnsmaq line in NetworkManager.conf

Comparison to Raspian demonstrated that Raspian uses wpa_supplicant to control dns name resolution. I have not tried this setup in Ubuntu yet.

ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: network-manager 1.2.6-0ubuntu1
ProcVersionSignature: Ubuntu 4.8.0-41.44-generic 4.8.17
Uname: Linux 4.8.0-41-generic x86_64
NonfreeKernelModules: wl nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
Date: Thu Mar 23 11:28:21 2017
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2017-01-27 (54 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
IpRoute:
 default via 10.1.0.254 dev wlp4s0 proto static metric 600
 10.0.0.0/8 dev wlp4s0 proto kernel scope link src 10.1.0.168 metric 600
 169.254.0.0/16 dev wlp4s0 scope link metric 1000
 172.16.199.0/24 dev vmnet8 proto kernel scope link src 172.16.199.1
 192.168.31.0/24 dev vmnet1 proto kernel scope link src 192.168.31.1
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.NetworkManager.NetworkManager.conf: 2017-03-23T11:24:00.888213
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH
 wlp4s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 rsb_hs 7a8389dc-afd3-444b-a106-1974e9e74dff /org/freedesktop/NetworkManager/ActiveConnection/0
 vmnet1 ethernet unmanaged /org/freedesktop/NetworkManager/Devices/1 -- -- --
 vmnet8 ethernet unmanaged /org/freedesktop/NetworkManager/Devices/0 -- -- --
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/3 -- -- --
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.2.6 connected started full enabled enabled enabled enabled enabled

Revision history for this message
Wolf Rogner (war-rsb) wrote :
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.