NM fails to configure routing correctly when connect to two LANs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dnsmasq (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
network-manager (Ubuntu) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
My computer happens to be connected to two networks through eth0 and wlan0. NetworkManager connects to both of them automatically and use DHCP for both of them. Both networks are protected from the outside by firewalls and they are lots of DNS servers (obtained automatically). Since the upgrade to Precise, DNS no longer works without manual intervention.
What happens is that, since bug #903854, dnsmasq no longer receives the option --strict-order. As a consequence, it tries servers in a random order to resolve DNS requests. In particular, it tries to access DNS servers from the wireless network through the eth0 route, which crosses a firewall, and therefore it fails to resolve requests. It takes a lot of failures before all the unreachable servers have been exhausted, which makes for a poor user experience.
With the --strict-order option, dnsmasq tries to access servers that can be accessed by the default route, which succeeds immediately. Note that I am not sure that --strict-order is the proper fix and it may only be papering over a real bug, but at least it does fix the issue.
network-manager: 0.9.4.0-0ubuntu2
dnsmasq-base: 2.59-4
Changed in network-manager (Ubuntu): | |
status: | Incomplete → Confirmed |
importance: | Undecided → Medium |
summary: |
- Please reenable dnsmasq --strict-order + DNS unresponsive/slow when different DNS are provided by wifi and wired + connected to different networks |
summary: |
- DNS unresponsive/slow when different DNS are provided by wifi and wired - connected to different networks + (1) NM fails to configure routing correctly when connect to two LANs; + (2) dnsmasq initially slow when some upstream nameservers can't be + reached |
Changed in dnsmasq (Ubuntu): | |
status: | New → Invalid |
Seems to me like this is possibly not the exact cause of the issue. It's expected that any network reachable via the default route (when no "more specific" route exists) will be attempted via the default route (because the kernel is supposed to always use the most specific route to get to a destination).
Furthermore, dnsmasq is supposed to be trying the dns nameservers in parallel, or at least sufficiently quickly and without blocking that this shouldn't affect network resolution in a bad way.
Could you please attach the contents of /run/nm- dns-dnsmasq. conf as well as the output of 'ip route' when you are reproducing the issue so that we can debug this?