dnsmasq with enable-dbus doesn't work properly with NetworkManager

Bug #192643 reported by Steinar Bang
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
NetworkManager
Fix Released
Wishlist
dnsmasq (Ubuntu)
Invalid
Undecided
Unassigned
network-manager (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Binary package hint: dnsmasq

Ubuntu 7.10, Intel Pentium M,
dnsmasq 2.39-1
network-manager 0.6.5-0ubuntu16.7.10.0
dbus 1.1.1-3ubuntu4

I followed the instructions in /usr/share/doc/dnsmasq/DBus-interface.gz and put the line
 enable-dbus
into /etc/dnsmasq.conf

This made dnsmasq show up in the output from the dbus-monitor utility, but it didn't give the expected behaviour of /etc/resolv.conf, in cooperation with NetworkManager, which is to have /etc/resolv.conf contain just 127.0.0.1, regard less of the DHCP lease, and when be unaffected by VPNC connections going up and down.

The behaviour is as before dnsmasq was installed, which is to show the DNS information from DHCP when getting a DHCP lease, and the DNS information from the VPNC remote end, when a VPNC connection is up,

Revision history for this message
Soren Hansen (soren) wrote : Re: [Bug 192643] [NEW] dnsmasq with enable-dbus doesn't work properly with NetworkManager

On Sun, Feb 17, 2008 at 02:05:41PM -0000, Steinar Bang wrote:
> This made dnsmasq show up in the output from the dbus-monitor utility,
> but it didn't give the expected behaviour of /etc/resolv.conf, in
> cooperation with NetworkManager, which is to have /etc/resolv.conf
> contain just 127.0.0.1, regard less of the DHCP lease, and when be
> unaffected by VPNC connections going up and down.

Where is this documented?

--
Soren Hansen
Virtualisation specialist
Ubuntu Server Team
http://www.ubuntu.com/

Revision history for this message
Steinar Bang (sb-dod) wrote :

>>>>> Soren Hansen <email address hidden>:

> Where is this documented?

Network Manager
 http://www.gnome.org/projects/NetworkManager/
uses DBUS to listen for updates from eg. DHCP clients, and use that
information do mediate between different network supports.

The DBUS support of dnsmasq (how to enable it, and what methods dnsmasq
supports), is documented in this file in the dnsmasq package:
 /usr/share/doc/dnsmasq/DBus-interface.gz

DBUS is documented here:
 http://www.freedesktop.org/wiki/Software/dbus

As for concrete documentation for the NetworkManager behaviour wrt. DNS
servers, I don't have it handy, and google doesn't find any, but I will
ask on the NetworkManager mailing list.

Revision history for this message
Thierry Carrez (ttx) wrote :

dnsmasq provides the DBUS service and methods correctly, it's just that NetworkManager doesn't do what you think it should do with it (it probably doesn't call the uk.org.thekelleys.dnsmasq SetServers method when new DNS servers are received from a new DHCP lease).

In my understanding, this is not a bug in dnsmasq, it's more a missing feature in NetworkManager.
If you think this is a bug in NetworkManager, please use "Also affects..." to assign this bug to that package.

Changed in dnsmasq:
status: New → Invalid
Thierry Carrez (ttx)
Changed in network-manager:
importance: Undecided → Wishlist
Revision history for this message
Howard Chu (hyc) wrote :

This missing feature in NetworkManager was really annoying me so I wrote a patch for it, which you can find here
http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00042.html

Revision history for this message
Howard Chu (hyc) wrote :

Just a few comments on prioritizing this wishlist item - I think using this feature should be the default on any desktop install; using dnsmasq improves all name resolver lookup response times, and by eliminating rewrites to /etc/resolv.conf it makes it a lot easier to run a secure system with a read-only root partition. Also, it has a power savings benefit on laptops by avoiding the churn of rewriting the file. The whole notion of rewriting any config files in /etc as a normal matter-of-course is completely wrong-headed to begin with...

Changed in network-manager:
importance: Undecided → Unknown
Revision history for this message
Alexander Sack (asac) wrote :

there is an upstream patch pending for this. However, we support resolvconf. isnt that enough to properly hook in dnsmasq for intrepid? Switching dnsmasq to dbus that late in the cycle might not be the thing we want.

Changed in network-manager:
status: New → Incomplete
Revision history for this message
Howard Chu (hyc) wrote :

If you're referring to Gnome bug 551747, yes, I submitted that bug report and patch, but it appears to have received no attention upstream yet.

For the reasons I already listed in my previous comment, resolvconf is a poor solution. I already tried using it here; it still rewrites the disk too frequently. That's what convinced me to write the DBUS patch.

Revision history for this message
Thierry Carrez (ttx) wrote :

Patch on upstream bugtracker received no attention.
Alexander: is it something we can/should carry on our side ?

Changed in network-manager:
status: Incomplete → New
Revision history for this message
Jasonbrisbane (jason-brisbane) wrote :

Hello,

Actually it appears that network-manager creates its own dnsmasq fomr the dnsmasq-base package.
It ignore any and all settings in dnsmasq as the conf file is only set and included in the dnsmasq package (not the base).

It is called and appear with ONLY command line settings.

It appears as if there is no checking to see if the configuration file exists and if it exists to attach it instead of the default command line arguments.

Shouldnt this have been tested before release?

It would have been nice to confirm if dnsmasq was called correctly. It would solve this and my issues (where the dhcp range in dnsmasq is not what I want - I want to specify my own dhcp range and settings but these are ignored as dnsmasq.conf is not checked for and called.

Changed in network-manager:
importance: Unknown → Wishlist
status: New → Fix Released
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Closing as Fix Released since the upstream bug was also closed. All indicates that this works properly at this point.

Changed in network-manager (Ubuntu):
status: New → Fix Released
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.