NetworkManager Internet Connection Sharing fails to route DNS

Bug #389006 reported by otakuj462
76
This bug affects 12 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Fix Released
High
Unassigned
Lucid
Won't Fix
High
Unassigned

Bug Description

Binary package hint: network-manager

I am able to share an internet connection between two wireless NIC's. However, DNS routing does not work correctly.
 I have used the following procedure to verify that the problem is DNS:

Use the computer behind the NAT to navigate to http://72.14.205.104/ in Firefox, and verify that this works. Then, navigate to
http://www.google.com and confirm that this does not work (Firefox says "Server not found").

I was also able to confirm this by editing /etc/resolv.conf, setting the contents to be the same as the resolv.conf file on the computer sharing the internet connection with NetworkManager. After that, all hostnames resolved correctly on the computer
behind the NAT. So, just so long as nameservers on the computer behind the NAT are set to the sharing computer's gateway's IP addres, everything works fine.

Revision history for this message
Alexander Sack (asac) wrote :

do you have dnsmasq-base package installed (also if you have the (full) dnsmasq package installed try to remove that as it might confuse some parts of NM).

Changed in network-manager (Ubuntu):
status: New → Incomplete
Revision history for this message
Steve McGrath (smcgrath23) wrote :

I believe I am experiencing this issue as well. My configuration is as follows:

Fresh Jaunty install on my laptop, with wireless interface connected to internet and wired interface connected to LAN.

Older Jaunty install (upgraded from ?, probably Feisty) on desktop, wired interface connected to LAN.

Laptop is configured via network-manager to share wireless internet to LAN. Both machines can ping each other and connect via SSH, etc. Desktop machine can reach internet sites by IP. However, Desktop machine will not resolve DNS names. Attempting to resolve google.com in nslookup results in the following:

> google.com
Server: 10.42.43.1
Address: 10.42.43.1#53

** server can't find google.com: REFUSED

As in the initial report, I have worked around this for now by manually editing resolv.conf on the desktop to match the laptop.

As nmap from the desktop shows that port 53 is accessible on the laptop, I believe this is an issue with my dnsmasq configurating, which I haven't dove in to yet. It's odd, as this initially worked, and I haven't changed any configuration. It may have stopped working after post-installation updates on the laptop, I'm not certain about the timing.

I will examine my logs and dnsmasq config and report any additional weirdness.

Revision history for this message
Steve McGrath (smcgrath23) wrote :

Just wanted to add that I've checked my logs and no packages that seem related were updated. Also, I've become aware that the dnsmasq-base package installed by default doesn't use a config file, so I've reached the end of what I can troubleshoot. Hopefully the details I've provided will be useful.

Revision history for this message
Brian Rogers (brian-rogers) wrote :

I can confirm this on both a fresh install of Jaunty and on Karmic. In both cases I created an ad-hoc network, which by default enables sharing, but DNS didn't work for clients that connected.

Changed in network-manager (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
wch (winston-stdout) wrote :

Another confirmation here.

It seems that dnsmasq doesn't want to listen on the correct interface. Here's the setup. The Ubuntu machine is connected to my router (192.168.1.1), which is connected to the internet. The Ubuntu box has address 192.168.144 on the side facing the router and internet, and 10.42.43.1 on the side that it is providing NAT to.

I ran some DNS lookups on the Ubuntu machine that is doing NAT. The first query is to the router (192.168.1.1), which is connected to the internet. The next three queries are to different interfaces on the the local machine. The only one that DOESN'T work is the interface that I'm actually interested in, which is 10.42.43.1 -- it's the address that the Ubuntu machine tells its clients is the DNS server.

# Querying the router OK
$ host ubuntu.com 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:

ubuntu.com has address 91.189.94.156
ubuntu.com mail is handled by 10 mx.canonical.com.

# Localhost interface OK
$ host ubuntu.com 127.0.0.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:

ubuntu.com has address 91.189.94.156
ubuntu.com mail is handled by 10 mx.canonical.com.

# Ubuntu machine's router-facing interface OK
$ host ubuntu.com 192.168.1.144
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:

ubuntu.com has address 91.189.94.156
ubuntu.com mail is handled by 10 mx.canonical.com.

# The client-side NAT interface of the Ubuntu machine NOT OK
$ host ubuntu.com 10.42.43.1
Using domain server:
Name: 10.42.43.1
Address: 10.42.43.1#53
Aliases:

Host ubuntu.com not found: 5(REFUSED)

Revision history for this message
wch (winston-stdout) wrote :

One more bit of information to add to my previous post. This is the output of ps:
nobody 925 0.0 0.0 19048 1192 ? S 17:58 0:00 /usr/sbin/dnsmasq --no-hosts --keep-in-foreground --bind-interfaces --no-poll --except-interface=lo --listen-address=10.42.43.1 --dhcp-range=10.42.43.10,10.42.43.100,60m --dhcp-option=option:router,10.42.43.1 --dhcp-lease-max=50 --pid-file=/var/run/nm-dnsmasq-eth1.pid

Revision history for this message
wch (winston-stdout) wrote :

Another update. (This is running on Karmic beta, with dnsmasq-base 2.50-1.)

Hopefully this diagram will make sense.
Client (10.42.43.11) <---> (10.42.43.1) [eth1] Ubuntu [eth0] (192.168.1.144) <---> (192.168.1.1) router <---> Internet

When I boot my Ubuntu machine with both interfaces active and the network sharing turned on, then I have the problem with the DNS failures. However, if I then disable eth1 and re-enable it, then everything works.

Revision history for this message
Onur Sehitoglu (onur-ceng) wrote :

I had the same problem. I sent an HUP signal to dnsmasq and it started working.

sudo killall -s HUP dnsmasq

I hope it works for you too.

My diagnosis is that at the time dnsmasq is executed, the /etc/resolv.conf file is empty
since the NetworkManager cleans it and the main interface is not ready so it has
not been filled yet.

dnsmasq is started with --no-poll option. Therefore it cannot load the new /etc/resolv.conf
updated by the main interface. Sending HUP forces it to reload and then it works fine..
Dropping the --no-poll option from the Network Manager default should also help but
I could not find where it is.

Changed in network-manager (Ubuntu):
importance: Undecided → High
Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

I'm targeting this to Lucid since it effectively breaks connection sharing.

I can confirm that sudo killall -s HUP dnsmasq makes it work, so it appears to be a problem with the timing of /etc/resolv.conf when dnsmasq is started. Because dnsmasq is started with the no-poll parameter, it doesn't pick up on changes in resolv.conf all by itself. I would suggest we:

 * contact NM upstream to ask if no-poll is a deliberate decision, and the rationale
 * upload NM patched to NOT use no-poll when firing up dnsmasq, to verify that this fixes the issues with DNS and connection sharing

Revision history for this message
Tony Espy (awe) wrote :

I'm currently working on an update to NM 0.8-rc1, so I took a quick look at the nm-dnsmasq-manager code. Looks like '--no-poll' was removed sometime between the Karmic snapshot of NM ( 0.8~a~git.20091013t193206.679d548 ) and 0.8-rc1, so this *should* be fixed by the upload. As it's in the upstream git tree, I'm going to change this to FixCommitted. When I get a chance, I'll try and find the actual commit that fixed it, and include it in a comment.

Changed in network-manager (Ubuntu Lucid):
status: Confirmed → Fix Committed
Revision history for this message
Tony Espy (awe) wrote :

commit cfb2b72dc6f1ab9e66daf53d4d7113997499049a
Author: Dan Williams <email address hidden>
Date: Sat Nov 14 14:42:58 2009 -0800

    dnsmasq: VPN DNS fixes

    Turn DHCP and DNS debugging on with NM_DNSMASQ_DEBUG.

    Without --strict-order, dnsmasq will round-robin queries which in
    the case of VPN connections may result in the query going to the
    non-VPN nameserver. Also, allow dnsmasq to poll resolv.conf for
    nameserver updates so that when the default connection changes,
    it knows about the new nameservers.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 389006] Re: NetworkManager Internet Connection Sharing fails to route DNS

Tony, is it worth queuing that for an SRU to Karmic too?

Revision history for this message
Tony Espy (awe) wrote :

Yes, the current plan is to release 0.8-rc1 in it's entirety as an SRU for Karmic. I have the NM bits done and ready to go, however as there were a couple of string additions / changes made to the applet, I'm in the process of creating patches to back those out first.

Revision history for this message
Nascarella (ottoln) wrote :

I was trying to share a connection just by creating an ad hoc connection with network-manager/dnsmasq and NAT but what happens is that dsnmasq, despite being a dhcp and dns server, it's used by network-manager to "create" the connection, but does not provide the DHCP service, even when I config /etc/dnsmasq.conf to do it.

if I run "sudo /etc/init.d/dnsmasq status" it gives me this output:
* Checking DNS forwarder and DHCP server dnsmasq * (not running)

So basically, my work around was to install dhcp3-server and configure /etc/dhcp3/dhcpd.conf to make it work with the same IP that network-manager mysteriously (I've been trying to change this, anyone knows where???) chooses to create the connection with "10.42.43.1".

Revision history for this message
UrbanWolf (urbanxwolf) wrote :

i cant seem to connect to the Internet when sharing and i can share my wireless wt can i do im think of going bk to windows

Revision history for this message
Dominic Lemire (dominic-lemire) wrote :

Tony, did you submit this fix for Karmic? I still have the DNS problem and I don't see it in the list of pending SRU.

Do I need to enable karmic-proposed / karmic-backports?

Revision history for this message
al_mckin (amckinley03) wrote :

Hi everyone,

I just want to confirm this bug still exists and the dnsmasq HUP signal workaround is successful in karmic as of 07/04/10.

Revision history for this message
Abdusamed Ahmed (sir508) wrote :

I didn't quite understand what Tony Esp post meant "Changed in network-manager (Ubuntu Lucid):
status: Confirmed → Fix Committed" Does it mean network manager 0.8 in lucid lynx has solved the problem because i really want it to get fixed. But does al_mckin 17th post denies it being fixed or 'confirmed-> fix committed"

Revision history for this message
JUAN (shwrre-13) wrote :

ok

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

We've obviously failed by not providing further information as to the state of this fix -- and I'm not even sure this ever landed as a Lucid SRU yet -- for that I'm very sorry. I'm also responsible for not getting back to this bug any sooner.

Tony, could you please give me the information as to how far you got with getting this SRU ready, and what else needs to be done to upload that to lucid-proposed? There's at least one other fix that could be bundled with this SRU, and it would be very good to have now despite how close we are to Precise being released. Seems to me like it's probably a pretty simple fix in Lucid.

I'm marking the floating task as Fix Released because I'm very certain ICS works well in later releases. If not, we can (preferably) file new bugs, or nominate the particular release.

Changed in network-manager (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in network-manager (Ubuntu Lucid):
status: Fix Committed → Won't Fix
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.