Re: [Dnsmasq-discuss] dns/resolv.conf shoud follow DNS server as learned via DHCP

[Dan Williams]

On Sat, 2017-03-04 at 10:41 +0100, Rene Stoutjesdijk wrote:
> i did setup the dnsmasq to be the dns server/resolver for my clients.
> this works fine when i say that the resolver (at my dnsmasq server)
> is
> pointing towards 8.8.8.8
> 
> However, my uplink router and ISP could change, so what i'm looking
> for now
> is that the resolver doesn't point anymore to the 8.8.8.8 but follows
> the
> DNS server which i do get provided automatically by the ISP router
> (as the
> interface between the local host and the router is DHCP derived).
> ( i know it could stil work with the 8.8.8.8 but i want to explore
> this
> alternative)
> 
> Can this be achieved within dnsmasq? and if yes how.

dnsmasq should be doing this already, unless you've given it the --no-
poll option.  'man dnsmasq' says "Unless --no-poll is used, dnsmasq
checks the modification time of /etc/resolv.conf (or equivalent if --
resolv-file is used) and re-reads it if it changes."

But to debug a bit further, when you notice that dnsmasq isn't using
the same nameserver as in resolv.conf, try 'killall -HUP dnsmasq' and
see if that helps things.  dnsmasq will reread resolv.conf when sent
the HUP signal.

Dan

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Fix DNS resolution when reconnecting to VPN or other similar interfaces

[Dan Williams]

On Sat, 2016-11-12 at 20:14 -0500, Nikolay Martynov wrote:
> If interface goes down and then interface with same name brought up
> (e.g. VPN) then sending data for fds bound to this interfaces fails
> with ENODEV. Fix this by rebinding opened fd to current interface
> name.

Does this commit fix your issue too?  Something similar was already
committed upstream:

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

Dan

> Signed-off-by: Nikolay Martynov 
> ---
>  src/network.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/src/network.c b/src/network.c
> index e7722fd..af7f94f 100644
> --- a/src/network.c
> +++ b/src/network.c
> @@ -1228,8 +1228,17 @@ static struct serverfd *allocate_sfd(union
> mysockaddr *addr, char *intname)
>    /* may have a suitable one already */
>    for (sfd = daemon->sfds; sfd; sfd = sfd->next )
>  if (sockaddr_isequal(>source_addr, addr) &&
> - strcmp(intname, sfd->interface) == 0)
> + strcmp(intname, sfd->interface) == 0) {
> +#if defined(SO_BINDTODEVICE)
> +  /* Interface may have went down and reopened after we have
> + opened this sfd (e.g. VPN). This makes interface-bound fd
> + invalid.
> + Bind fd to new interface instance to avoid errors */
> +  if (intname[0] != 0)
> +setsockopt(sfd->fd, SOL_SOCKET, SO_BINDTODEVICE, intname,
> IF_NAMESIZE) == -1;
> +#endif
>    return sfd;
> +}
>    
>    /* need to make a new one. */
>    errno = ENOMEM; /* in case malloc fails. */

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Interface name in /etc/resolv.conf with network-manager

[Dan Williams]

On Mon, 2016-04-11 at 09:24 +0200, Albert ARIBAUD wrote:
> Hi Leandro,
> 
> Le Sun, 10 Apr 2016 21:42:57 +0200
> Leandro Noferini  a écrit:
> 
> > 
> > Albert ARIBAUD  writes:
> > 
> > 
> > [...]
> > 
> > > 
> > > So it would appear that dnsmasq already sends the right domain
> > > search option, and the issue is indeed with network manager.
> > So I need to notice about this bug (?) to network-manager team!
> Depends: could be a Network manager inherent bug, or a NM
> configuration
> file issue -- in the second case, this is not for the NM team to
> handle, but for the distro team.

Turns out this is an openresolv bug present in 3.7.3 that was fixed in
3.8.0.  It does not split multiple search domains.

http://roy.marples.name/projects/openresolv/info/1e6ac67eb3

Dan

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq on Ubuntu 14.04 and Network Manager

[Dan Williams]

On Tue, 2015-09-29 at 09:04 -0500, Brian Watson wrote:
> Hi,
>I had this working on Ubuntu 10.04, but now I would like to get it
> working on 14.04 with a better understanding of what's happening. On 10.04
> I installed dnsmasq without understanding that there was probably one
> already installed as part of NetworkManager. With 14.04 I would like to
> just use the version that's used by NetworkManager, but I didn't understand
> the following:

NM doesn't use a private on-disk copy of dnsmasq or anything, it uses
the normal system copy that's already installed.  But it spawns a
private *runtime* dnsmasq process to handle either (a) the local caching
nameserver functionality, or (b) the internet connection sharing
functionality.

So it depends on what you want to use dnsmasq for; which one are you
trying to do?  If it's internet connection sharing, then with the NM
0.9.8 in Ubuntu 14.04 you cannot change the address range handed to
clients on the interface.  That has been fixed in NM 0.9.10 and later
but even though that version is more than a year old, it is only
included in Ubuntu 15.04.

Typically you never really need to touch the dnsmasq that NM spawns,
because modifications are usually done through the NM configuration not
dnsmasq.  An independently installed and configured dnsmasq usually does
not conflict with NetworkManager's copy, unless:

1) you have configured the independent copy to bind to the same
interface/IP address that NetworkManager's copy is bound to, or you have
allowed the independent copy to bind to all interfaces ("*") which
obviously conflicts with the one NM spawns for interfaces it manages

2) you have enabled NM's local caching nameserver functionality and you
have configured the independent copy to do the same thing

In Ubuntu, NM and dnsmasq communicate via D-Bus, not through
configuration files.  For internet connection sharing, NM spawns and
kills its own copy for that specific interface.  For local caching DNS,
I think the dnsmasq may be started by 

Dan

> 1. The first thing I needed to do was to find the existing dnsmasq.conf so
> that I could add my changes there and there is a version in
> /etc/dbus-1/system.d/dnsmasq.conf
>  2. dnsmasq.conf - it has XML type data in it related to busconfig with
> some policies depending on the user.
>  3. Can this file be modified so that I can add an interface with an
> address range of IP addresses that I would like to use?
>  4. If I install an independent version of dnsmasq does that interfere with
> the NetworkManager one?
>  5. Where is the NetworkManager one being started from? I looked in
> /etc/init.d, but I didn't see anything for dnsmasq. I grepped the running
> processes and it shows up as running.
> 
> Best Regards,
>BW
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DBus API

[Dan Williams]

On Fri, 2015-05-22 at 09:52 -0500, richardvo...@gmail.com wrote:
 
  I can see why rereading *all* configuration would require root
  privileges, but certainly a simple refresh of the DNS information
  doesn't since that would just update internal structures and not require
  opening any additional ports, since they would already be open.
 
  Dan
 
 
 dnsmasq already does refresh the DNS server list without respawn.  It's not
 even necessary to send a signal, it detects changes to the list.
 
 See the -r and -R options.

Ah, nice.  NM already passes the -R (--no-resolv) option, so I guess
then writing custom config to /etc/NetworkManager/dnsmasq.d/ (which NM
passes using --config-dir) would suffice and dnsmasq will watch any
files in that directory?

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DBus API

[Dan Williams]

On Thu, 2015-05-21 at 13:17 -0400, Tom Metro wrote:
 I'm attempting to use DBus to set up DNS for a split-tunnel VPN using an
 environment similar to the one described in this posting:
 http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008541.html
 
 with Ubuntu 14.10 and NetworkManager wrapped around Dnsmasq. I've ran
 into some similar issues as that poster had.
 
 The main one seems to be that the Dnsmasq's SetDomainServers (and
 similar) DBus methods seem to be designed with he assumption that with
 any given installation you will have only one VPN active, or a base
 configuration using non-DBus methods and one split-tunnel VPN.
 
 I'm inferring this because SetServers and SetServersEx (and although not
 explicitly documented as such, in practice it seems SetDomainServers as
 well) are documented as Each call to SetServers [or SetServersEx]
 completely replaces the set of servers specified by via the DBus, but it
 leaves any servers specified via the command line or /etc/dnsmasq.conf
 or /etc/resolv.conf alone.
 
 The problem with the NetworkManager usage is that it doesn't use
 /etc/resolv.conf to store upstream servers nor use a Dnsmasq config
 file. It obtains the upstream servers from dhclient, then tells Dnsmasq
 about them via DBus.
 
 Consequently, if you bring up a split-tunnel VPN, and set a DNS server
 for it via DBus, it wipes out the base configuration.
 
 The above referenced thread mentions that NetworkManager has built-in
 support for split-tunnels, but that presumes NetworkManager supports the
 type of VPN connection you are using. (I'm connecting to a Juniper VPN
 that is only supported by a bleeding edge version of OpenConnect.)
 
 I'm sure thee are ways around this on the NetworkManager side. Perhaps
 some way to tell NetworkManager the additional DNS servers, and then let
 it manage Dnsmasq by sending all the servers in one batch. (I'm open to
 pointers if anyone knows how to do that.) But I'm posting to 1. confirm
 my that my understanding of Dnsmasq's DBus API is correct, and 2. to
 ask: does it makes sense that the API assumes there will never be a use
 case for incremental additions (and removal) of DNS servers? What if the
 user has multiple split-tunnel VPNs?
 
 My expectation is that a DBus caller ought to be able to set upstream
 servers one at a time, choosing whether to incrementally add them or
 supplant existing servers. (And ideally, there should be a documented
 mechanism for removing those entries.)

NM spawns a private dnsmasq though, so it is going to be under NM's
control and isn't really intended to be a system wide dnsmasq that
anything can talk to.  In this case, since NM is not able to effectively
manage resolv.conf itself (since there are some external programs that
need to adjust DNS information) you'll probably need something like
resolvconf.  Unfortunately, I don't think resolvconf can do split DNS
either.

The longer term solution here for NM is to enhance its DNS plugin
interface so that it can dump the whole set of split DNS to plugins or
scripts and let them do whatever they want, instead of having only a C
API.  Then you'd set dns=none in NM's config and manage resolv.conf and
dnsmasq on your own, by combining information from all sources (where NM
is simply one) and pushing that to your own dnsmasq.

For the short term, NM does have an /etc/NetworkManager/dnsmasq.d
directory where you can toss dnsmasq config files, which NM will pass to
dnsmasq when it spawns it.  Unfortunately, because D-Bus gets used on
Ubuntu and dnsmasq isn't respawned on changes, that won't work for you.
Ideally, dnsmasq would get some kind of SIGHUP-like signal that *would*
re-read config files too, and then you could dump your info there and
SIGxxx it and everything would be fine.

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DBus API

[Dan Williams]

On Thu, 2015-05-21 at 14:28 -0500, richardvo...@gmail.com wrote:
 
  For the short term, NM does have an /etc/NetworkManager/dnsmasq.d
  directory where you can toss dnsmasq config files, which NM will pass to
  dnsmasq when it spawns it.  Unfortunately, because D-Bus gets used on
  Ubuntu and dnsmasq isn't respawned on changes, that won't work for you.
  Ideally, dnsmasq would get some kind of SIGHUP-like signal that *would*
  re-read config files too, and then you could dump your info there and
  SIGxxx it and everything would be fine.
 
 
 Can't seem to find this in the documentation, but the reason that SIGHUP
 only rereads datafiles (hostsfile, /etc/ethers, etc) and not configuration
 has been explained before:
 
 Implementing configuration (opening port 53, among other things) requires
 root privilege.  But signals are received after dnsmasq drops root.
 Allowing full reconfiguration while dnsmasq is running would open the door
 to privilege escalation, and therefore is excluded as an intentional design
 decision.
 
 Ideally, you would fix your wrapper's behavior that dnsmasq isn't
 respawned on changes, because this behavior is wrong.

Respawning is sub-optimal because it can cause DNS dropouts during the
short window when dnsmasq isn't running, and existing requests can be
left hanging or simply fail.  This was the specific reason why Ubuntu
moved to the D-Bus interface instead of respawning, to ensure that
dnsmasq always stayed running and there was no window of downtime.

I can see why rereading *all* configuration would require root
privileges, but certainly a simple refresh of the DNS information
doesn't since that would just update internal structures and not require
opening any additional ports, since they would already be open.

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCP simultaneous with static addresses and autoconf

[Dan Williams]

On Fri, 2015-03-27 at 15:51 -0400, Laine Stump wrote:
 (the following is on RHEL, Fedora, and CentOS clients; I'm not sure what
 behavior is on other platforms.)
 
 First, a question about client behavior (i.e. not specific to dnsmasq):
 
 I noticed a long time ago that IPv4 clients configured for both static
 IP addresses and dhcp would discard the static IP addresses in favor of

NetworkManager (which is default on Fedora, RHEL, and CentOS for
many/most installs) will quite happily allow both IPv4 static and DHCP
addresses to co-exist and will manage each appropriately.  You're right
that there's no reason for that not to work.  It's not typically exposed
from some GUI clients because it's an unusual configuration; but it's
explicitly supported by NM itself when then configuration specifies it.

 the one from dhcp. Likewise, I found the same behavior for IPv6 when
 checking it for this bug report:
 
   https://bugzilla.redhat.com/show_bug.cgi?id=1113983
 
 This is different from IPv6 autoconf behavior - you can configure a
 static IP and set autoconf, and you will end up with both IP addresses.

Right.

 I don't see any reason why a client shouldn't behave the same with dhcp
 - just keep the static address and add the address from dhcp, and am
 thinking this is just a deficiency in the dhcp client implementation (in
 this case ISC dhclient). Is there anything in the DHCP standard that I'm

If you're using plain dhclient (and not NM), then I'd think it would be
a deficiency in the RHEL/Fedora dhclient-script then, not dhclient
itself.  dhclient itself doesn't care about the interface configuration,
it's up to /usr/sbin/dhclient-script to take the DHCP server's reply and
apply it to the interface.

 overlooking that would preclude static + dhcp ( + autoconf) on the same
 interface from working?

I don't think the DHCP standards care at all, but I'm not an expert.

 And now to a question about dnsmasq - libvirt uses dnsmasq for DNS, DHCP
 (v4 and v6), and RA. I've just noticed that when I enable dhcpv6,
 clients are no longer able to get an IPv6 via autoconf (i.e. when
 they're configured to only use autoconf). Is this expected, or a
 bug/configuration problem?

This could be a misconfiguration or a bug in dnsmasq, I'll let Simon
answer that.

If you set the A bit in the RA's Prefix Information option, that says
clients can use the given prefix to autoconfigure an address.  If you
set either of the M or O bits in the RA header, then DHCPv6 will be
invoked.  These are independent of each other.

It sounds like when dnsmasq is configured for DHCPv6, it turns off the A
bit which prevents clients from using the prefix for an autoconf
address.  While that would typically be done when using the M flag
(since M implies you are using full DHCP leases and thus probably don't
want autoconf) it's not prohibited in anyway that I know of, so perhaps
dnsmasq just doesn't have a knob to keep A=1 when M=1?  Just a guess.

Dan

 This is my dnsmasq version: dnsmasq-2.72-3.fc21.x86_64
 
 The dnsmasq commandline:
 
 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/ipv6.conf
 --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper
 
 and ipv6.conf:
 
 strict-order
 domain=test.lainetest.org
 expand-hosts
 pid-file=/var/run/libvirt/network/ipv6.pid
 except-interface=lo
 bind-dynamic
 interface=virbr1
 dhcp-range=192.168.123.2,192.168.123.254
 dhcp-no-override
 dhcp-range=x:x:x:x::2,x:x:x:x::200
 dhcp-lease-max=764
 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/ipv6.hostsfile
 addn-hosts=/var/lib/libvirt/dnsmasq/ipv6.addnhosts
 enable-ra
 
 This is the config file when there is no dhcp-range defined for the network:
 
 strict-order
 domain=test.lainetest.org
 expand-hosts
 pid-file=/var/run/libvirt/network/ipv6.pid
 except-interface=lo
 bind-dynamic
 interface=virbr1
 dhcp-range=192.168.123.2,192.168.123.254
 dhcp-no-override
 dhcp-lease-max=253
 dhcp-hostsfile=/var/lib/libvirt/dnsmasq/ipv6.hostsfile
 addn-hosts=/var/lib/libvirt/dnsmasq/ipv6.addnhosts
 dhcp-range=x:x:x:x::1,ra-only
 
 (in this case, autoconf works correctly).
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Problem in DHCPv6

[Dan Williams]

On Wed, 2014-07-23 at 13:45 +0200, Lorenzo Milesi wrote:
  If I understood correctly, you will have to send router advertisements
  from your default router (apparently you need to do this from the
  router, with IPv6) using e.g. radvd to advertise the prefix length.
 
 Setting the RA on the router in Managed mode and commenting enable-ra 
 worked, thanks.

DHCPv6 is meant to be used in conjunction with router advertisements,
and is not a mechanism to deliver a default gateway/router to clients.
That is what RA is for.  If you're not delivering actual options (DNS,
search domains, etc) with DHCP, you might re-evaluate whether you need
to use DHCP at all.  RA might be all you need.

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnssec and local caching dns in fedora and network manager

[Dan Williams]

On Mon, 2014-04-14 at 09:31 +0100, Simon Kelley wrote:
 On 13/04/14 21:24, Dave Taht wrote:
  interesting long thread over at the fedora project this weekend:
  
  https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
  
 
 I'm quite a long way through it already. The main takehome seems to be
 that captive portals are even more broken in the era of DNSSEC than
 before. It's amazing that's even possible..

They are quite awful.  They were always awful.  But with 10+ years of
captive portal hackage, it's pretty much on the DNSSEC implementors to
either (a) change every captive portal to work, or (b) figure out how to
work around the problem.  A combination of the two is the right path,
but nobody is going to get all captive portals to follow a spec.

There is Hotspot 2.0 (and the older WISPR) that at least automates the
process so that you *know* you're connected to a captive portal and
sometimes you can automatically log in using the SIM card in your device
or other cached credentials.  Usually used by phones and providers to
automatically roam to WiFi networks your provider has affiliations with.

This is where the standardization work is going on for hotspot stuff.

Dan

 Maybe the IETF should create a sane spec for such things
 
 
 
 Simon.
 
  
  
  -- Forwarded message --
  From: Chuck Anderson c...@wpi.edu
  Date: Sun, Apr 13, 2014 at 10:59 AM
  Subject: Re: [Cerowrt-devel] Full blown DNSSEC by default?
  To: cerowrt-de...@lists.bufferbloat.net
  
  
  On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote:
 
  Is there a D?
 
  Running a full resolver in cerowrt? I've been running a dnssec-enabled 
  bind for some time on my boxes (prior to dnssec support in dnsmasq).
  
  How do these proposals compare with unbound+dnssec-trigger in the
  Fedora world?  I stirred up a rats nest:
  
  https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
  
  I realize these are slightly different use cases, but it may be
  helpful to learn from the different implementations, if for no other
  reason than to be sure they interoperate.  I'm going to turn on
  unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC
  turned on to see what happens...
  ___
  Cerowrt-devel mailing list
  cerowrt-de...@lists.bufferbloat.net
  https://lists.bufferbloat.net/listinfo/cerowrt-devel
  
  
 
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq, NetworkManager and VPNs

[Dan Williams]

On Thu, 2014-03-06 at 12:39 +1100, Tony Breeds wrote:
 Hi All,
 I'm a new user of dnsmasq and I can't see an easy way to do what
 I want to do.
 
 My situation is (probably not that uncommon) I need to connect to a work
 VPN and while I'm connected to said VPN I need to query work's DNS
 servers for company.com addresses but all other queries should go
 through my normal (as supplied by DHCP) DNS servers.
 
 I tried adding a config file like:
 server=/company.com/DNS_SERVER_1@interface
 server=/company.com/DNS_SERVER_2@interface
 server=/I.P.ADDR.in-addr.arpa/DNS_SERVER_1@interface
 server=/I.P.ADDR.in-addr.arpa/DNS_SERVER_2@interface
 
 Now my problem is that if that file exists when dnsmasq starts and my
 VPN interface isn't up, dnsmasq prints an error and exits.  This is
 especially painful as I'm starting dnsmasq from NetworkManager (by
 setting dns=dnsmasq in the NetworkManager config file)

If you're using dns=dnsmasq, then NetworkManager will automatically do
split DNS exactly as you describe, as long as your VPN returns a DNS
domain (or you specify one yourself).  Is this not working?

(the 'bind-interfaces' note is not for DNS, it's NM's Internet
Connection Sharing feature, which also uses dnsmasq.  Since this
requires a very specific setup on the private interface, it's always
incompatible with a system-configured dnsmasq.  But if you don't use
bind-interfaces with the system-configured dnsmasq, then the private
copy for ICS on the private interface doesn't work, becuase the
system-configured one has already bound to the DHCP and DNS ports on
that interface)

Dan

 I can run a script that adds and removes the config file on VPN up/down
 events but I can't find a way to re-read all the config files for a
 running dnsmasq process.
 
 My next thought was to use the dbus interface to inject the above
 configuration to the running dnsmasq server, but I don't see a syntax
 that will remove the configuration when I take down my VPN.
 
 So any advice? this must be possible, perhaps I just need to be more
 creative.
 
 Tony.
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Why is dnsmasq reading /var/run/dnsmasq/resolv.conf twice when it starts up?

[Dan Williams]

On Thu, 2013-10-03 at 17:05 +0100, Chris Green wrote:
 On Thu, Oct 03, 2013 at 04:42:59PM +0100, Simon Kelley wrote:
  On 03/10/13 16:29, Chris Green wrote:
  When I start dnsmasq I see the following in syslog:-
  
  Oct  3 16:09:03 revo dnsmasq[2819]: started, version 2.63rc6 cachesize 150
  Oct 3 16:09:03 revo dnsmasq[2819]: compile time options: IPv6 GNU-getopt 
  DBus i18n IDN DHCP DHCPv6 
  Oct 3 16:09:03 revo dnsmasq-dhcp[2819]: DHCP, IP range 192.168.1.80 -- 
  192.168.1.150, lease time 1h 
  Oct  3 16:09:03 revo dnsmasq[2819]: using local addresses only for domain 
  zbmc.eu
  Oct  3 16:09:03 revo dnsmasq[2819]: reading /var/run/dnsmasq/resolv.conf
  Oct  3 16:09:03 revo dnsmasq[2819]: ignoring nameserver 192.168.1.2 - 
  local interface
  Oct  3 16:09:03 revo dnsmasq[2819]: using nameserver 194.72.0.114#53
  Oct  3 16:09:03 revo dnsmasq[2819]: using nameserver 212.159.6.10#53
  Oct  3 16:09:03 revo dnsmasq[2819]: ignoring nameserver 127.0.0.1 - local 
  interface
  Oct  3 16:09:03 revo dnsmasq[2819]: using local addresses only for domain 
  zbmc.eu
  Oct  3 16:09:03 revo dnsmasq[2819]: read /etc/hosts - 12 addresses
  Oct 3 16:09:03 revo dnsmasq-dhcp[2819]: not giving name revo.zbmc.eu to 
  the DHCP lease of 192.168. 
  Oct 3 16:09:03 revo dnsmasq-dhcp[2819]: not giving name revo to the DHCP 
  lease of 192.168.1.148 be 
  Oct  3 16:09:05 revo dnsmasq[2819]: reading /var/run/dnsmasq/resolv.conf
  Oct  3 16:09:05 revo dnsmasq[2819]: ignoring nameserver 192.168.1.2 - 
  local interface
  Oct  3 16:09:05 revo dnsmasq[2819]: using nameserver 194.72.0.114#53
  Oct  3 16:09:05 revo dnsmasq[2819]: using nameserver 212.159.6.10#53
  Oct  3 16:09:05 revo dnsmasq[2819]: ignoring nameserver 127.0.0.1 - local 
  interface
  Oct  3 16:09:05 revo dnsmasq[2819]: using local addresses only for domain 
  zbmc.eu
  
  Why is it doing everything twice?
  
  Probably because whatever populates /var/run/dnsmasq/resolv.conf
  alters the modification time just after it starts dnsmasq.
  
 That makes sense I guess!

While I don't know how Ubuntu has configured it, NetworkManager spawns a
private instance of dnsmasq to handle local caching nameserver if you've
configured that in /etc/NetworkManager/NetworkManager.conf.  Otherwise,
it might be some interaction between resolvconf (a resolv.conf manager
that Debian-based systems use) and dnsmasq that's set up outside
NetworkManager.

Dan

  
  While I'm about it, what creates/populates /var/run/dnsmasq/resolv.conf?
  
  We need more context to have a hope of answering that.
  
 OK.  As you may gather I'm playing about a bit with my dnsmasq
 configuration on the server machine at 192.168.1.2.  It's a small Acer
 Revo machine running Ubuntu 12.10.
 
 I recently changed ISP and thus needed to change the DNS servers that
 dnsmasq uses upstream of itself.  That was my first problem because I
 couldn't find where these are set.  I *think* I have found it now,
 they're in the files in /etc/NetworkManager/system-connections.  I have
 in Wired connection 1:-
 
 [802-3-ethernet]
 duplex=full
 mac-address=00:01:6C:6C:C7:9B
 
 [connection]
 id=Wired connection 1
 uuid=2262541a-2106-4e4d-b2b7-ab631dddcbf1
 type=802-3-ethernet
 timestamp=1361810287
 
 [ipv6]
 method=ignore
 
 [ipv4]
 method=manual
 dns=127.0.0.1;212.159.6.9;212.159.13.49;
 dns-search=zbmc.eu;
 addresses1=192.168.1.2;24;192.168.1.1;
 may-fail=false
 
 Presumably (relating to the other thread) I can add a 'manual' ipv4
 section like the one above to the file in the same directory that
 relates to the wireless interface.
 
 The doing things twice was just something I noticed, probably
 NetworkManager is doing things at boot time and happens, as you said, to
 change the file just after dnsmasq reads it.  Not a big issue really, it
 only happens at boot time I think.
 
 
 Hopefully all these things are resolved now and I can leave the list in
 peace.  However I did have one issue where, after rebooting the dnsmasq
 server machine nothing worked at all (i.e. no DNS or DHCP) until I
 manually restarted dnsmasq itself.  I'll try it all again, carefully,
 and see if the same happens again.
 



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] IPv6 link-local addresses and listen-address parameter

[Dan Williams]

On Sun, 2013-08-04 at 19:43 +0545, Phil Davis wrote:
 In a valid IPv4 configuration, the IP address of every interface on a 
 device has to be different. So the --listen-address parameter specifies 
 particular IPv4 addresses, and those are unique on the box, each IPv4 
 address appears on 1 and only 1 interface. So --listen-address is easily 
 used to specify what is required, without needing --interface.
 In IPv6, the link-local address can be the same on multiple interfaces. 
 This can happen by design - e.g. every LAN interface on a router is set 
 to fe80::1 - or in a scenario with some sort of virtual interfaces 
 running on a physical NIC, the software might use the same underlying 
 MAC address of the NIC to generate the link-local address. So all the 
 VPN interfaces, or VLAN interfaces or whatever turn out to have the same 
 link-local address. I believe this is all valid in IPv6. (Stop here and 
 tell me if it is not!)
 This makes it not possible to use --listen-address for IPv6 link-local 
 addresses that appear on multiple interfaces. (unless you do happen to 
 want to listen on them all)
 If you want to listen to both IPv4 and IPv6 on a set of interfaces, then 
 you can use --interface and/or --except-interface - but that can also be 
 tricky IP alias interfaces (eg eth1:0) cannot be used with 

IP alias interfaces actually aren't interfaces at all.  They just look
that way in 'ifconfig', but nowhere else.  What 'ifconfig' shows as an
alias interface is actually just an IP address with a label.  If you
set up an alias interface, try:

cat /proc/net/dev
ls /sys/class/net
ip link show

and you won't see the alias interface anywhere, because it's not
actually an interface...  which is why you can't use actualy use it with
--interface or --except-interface.  Aliases are actually just extra IP
addresses, and ifconfig simply can't handle them.

Dan

 *--interface* or *--except-interface* options, use --listen-address 
 instead. And what if someone does want to listen to some mixture of 
 IPv4 and IPv6 addresses on particular interfaces.
 There is a discussion about this on pfSense: 
 http://forum.pfsense.org/index.php/topic,65109.msg353680.html#msg353680
 My question is, when an IPv6 address is duplicated on multiple 
 interfaces, is there a way to specify listening on a particular 
 combination of IPv6 address+interface?
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Cannot assign IPv6 address for /96 subnet

[Dan Williams]

On Fri, 2013-03-01 at 16:58 -0500, Pavel Simerda wrote:
 - Original Message -
  From: Joakim Langlet joakim.lang...@seaview.se
  
  Pavel and Dan,
  Thank you for your answers. It makes it a lot easier for me to
  understand the problems I have with Ubuntu 12.04 and also Debian
  Wheezy RC-1 currently.
 
 No problem, feel free to ask more questions.
 
  I use DHCPv6 for address assignment (nicely serviced by dnsmasq) and
  radvd is used to announce the /96 networks. This all works. I get an
  address and a /96 route, but unfortunately there is also an
  additional route (/64) added.
 
 Sounds wrong.
 
  This additional route screws up routing to other /96 networks (locally).
 
 Are you sure? A /96 route should always take precedence over a /64 route, as 
 it is more specific.
 
  I ask for your advice, should I consider this additional (bad) route
  being a kernel bug or is it more likely something Debian specific?
 
 If it is a kernel bug (and I don't think so), then the /64 route is a 
 kernel-originated route and it will appear even without the DHCP client. If 
 it only appears when you run DHCP client, it is most likely a bug in the DHCP 
 client itself. If it appears when DHCP client is run by NetworkManager, it is 
 more likely a bug in NetworkManager.

And if you're not running NetworkManager, then it's a bug in
dhclient-script, or whatever script you're using to apply the DHCP
configuration.  Again, by default dhclient tells the script to use
a /64, which is wrong.

Dan

 Also, kernel routes tend to have preferred life time and valid lifetime set 
 (and different from each other).
 
  I am prepared to dig into the source to find it
  
  It seems like the additional route is added by *default*. It has the
  same prefix as announced by the router, but cut down to /64.
  
  I have a temporary fix for it. I simply look for it in the routing
  table and delete the extra route using script, but it would be nice to
  track down the real reason so that it gets solved.
 
 Agreed.
 
  Again, thanks a lot for your answers on DHCPv6. It all makes much
  more sense now.
 
 Thanks for your interest.
 
 Cheers,
 
 Pavel



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Cannot assign IPv6 address for /96 subnet

[Dan Williams]

On Sat, 2013-02-23 at 12:24 +0100, Joakim Langlet wrote:
 tis 2013-02-19 klockan 18:02 -0600 skrev Dan Williams:
  On Tue, 2013-02-19 at 21:06 +, Simon Kelley wrote:
   So, I did some testing. I configured an server interface with 
   prefix-length 96, and configured dnsmasq with a dhcp-range and 96 prefix.
   
   Using dhclient, I got a lease successfully.
   
   The only problem is that dhclient configured the client's interface with 
   prefix-length 64.
   
   I moment's thought shows that this is expected: there is nowhere in the 
   DHCPv6 messages for the prefix-length information to be passed to the 
   client. There _is_ a prefix-length field in router-advertisements. but 
   AFAIK, there's no way for the DHCPv6 client to use that information.
   
   Of course if you're using RA for address-allocation, using SLAAC, the 
   prefix length has to be 64 anyway.
  
  We had this discussion for NM a long time back.  dhclient hardcodes the
  prefix to /64 because there's no agreement in the standards on prefixes,
  and last I knew, DHCPv6 didn't even have a prefix/netmask option.  It
  turns out that's kinda pointless anyway, so we ignore that /64 from
  dhclient and hardcode it to /128 or something like that.
  
  But the point is, until standards get changed and dhclient updates to
  use them, you're stuck wtih a /64 or whatever you choose to override
  that as.
  
  Dan
  
  
  ___
  Dnsmasq-discuss mailing list
  Dnsmasq-discuss@lists.thekelleys.org.uk
  http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
 
 Hi Dan, Simon and all others,
 
 I have had similar issues with /96 prefix and dhclient in connection to
 my Raspberry Pi based dual-stack router.
 
 Initially, I hoped to use SLAAC for some client computers but no
 implementation use the room in the standard.
 
 In RFC2462 the following is stated in section 5.5.3 (RA processing
 bullits)
 
 
 d) If the prefix advertised does not match the prefix of an address
already in the list, and the Valid Lifetime is not 0, form an
address (and add it to the list) by combining the advertised
prefix with the link's interface identifier as follows:
 
|128 - N bits   |   N bits   |
+---++
|link prefix|  interface identifier  |
++
 
 
If the sum of the prefix length and interface identifier length
does not equal 128 bits, the Prefix Information option MUST be
ignored.  An implementation MAY wish to log a system management
error in this case. It is the responsibility of the system
administrator to insure that the lengths of prefixes contained in
Router Advertisements are consistent with the length of interface
identifiers for that link type. Note that interface identifiers
will typically be 64-bits long and based on EUI-64 identifiers as
described in [ADDR-ARCH].
 
If an address is formed successfully, the host adds it to the
list of addresses assigned to the interface, initializing its
preferred and valid lifetime values from the Prefix Information
option.
 
 There is nothing here that prevents using a longer prefix length
 than /64. It only states that it *typically* be /64 and use EUI-64.

For RA, yes.  Any prefix is allowed there.  But DHCPv6 is different.  I
can't recall all the details of why we decided to ignore dhclient's
prefix option for NM and lock it to /128, but Pavel Simerda does and I'm
cc-ing him on this message so he can weigh in on this.

Dan

 An implementation that fulfills the ambition to be policy-free and as
 useful as possible, could in my view be more flexible and creative.  
 
 If the prefix-length in the RA is greater than /64, one could start with
 shaving of the inserted midbits of the EUI-64 identifier. If that is
 not enough, shave off bits from the left. The risk of dual address
 allocation is still *very* small and the DAD mechanism could be used as
 well.
 
 This would allow SLAAC on prefixes longer than /64 without actually
 *breaking* RFC2462 rules (in my view). An additional bit in /proc could
 enable/disable the extension (default off). 
 
 In combination with DAD, it should be pretty safe. Small networks, such
 as my 6RD-allocation, could use this feature. Larger networks will have
 larger allocations (maybe /48) and would not enable this behavior.
 
 As you have discussed, the DHCPv6 lacks a prefix option. As an
 intermediate solution to this in the clients, it would be nice if there
 was an option to trust the prefix of the RAs. Then, a correct prefix
 (in most cases) would be allocated. If the last received prefix from an
 RA was always saved and accessible from /proc, that could be used if
 its validity (receive time related

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 11:48 -0500, Gene Czarcinski wrote:
 On 02/10/2013 08:57 PM, Dan Williams wrote:
  Best to test with is git master or the 0.9.7.995 release.
 Too late ... I am running 0.9.7.997

I lied and I actually mean 0.9.7.997 :)

 So far things are working well (no problems).
 
 I finally figured out that the easiest way to specify the duid-default 
 so that I would be using duid-LL is to take the colon separated hex 
 digits and converting them to back-slash separated 3-digit octal numbers 
 and ignore the other stuff dhclient does. This seems acceptable to dhclient.

Yep, those are the dhclient escape rules.

 If I delete everything but the first line in the lease file and then use 
 the above to set the LL this works.
 
 I still do not understand how/why duid-UUID gets used as the current 
 default is duid-LLT.  And, I would still like an option to specify that 
 duid-LL be used but, if not acceptable for the regular NetworkManager 
 distribution, then I can handle it as a local patch.

The option you're looking for *is* to set default-duid in the lease
file.  That's exactly how you tell NM to use the DUID you want.
Otherwise, NM will generate the DUID-UUID.

As I mentioned in other mails to this thread, the DUID-UUID gets used
for a number of reasons (all quotes from RFC 3315):

1) the RFC specifies that the DUID is *per machine*, not per-interface,
and that one DUID is used for any client run on that machine.
Furthermore, the DUID must be globally unique.

2) A machine may contain more than one network interface and since under
Linux, interface enumeration is not stable, there's no way to
consistently choose which interface to use for the DUID-LL.  Since the
RFC indicates that the same DUID should be used for all interfaces
(each DHCP client and server should have exactly one DUID), it's
really a toss-up which interface is the main interface from which we
should generate the machine-wide DUID.

3) Since the RFCs state that the DUID should not change as a result of
changes to network interfaces, addition/removal of hardware, etc (a
device's DUID should not change as a result of a change in the device's
network hardware) this implies that it must be stored somewhere.  This
causes a problem when network booting or cloning system images, since a
stored DUID would be used for all machines and would no longer be
globally unique as required by #1.  Since /etc/machine-id is already
supposed to be globally unique, it must already be handled by the
cloning/network-boot case, and thus we can use it as a basis for the
DUID-UUID without creating extra work for the administrator.

But again, you're free to override this behavior by modifying the
default leasefile in /etc/dhclient6.leases with whatever DUID you
desire.

Dan



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 15:34 -0500, Gene Czarcinski wrote:
 On 02/10/2013 09:09 PM, Dan Williams wrote:
  On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote:
 snip
  Unfortunately, what you have done is not going to scratch my itch!
 
  First, I would like a bit of clarification.  Is the DUID-UUID going to
  be per system or per network interface?  By per system I mean that all
  interfaces would have the same DUID-UUID.
  Correct.  We're working off RFC-3315, which has sections stating that
  the DUID used by a client or server SHOULD NOT change over time if at
  all possible; for example, a device's DUID should not change as a result
  of a change in the device's network hardware. (section 9)
 
  Which implies that even if you change a network interface, the DUID
  should not change.  Which also implies one DUID *per machine*, not
  per-interface.  It's also supposed to be globally unique, which means
  you should not use the same DUID for multiple machines or VMs (section
  9).
 
  Even if we used a DUID-LL or LLT, RFC-3315 states that the DUID is
  generated from any one network interface that is connected to the DHCP
  device at the time that the DUID is generated.  It doesn't say that the
  DHCP client process must use a separate DUID for each interface it's run
  on, though NM supports per-connection DUIDs.
 
  That said, you're perfectly able to put whatever DUID you want to
  in /etc/dhclient6.leases (or /var/lib/dhcp/dhclient6.leases
  or /var/lib/dhclient/dhclient6.leases) and NM will use that instead of
  generating a DUID-UUID.
 
  Now, what I want/need is the have a DUID which is predictable and fixed
  for an interface on a hardware system.  The hardware system supports
  multi-boot of different installations such as a Fedora 17 system and a
  Fedora 18 system.  I have a firm, learned the hard way, rule never to
  destroy a working systems ... all my installs are fresh installs into
  different partition, LVs, or btrfs-subvolumes. I want to be able to boot
  these system up and have them all use the same DUID.
  Apparently that's against RFC-3315 section 9: The motivation for having
  more than one type of DUID is that the DUID must be globally unique...
 
  But again, you can override with dhclient6.leases.
 
  The reason for wanting this predictable, unchanging DUID is that I want
  my dnsmasq server to assign this system a specific IPv6 address without
  having to manually configure the system.  This specific IPv6 address is
  used for routing IPv6 address of virtual guests running on that system.
 
  I checked and /etc/machine-id differs on each installed system.  For me,
  the DUID-UUID is no better than DUID-LLT.
  That's what we've got for the standards, unfortunately.  But again,
  you're free to override this on every machine
  with /etc/dhclient6.leases.
 
  However, I suspect that there are situations where DUID-UUID is the
  correct solution.
  Yeah, we identified a few.
 
  Given these two different approaches/solutions, what I would like to see
  is to optionally do either one (on a per interface basis).  If the value
  of DUID-UUID is kept in the interface configuration file, then maybe
  that could be extended so the DUID-LL could be specified (DUID-LLT is
  the default for dhclient if nothing else is done).  How is dhclient
  told to use a specific DUID-UUID value?
  According to the standards, you're supposed to use one DUID *per
  machine* and that DUID must be globally unique.  So what you're trying
  to do here apparently contravenes the standards in a couple of ways.
  But even so, you're certainly able to do what you want by specifying the
  DUID in /etc/dhclient6.leases or connection-specific lease files by
  putting this line in the file:
 
  default-duid your escaped DUID;
 
  And NM will happily use it; since you're the administrator, we're not
  forcing you to use DUID-UUID.
 Oops, you are correct.  The standard does say one DUID per device and 
 the same DUID for every network interface on that device.
 
 I have not tried this but what happens when you have more than on 
 network interface and they are all connect to the same network and all 
 using DHCPv6.  If each is connected to a different network then things 
 should work correctly.
 
 But, RFC3315 also says per device which to me means per hardware 
 device not per OS installation.  I am not sure how you do that but that 
 is my interpretation.  The only thing that comes close is duid-LL and 
 that has a problem when there are multiple network interfaces.  BTW, 
 this whole business with client-id is because the client-id did differ 
 between a Fedora 17 and a Fedora 18 installation which caused some 
 things to stop working.

Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to
dhcleint, which appears to generate a default DUID itself; but the
NetworkManager code will honor that existing DUID if it finds it in the
interface+connection specific lease file [1].  If NM does *not*, please
let

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 15:46 -0500, Gene Czarcinski wrote:
 On 02/11/2013 12:13 PM, Dan Williams wrote:
  The option you're looking for*is*  to set default-duid in the lease
  file.  That's exactly how you tell NM to use the DUID you want.
  Otherwise, NM will generate the DUID-UUID.
 See my other message.  This appears to be not working.
 
 Do you want me to create a bugzilla report on this?
 
  As I mentioned in other mails to this thread, the DUID-UUID gets used
  for a number of reasons (all quotes from RFC 3315):
 
  1) the RFC specifies that the DUID is*per machine*, not per-interface,
  and that one DUID is used for any client run on that machine.
  Furthermore, the DUID must be globally unique.
 Well, actually, I believe it says per device.  Also, RFC6355 says that 
 the only solution they consider is firmware based which /etc/machine-id 
 is not or it would not vary between OS installs.

Now I see what you're saying; I think there's a case to be made for
generating /etc/machine-id from whatever firmware information is
available if requested by the system administrator. Essentially,
machine-id *should* be the abstraction from getting that ID from CPUID,
BIOS Asset Number, NVRAM, whatever.  But neither NM itself nor dhclient
should really be in the business of doing that.

So I think we should push for getting machine-id to optionally (or even
by default) generate the ID from hardware/firmware information if
possible.  At the moment, the only requirement that machine-id does
*not* fulfill from 6355 is the OS reinstall one, so (a) it's the best
we've got so far, and (b) we can work to make it more 6355-compliant.

Dan

  2) A machine may contain more than one network interface and since under
  Linux, interface enumeration is not stable, there's no way to
  consistently choose which interface to use for the DUID-LL.  Since the
  RFC indicates that the same DUID should be used for all interfaces
  (each DHCP client and server should have exactly one DUID), it's
  really a toss-up which interface is the main interface from which we
  should generate the machine-wide DUID.
 
  3) Since the RFCs state that the DUID should not change as a result of
  changes to network interfaces, addition/removal of hardware, etc (a
  device's DUID should not change as a result of a change in the device's
  network hardware) this implies that it must be stored somewhere.  This
  causes a problem when network booting or cloning system images, since a
  stored DUID would be used for all machines and would no longer be
  globally unique as required by #1.  Since /etc/machine-id is already
  supposed to be globally unique, it must already be handled by the
  cloning/network-boot case, and thus we can use it as a basis for the
  DUID-UUID without creating extra work for the administrator.
 
  But again, you're free to override this behavior by modifying the
  default leasefile in /etc/dhclient6.leases with whatever DUID you
  desire.
 I had considered /etc/dhclient6.leases and rejected it but I do not 
 remember why.  Now, it seems like the right solution.  Since almost 
 all my installs use kickstart, I could set this in my post-install script.
 
 I think I have beaten this dead horse more than enough.
 
 Gene
 
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 15:06 -0600, Dan Williams wrote:
 On Mon, 2013-02-11 at 15:34 -0500, Gene Czarcinski wrote:
  On 02/10/2013 09:09 PM, Dan Williams wrote:
   On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote:
  snip
   Unfortunately, what you have done is not going to scratch my itch!
  
   First, I would like a bit of clarification.  Is the DUID-UUID going to
   be per system or per network interface?  By per system I mean that all
   interfaces would have the same DUID-UUID.
   Correct.  We're working off RFC-3315, which has sections stating that
   the DUID used by a client or server SHOULD NOT change over time if at
   all possible; for example, a device's DUID should not change as a result
   of a change in the device's network hardware. (section 9)
  
   Which implies that even if you change a network interface, the DUID
   should not change.  Which also implies one DUID *per machine*, not
   per-interface.  It's also supposed to be globally unique, which means
   you should not use the same DUID for multiple machines or VMs (section
   9).
  
   Even if we used a DUID-LL or LLT, RFC-3315 states that the DUID is
   generated from any one network interface that is connected to the DHCP
   device at the time that the DUID is generated.  It doesn't say that the
   DHCP client process must use a separate DUID for each interface it's run
   on, though NM supports per-connection DUIDs.
  
   That said, you're perfectly able to put whatever DUID you want to
   in /etc/dhclient6.leases (or /var/lib/dhcp/dhclient6.leases
   or /var/lib/dhclient/dhclient6.leases) and NM will use that instead of
   generating a DUID-UUID.
  
   Now, what I want/need is the have a DUID which is predictable and fixed
   for an interface on a hardware system.  The hardware system supports
   multi-boot of different installations such as a Fedora 17 system and a
   Fedora 18 system.  I have a firm, learned the hard way, rule never to
   destroy a working systems ... all my installs are fresh installs into
   different partition, LVs, or btrfs-subvolumes. I want to be able to boot
   these system up and have them all use the same DUID.
   Apparently that's against RFC-3315 section 9: The motivation for having
   more than one type of DUID is that the DUID must be globally unique...
  
   But again, you can override with dhclient6.leases.
  
   The reason for wanting this predictable, unchanging DUID is that I want
   my dnsmasq server to assign this system a specific IPv6 address without
   having to manually configure the system.  This specific IPv6 address is
   used for routing IPv6 address of virtual guests running on that system.
  
   I checked and /etc/machine-id differs on each installed system.  For me,
   the DUID-UUID is no better than DUID-LLT.
   That's what we've got for the standards, unfortunately.  But again,
   you're free to override this on every machine
   with /etc/dhclient6.leases.
  
   However, I suspect that there are situations where DUID-UUID is the
   correct solution.
   Yeah, we identified a few.
  
   Given these two different approaches/solutions, what I would like to see
   is to optionally do either one (on a per interface basis).  If the value
   of DUID-UUID is kept in the interface configuration file, then maybe
   that could be extended so the DUID-LL could be specified (DUID-LLT is
   the default for dhclient if nothing else is done).  How is dhclient
   told to use a specific DUID-UUID value?
   According to the standards, you're supposed to use one DUID *per
   machine* and that DUID must be globally unique.  So what you're trying
   to do here apparently contravenes the standards in a couple of ways.
   But even so, you're certainly able to do what you want by specifying the
   DUID in /etc/dhclient6.leases or connection-specific lease files by
   putting this line in the file:
  
   default-duid your escaped DUID;
  
   And NM will happily use it; since you're the administrator, we're not
   forcing you to use DUID-UUID.
  Oops, you are correct.  The standard does say one DUID per device and 
  the same DUID for every network interface on that device.
  
  I have not tried this but what happens when you have more than on 
  network interface and they are all connect to the same network and all 
  using DHCPv6.  If each is connected to a different network then things 
  should work correctly.
  
  But, RFC3315 also says per device which to me means per hardware 
  device not per OS installation.  I am not sure how you do that but that 
  is my interpretation.  The only thing that comes close is duid-LL and 
  that has a problem when there are multiple network interfaces.  BTW, 
  this whole business with client-id is because the client-id did differ 
  between a Fedora 17 and a Fedora 18 installation which caused some 
  things to stop working.
 
 Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to
 dhcleint, which appears to generate a default DUID itself

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 16:29 -0500, Gene Czarcinski wrote:
 On 02/11/2013 04:12 PM, Dan Williams wrote:
  See my reply to your other mail about this; I see what you're saying
  now, and I think we can push for having whatever generates machine-id
  (often systemd) pull that information from firmware/hardware rather than
  generating it randomly.
 Success!  Thank you.  That does scratch my itch.
 
 So long as it does not vary, I can plug it into dnsmasq with fixed IPv6 
 addresses and it will work.

Well, it turns out that machine-id is confusingly named, and that it's
actually the install id and is meant to change whenever the OS is
reinstalled.  So we're kinda stuck here; either we try to follow the
standards to the end of the earth and start
parsing /sys/class/dmi/id/product_id (which apparently is often
1234567890) or we just go off machine-id and understand that
reinstalling the OS on the same hardware will change the DUID.

My believe is that using DUID-UUID generated from /etc/machine-id is
more standards-compliant and less error-prone than using DUID-LL or
DUID-LLT though.  And, of course, it can always be overridden.

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 16:42 -0500, Gene Czarcinski wrote:
 On 02/11/2013 04:06 PM, Dan Williams wrote:
 
  Fedora 17 and 18, until 0.9.7.997, left the DUID behavior up to
  dhcleint, which appears to generate a default DUID itself; but the
  NetworkManager code will honor that existing DUID if it finds it in the
  interface+connection specific lease file [1].  If NM does *not*, please
  let me know and we'll fix that bug.
 It is *not*.
 
 I assume that NM is suppose to be examining the lease file before
 dhclient starts because it sure looks like it is dhclient that is
 creating the default.
 
 I have a real-hardware system that I can reboot or whatever so if you
 need me to test something, just tell me.  I know that it is
 frustrating on both sides if I say there is a problem and you cannot
 reproduce it.
 
 If you need to see the configuration file, then I should probably open
 a bugzilla report and file it there.
 
 BTW, I tried putting the default-duid in /etc/dhclient.leases and also
 in /var/lib/dhclient.leases and the only thing that seems to work
 is /var/lib/NetworkManager/dhclient6-whatever.lease

You want one of dhclient*6*.leases, in this priority order:

SYSCONFDIR /dhclient6.leases,
LOCALSTATEDIR /lib/dhcp/dhclient6.leases,
LOCALSTATEDIR /lib/dhclient/dhclient6.leases,

or the interface+connection-specific leasefile, eg:

/var/lib/dhclient/dhclient6-cc98bcbe-ef64-4db7-9b46-b12ca02172e6-wlan12.lease

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Mon, 2013-02-11 at 16:53 -0500, Gene Czarcinski wrote:
 On 02/11/2013 04:35 PM, Dan Williams wrote:
  On Mon, 2013-02-11 at 16:29 -0500, Gene Czarcinski wrote:
  On 02/11/2013 04:12 PM, Dan Williams wrote:
  See my reply to your other mail about this; I see what you're saying
  now, and I think we can push for having whatever generates machine-id
  (often systemd) pull that information from firmware/hardware rather than
  generating it randomly.
  Success!  Thank you.  That does scratch my itch.
 
  So long as it does not vary, I can plug it into dnsmasq with fixed IPv6
  addresses and it will work.
  Well, it turns out that machine-id is confusingly named, and that it's
  actually the install id and is meant to change whenever the OS is
  reinstalled.  So we're kinda stuck here; either we try to follow the
  standards to the end of the earth and start
  parsing /sys/class/dmi/id/product_id (which apparently is often
  1234567890) or we just go off machine-id and understand that
  reinstalling the OS on the same hardware will change the DUID.
 
  My believe is that using DUID-UUID generated from /etc/machine-id is
  more standards-compliant and less error-prone than using DUID-LL or
  DUID-LLT though.  And, of course, it can always be overridden.
 Too bad.  I thought this might be a solution.
 
 I really do not have multiple network interfaces on most systems and the 
 ones that do are manually configured.  So, I will just pick one( duid-LL 
 or duid-UUID) and use it for every installation where I need to have a 
 specific IPv6 address.

A DUID-UUID on a system with one interface should provide exactly the
same behavior as a DUID-LL on that system, no?  And are the systems you
run that have multiple interfaces that use DHCPv6 connected to the same
broadcast domain (eg, would use the same DHCPv6 server)?

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Sat, 2013-02-09 at 12:02 -0500, Gene Czarcinski wrote:
 On 02/09/2013 11:01 AM, Gene Czarcinski wrote:
  I need to look at the new code in NetworkManager to see what is being 
  done.
 There is a testing candidate update out for NetworkManager and 
 networt-manager-applet (0.9.7.997) which addresses the bridge problem 
 among other issues.
 
 I also updated my copy of the NetworkManager git and checked out the 
 duid branch.  It appears (if I did not screw something up) that there is 
 a 4 patch difference to implement the new duid capability. Is this code 
 OK to give it a shot?  I want to understand what the new code does 
 without spending lots of time analyzing the source code (at least not yet).

We merged the DUID stuff to git master already, so any of the DUID
branches are old and shouldn't be used.  The code is OK to try out.

 My brief look at the source code tells me that there may be a way I can 
 live with this.  Plus, I need to test this with dnsmasq so to ensure 
 that what I want does work for me.

Best to test with is git master or the 0.9.7.995 release.

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Sat, 2013-02-09 at 11:01 -0500, Gene Czarcinski wrote:
 On 02/08/2013 05:11 PM, Dan Williams wrote:
  On Fri, 2013-02-08 at 11:34 -0500, Gene Czarcinski wrote:
  On 02/08/2013 10:39 AM, Gene Czarcinski wrote:
  On 02/08/2013 10:17 AM, Simon Kelley wrote:
  On 07/02/13 21:27, Gene Czarcinski wrote:
  On 02/07/2013 04:22 PM, Gene Czarcinski wrote:
  I was googling around and found this:
  Looks like I got it working. I must admit that I was going off of
  information back when IPv6 and DHCPv6 first came out.
 
  So it was my impression that in my DHCP server configuration I had to
  use the old style of:
  host-identifier option dhcp6.client-id
  00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4;
  fixed-address6 FD35:4776:6804:1::1;
 
  Turns out there is now compatibility with the IPv4 style of setting
  fixed ip addresses where a clientid / duid isn't required and I was
  able to set it up as:
  hardware ethernet 00:0C:29:37:12:85;
  fixed-address6 FD35:4776:6804:2:1::1;
 
  I remember trying the previous a long time ago when hardware ethernet
  wasn't allowed to be used with IPv6 but it appears that has now
  changed.
 
  All is well now and things are finally back on track.
 
  at: https://bbs.archlinux.org/viewtopic.php?id=139567
 
  The quoted text is comment #5
 
  The writer claims to be using dhclient and dhcpd.
 
  The problems described are the same ones which trouble me. Has
  something changed with the DHCPv6 standard or did the folks at isc.org
  just want something that worked?
 
 
  I should have waited because I found what might be a slightly different
  solution to the problem here:
  http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/
  *Surprise #2: You can no longer simply use the MAC address of an
  interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in
  which the MAC address of the client interface is included in a DHCP
  request, DHCPv6 uses a DHCP Unique Identifier
  http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely
  identify the client. By default, the DUID is synthesized from the MAC
  address of an arbitrary interface on the host plus the system time at
  the moment the DUID is generated. The same DUID is then used
  regardless of which interface a DHCPv6 message originates from.
 
  The DUID normally persists across reboots, but if it’s deleted on the
  client, e.g., when a new operating system is installed, the DUID is
  automatically regenerated with a new time, and the server will no
  longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315
  prohibits using a portion of the DUID as an identifier (it must be
  treated as opaque), so DHCPv6 servers can’t be told to “just look at
  the MAC address part” of the DUID.
 
  Fortunately for those wishing to use old-style MAC addresses, there’s
  an alternative DUID type that let you do this. The DUID described
  above is a “Type 1” DUID, and is referred to as a “Link-Layer plus
  Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type
  1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs
  http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is
  simply the MAC address prepended with two identifiers (the sequence
  “00:03:00:01”). Moreover, these can be configured on a per-interface
  basis in the ISC DHCP client.^3
  http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3
  Problem solved.
 
  Now I just need to figure out how to get dhclient to use DUID-LL rather
  than DUID-LLT.
 
  Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac
  address, but if the machine has more than one interface, the client can
  use any of them, and use the same DUID for all the interfaces. Then if
  the MAC address is changed for any reason, the client will likely
  continue to use the existing DUID, not make a new one.
 
 
  Essentially, the MAC address is used just to ensure that the DUID is
  unique, not to make ide ntifying interfaces/machines easy. That wasn't
  considered necessary by the definers if IPv6.
 
  It is better than DUID-LLT.
 
  I only have one NIC which works so that may not be a problem. Plus,
  with NetworkManager, I believe it may still work OK since NM has a
  separate dhclient instance for each interface it manages ... and
  separate DHCPv4 and DHCPv6 instances too.  Each interface will have a
  different MAC.
 
  But, this is a good point and I will try to test what happens.
 
  Seems to work as I expected it to.  The test was of a qemu-kvm/libvirt
  virtual system with two NICs and the updated NetworkManager installed.
 
  1. Each NIC on a different network but the -D LL specified ... client-ID
  matches the NIC
 
  2. Both NICs on the same network and with -D LL specified ... client-ID
  matches the respective NIC
  We just updated NetworkManager to generate a *stable* DUID-UUID hashed
  off /etc/machine-id, which is generated once at system install/clone
  time, and stays the same thereafter.  Thus we avoid the whole

Re: [Dnsmasq-discuss] DHCPv6 and MAC

[Dan Williams]

On Fri, 2013-02-08 at 11:34 -0500, Gene Czarcinski wrote:
 On 02/08/2013 10:39 AM, Gene Czarcinski wrote:
  On 02/08/2013 10:17 AM, Simon Kelley wrote:
  On 07/02/13 21:27, Gene Czarcinski wrote:
  On 02/07/2013 04:22 PM, Gene Czarcinski wrote:
  I was googling around and found this:
  Looks like I got it working. I must admit that I was going off of
  information back when IPv6 and DHCPv6 first came out.
 
  So it was my impression that in my DHCP server configuration I had to
  use the old style of:
  host-identifier option dhcp6.client-id
  00:01:00:01:17:0B:B9:14:00:1D:60:B7:5F:D4;
  fixed-address6 FD35:4776:6804:1::1;
 
  Turns out there is now compatibility with the IPv4 style of setting
  fixed ip addresses where a clientid / duid isn't required and I was
  able to set it up as:
  hardware ethernet 00:0C:29:37:12:85;
  fixed-address6 FD35:4776:6804:2:1::1;
 
  I remember trying the previous a long time ago when hardware ethernet
  wasn't allowed to be used with IPv6 but it appears that has now 
  changed.
 
  All is well now and things are finally back on track.
 
  at: https://bbs.archlinux.org/viewtopic.php?id=139567
 
  The quoted text is comment #5
 
  The writer claims to be using dhclient and dhcpd.
 
  The problems described are the same ones which trouble me. Has
  something changed with the DHCPv6 standard or did the folks at isc.org
  just want something that worked?
 
 
  I should have waited because I found what might be a slightly different
  solution to the problem here:
  http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/
  *Surprise #2: You can no longer simply use the MAC address of an
  interface to assign a fixed IP address via DHCP.* Unlike DHCPv4, in
  which the MAC address of the client interface is included in a DHCP
  request, DHCPv6 uses a DHCP Unique Identifier
  http://tools.ietf.org/html/rfc3315#section-9, or DUID, to uniquely
  identify the client. By default, the DUID is synthesized from the MAC
  address of an arbitrary interface on the host plus the system time at
  the moment the DUID is generated. The same DUID is then used
  regardless of which interface a DHCPv6 message originates from.
 
  The DUID normally persists across reboots, but if it’s deleted on the
  client, e.g., when a new operating system is installed, the DUID is
  automatically regenerated with a new time, and the server will no
  longer recognize it. RFC 3315 http://tools.ietf.org/html/rfc3315
  prohibits using a portion of the DUID as an identifier (it must be
  treated as opaque), so DHCPv6 servers can’t be told to “just look at
  the MAC address part” of the DUID.
 
  Fortunately for those wishing to use old-style MAC addresses, there’s
  an alternative DUID type that let you do this. The DUID described
  above is a “Type 1” DUID, and is referred to as a “Link-Layer plus
  Time DUID”, or DUID-LLT. Many older DHCPv6 clients implement only Type
  1 DUIDs. You can configure ISC DHCPv6 client to use link-layer DUIDs
  http://tools.ietf.org/html/rfc3315#section-9.4 (DUID-LLs), which is
  simply the MAC address prepended with two identifiers (the sequence
  “00:03:00:01”). Moreover, these can be configured on a per-interface
  basis in the ISC DHCP client.^3
  http://blog.geoff.co.uk/2011/07/08/dhcpv6-surprises/#footnote-3
  Problem solved.
 
  Now I just need to figure out how to get dhclient to use DUID-LL rather
  than DUID-LLT.
 
  Sadly, it ain't that easy. a DUID-LL is _generated_ using _a_ mac
  address, but if the machine has more than one interface, the client can
  use any of them, and use the same DUID for all the interfaces. Then if
  the MAC address is changed for any reason, the client will likely
  continue to use the existing DUID, not make a new one.
 
 
  Essentially, the MAC address is used just to ensure that the DUID is
  unique, not to make ide ntifying interfaces/machines easy. That wasn't
  considered necessary by the definers if IPv6.
 
  It is better than DUID-LLT.
 
  I only have one NIC which works so that may not be a problem. Plus, 
  with NetworkManager, I believe it may still work OK since NM has a 
  separate dhclient instance for each interface it manages ... and 
  separate DHCPv4 and DHCPv6 instances too.  Each interface will have a 
  different MAC.
 
  But, this is a good point and I will try to test what happens.
 
 Seems to work as I expected it to.  The test was of a qemu-kvm/libvirt 
 virtual system with two NICs and the updated NetworkManager installed.
 
 1. Each NIC on a different network but the -D LL specified ... client-ID 
 matches the NIC
 
 2. Both NICs on the same network and with -D LL specified ... client-ID 
 matches the respective NIC

We just updated NetworkManager to generate a *stable* DUID-UUID hashed
off /etc/machine-id, which is generated once at system install/clone
time, and stays the same thereafter.  Thus we avoid the whole issue of
what MAC address to generate the DUID from (which is a problem with
DUID-LL and DUID-LLT), especially 

Re: [Dnsmasq-discuss] DNS server order is not being honored

[Dan Williams]

On Tue, 2012-12-11 at 13:17 -0500, richardvo...@gmail.com wrote:
 Unless you're using the strict-order option and still seeing the order
 change, this is not a bug.

NM does pass --strict-order to dnsmasq when dnsmasq is used as the local
caching nameserver plugin for NM, and has done that since 2009-11-14.

To verify, you can run ps ax | grep dnsmasq and see that
--strict-order is passed to the dnsmasq command line.

Dan

 
 -o, --strict-order
 By default, dnsmasq will send queries to any of the upstream
 servers it knows about and tries to favour servers that are
 known to be up. Setting this flag forces dnsmasq to try each
 query with each server strictly in the order they appear
 in /etc/resolv.conf
 
 
 On Tue, Dec 11, 2012 at 12:38 PM, Daniel Nicoletti
 dantt...@gmail.com wrote:
 Hi,
 a friend of mine using NetworkManger complained
 that when he puts 3 DNS entries on NM he gets
 NXDOMAIN, then he goes to /etc/resolv.conf
 and manually adds them. Since NM uses dnsmasq
 and the website says bugs should be discussed here
 I'll explain why it is failing.
 Also note that I'm not a DNS expert (he knows about
 it better), anyway, we found out that different from 
 libresolver dnsmasq spawns a call for all DNS servers
 and the fist to reply gets repassed to the caller.
 
 
 This is a big problem, since you put your internal
 company DNS to resolv local names, then you
 add some external DNS just in case the internal one fails.
 It also means that the order that you put the DNS
 doesn't matter since the reply speed is what is more
 important...
 
 
 I think it would be sane to have the same behavior
 as libresolv. How can this issue be addressed?
 Is there another place to fill a bug report?
 My friend told be also that he saw other people
 complaining in forums about this but they
 didn't know the cause.
 
 
 TCPDUMP (I changed the ips...)
 15:05:48.978824 IP 200-200-200-200.bbone.telesp.net.br.40510 
 10.0.0.123.domain: 12632+ A? intranet.foo.bar. (40)
 15:05:48.978872 IP 200-200-200-200.bbone.telesp.net.br.40510 
 resolver1.telesp.net.br.domain: 12632+ A? intranet.foo.bar.
 (40)
 15:05:48.979517 IP 200-200-200-200.bbone.telesp.net.br.45180 
 resolver1.telesp.net.br.domain: 49029+ PTR?
 123.0.0.10.in-addr.arpa. (41)
 15:05:48.982797 IP resolver1.telesp.net.br.domain
  200-200-200-200.bbone.telesp.net.br.40510: 12632 NXDomain
 0/1/0 (102)
 15:05:48.983391 IP resolver1.telesp.net.br.domain
  200-200-200-200.bbone.telesp.net.br.45180: 49029 NXDomain
 0/0/0 (41)
 15:05:48.984412 IP 200-200-200-200.bbone.telesp.net.br.26486 
 resolver1.telesp.net.br.domain: 2556+ A? intranet.foo.bar.
 (40)
 15:05:48.984622 IP 10.0.0.123.domain 
 200-204-2-133.bbone.telesp.net.br.40510: 12632* 1/0/0 A
 10.20.96.43 (56)
 15:05:48.988846 IP resolver1.telesp.net.br.domain 
 200-200-200-200.bbone.telesp.net.br.26486: 2556 NXDomain 0/1/0
 (102)
 
 
 As you can see 10.0.0.123 does knows about the domain, but
 resolver1.telesp.net.br reply first.
 
 
 -- 
 Daniel Nicoletti
 
 KDE Developer - http://dantti.wordpress.com
 
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
 
 
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Unable to connect by hostname for local machines

[Dan Williams]

On Tue, 2012-10-23 at 06:49 -0600, dnsm...@ailsby.net wrote:
 On 12-10-22 10:32 PM, /dev/rob0 wrote:
  On Mon, Oct 22, 2012 at 09:24:34PM -0600, dnsm...@ailsby.net wrote:
  I am trying to setup dnsmasq so that I can use the OpenDNS servers
  for my younger children, and then have all other devices use a
  different dns server (Google's).
 
  The program that I am having is that I cannot use the hostname of
  any of my local devices to connect, I can only do it via the ip
  Neither Google nor OpenDNS knows the names and addresses of your
  internal hosts. If you are setting your machines to use these
  external nameservers, you're not using the DNS feature of dnsmasq.
 
  address. This happens with my ubuntu server, and osx machines.  My
  windows laptop does not have an issue, and can ping other devices
  by hostname.
 
  As far as I can tell, all else is working properly.  The devices
  that are supposed to use OpenDNS are, and the ones that should use
  google's dns are.
 
  My setup:
  * tomatousb on my router
  * dnsmasq is version 2.61
  * static dns set to the OpenDNS ips
  * static ips assigned to the machines I want to use the google dns servers
  * dynamic ips assigned to the machines to use the OpenDNS servers.
  Set to the range of 192.168.1.100 to 192.168.1.199
  A style suggestion: I would use CIDR-style ranges rather than
  decimal-style. For example, 192.168.1.128-196 can be addressed in a
  single CIDR expression, 192.168.1.128/26.
 
  Options set for dnsmasq:
  # Range of IPs that are set up as static (computers that should
  have unrestricted DNS)
 
  dhcp-range=set:green,192.168.1.10,192.168.1.99
 
  dhcp-option=net:green, 3, 192.168.1.1 #Assigns green gateway to
  these clients
  dhcp-option=net:green, 6, 8.8.8.8 #Assigns green' DNS server to
  these clients (google).
 
  Any ideas on what I need to do so that the devices in the ip range
  192.168.1.10 to 192.168.1.99 can use hostnames to connect to each
  other?  Is there any other information that is needed to understand
  this issue?
  Probably what you want to do is to use a different upstream server
  for the big people and little people machines. And I know of no
  trivial way to do that in a single instance of dnsmasq. It might
  require two instances (one of them being DNS-only.) And I'm not sure
  that would be easy, either.
 
  This could be done with BIND named using views (and there too, you
  would benefit from the above CIDR suggestion.) But then you wouldn't
  have the ease of setup of dynamic DNS that dnsmasq offers.
 Thanks for the clear response.  I will have to see if there is some 
 other way to get to my desired end point.

Another possibility: avahi/zeroconf/bonjour/mDNS, which is precisely the
situation those were made for.  Run avahi-daemon on all machines and
then install the 'nss-mdns' glibc resolver plugin, and magically all
your machines are available via hostname.local.  So if you have one
machine named foo and another named bar, both are accessible on the
local network as foo.local and bar.local.

All this works completely outside normal DNS, exactly as it was meant
to, because (a) it's supposed to be easily done without central
administration, and (b) it's all local-network specific, so you don't
need to change anything about your DNS config, which you probably can't
do anyway because your upstream nameservers aren't under your control.

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] How to add local configuration to Network Manager initiated dnsmasq in Ubuntu 12.04

[Dan Williams]

On Tue, 2012-10-09 at 14:04 +0100, Chris Green wrote:
 On Tue, Oct 09, 2012 at 12:25:41PM +0100, Niall Litchfield wrote:
 Chris
 Did you come across Stephane Graber's website and article
 at [1]http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ (not sure 
  if
 
 Yes, I've found and read that.  It describes how the new NM driven
 dnsmasq works but give no clue how to customise/configure local DNS.
 
 
 Stephane is on this list). If what you are after is just nameserver
 changes he addresses that. Now I'll admit to disabling the network 
  manager
 install of dnsmasq and installing my own installation instead for 2
 reasons 
 
 I don't want nameserver changes, I want a nameserver that works for
 local (LAN) systems.

Back in July we added the ability to drop local dnsmasq config
into /etc/NetworkManager/dnsmasq.d which is part of NM 0.9.6, released
in early August.  I believe this fixes your problem.

The reason we cannot use the normal dnsmasq configuration is that by
default, that gets read, but there's a *lot* of stuff that uses dnsmasq
these days (libvirt, manual installs, NM, etc) and NM's use of dnsmasq
is quite different from these others, and thus the configuration
directives in the default config file simply don't apply to how NM uses
dnsmasq.

I think your best bet is to either:

1) get Ubuntu to backport the patch (git commit
ac152ece0206b4cde28acf78abb21518e67513e1) to 12.04

2) replace dnsmasq with a shellscript that checks the arguments it's
being called with, munges the arguments, and then calls the real dnsmasq

Dan



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] System tries to get its address by DHCP before dnsmasq starts up - how to stop it?

[Dan Williams]

On Thu, 2012-10-04 at 12:20 +0100, Chris Green wrote:
 On Thu, Oct 04, 2012 at 10:23:33AM +0100, Chris Green wrote:
  I have a little server system running dnsmasq version 2.59 under Ubuntu
  12.04 (I have just upgraded it from Ubuntu 10.04).
  
  While booting it tries to get its network configuration (using DHCP
  presumably) from the LAN, since *it's* the DHCP server this doesn't work
  but it wastes a lot of time waiting for things to time out and produces
  various error messages on the way.
  
  How do I configure the system so that it doesn't do this?
  
 Further to this the delay is cause by /etc/init/failsafe.conf, even if I
 have static IP correctly configured in /etc/network/interfaces the silly
 init sequence still does all the waits in /etc/init/failsafe.conf
 waiting for DHCP.
 
 Google searches just produce the standard way to set up static IP but
 no workaround for the delays.

Is the machine running NetworkManager?  If so it could be a
misconfiguration issue or an Upstart dependency issue.

Dan



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Can't figure out how to assign static IPv6 addresses to clients

[Dan Williams]

On Mon, 2012-10-01 at 21:49 +0200, Sean Boran wrote:
 
 
 Perhaps you clients are getting their addresses from router
 advertisement, and not DHCP.  So disable RA first in dnsmasq (and make
 sure no router or other host is publishing one)

You don't want to disable RA, you want to tell clients to use managed
configuration in the RA.  If you disable RA, then nothing on that link
will have a default router and thus no way to get packets to anything
that's not in the broadcast domain.  DHCPv6 does not have any facility
to provide a default gateway like IPv4, since that's precisely the
functionality of RAs.

So you really want to reconfigure either dnsmasq or radvd to set the
M (Managed) flag, which will tell the clients to get their address
from DHCPv6, not generate one from the RA prefix option.

Dan

 
 Syntax like this works, I used it:
 dhcp-host=ubuntu12,[2001::666::1]
 
 
 perhaps a v6 range needs to be specified:
 dhcp-range=2001::666::1, 2001::666::4, 24h
 
 
 make sure you're using  a very recent version of dnsmasq.
 
 
 tcpdump ip6 can show what packets are on the wire too.
 
 
 Sean
 
 
 
 On 1 October 2012 01:38, Carlos Laviola carlos.lavi...@gmail.com
 wrote:
 Hello everyone,
 
 I've recently switched to using only dnsmasq on openwrt since
 finding
 out that it could also hand out IPv6 addresses. This works,
 but the
 clients only get SLAAC addresses.
 
 Also, the manpage states:
 
 A single dhcp-host may contain an IPv4 address or an IPv6
 address, or
 both. IPv6 addresses must be bracketed by square brackets
 thus:
 --dhcp-host=laptop,[1234::56] Note that in IPv6 DHCP, the
 hardware
 address is not normally available, so a client must be
 identified by
 client-id (called client DUID in IPv6-land) or hostname.
 
 How do I find this client-id/DUID? Even with the log-dhcp
 directive,
 I don't see anything that looks like it.
 
 Here are my conffiles. openwrt auto-generates
 a /var/etc/dnsmasq.conf
 based on a file written in their own DSL (/etc/config/dhcp),
 which is
 it's split in two files.
 
 /var/etc/dnsmasq.conf:
 
 --
 conf-file=/etc/dnsmasq.conf
 dhcp-authoritative
 domain-needed
 no-resolv
 localise-queries
 read-ethers
 bogus-priv
 expand-hosts
 domain=home.laviola.org
 server=/home.laviola.org/
 server=8.8.8.8
 server=8.8.4.4
 server=2001:4860:4860::
 server=2001:4860:4860::8844
 server=2620:0:ccc::2
 server=2620:0:ccd::2
 dhcp-leasefile=/tmp/dhcp.leases
 stop-dns-rebind
 rebind-localhost-ok
 
 
 
 
 dhcp-range=lan,192.168.1.100,192.168.1.249,255.255.255.0,12h
 no-dhcp-interface=pppoe-wan
 
 
 address=/ellis.home.laviola.org/192.168.1.1
 ptr-record=1.1.168.192.in-addr.arpa,ellis.home.laviola.org
 --
 
 /etc/dnsmasq.conf:
 
 --
 dhcp-range=2001::666::,slaac
 enable-ra
 dhcp-host=192.168.1.2,[2001::666::1],client1
 dhcp-host=192.168.1.3,[2001::666::2],client2
 dhcp-host=192.168.1.4,[2001::666::3],client3
 dhcp-host=192.168.1.5,[2001::666::4],client4
 log-dhcp
 --
 
 Thanks for your help!
 
 Best regards,
 Carlos
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
 
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH 2/2] dbus: add SetServersEx method

[Dan Williams]

On Sat, 2012-08-18 at 07:28 +0100, Simon Kelley wrote:
 On 17/08/12 23:35, Dan Williams wrote:
  The SetServers method has a few deficiencies:
 
  First, given its argument structure, you cannot actually
  introspect it since it expects a variable number of arguments.
  Typically these are encoded into arrays, but that's not the
  case with SetServers.  This means it's hard to use the method
  from dbus client libraries like dbus-glib, gdbus, or many bound
  languages like python or javascript.
 
  Second, given that the address arguments are either uint32
  or a number of bytes, additional options like IPv6 scope or
  DNS server port numbers are impossible.
 
  To address these issues, create a new method SetServersEx that
  performs the same function, but accepts arrays of strings as input.
  This allows more complex parsing of addresses and easier groupings
  of addresses and domains from clients.
 
  For example, from Python:
 
  import dbus
 
  bus = dbus.SystemBus()
  p = bus.get_object(uk.org.thekelleys.dnsmasq, 
  /uk/org/thekelleys/dnsmasq)
  l = dbus.Interface(p, dbus_interface=uk.org.thekelleys.dnsmasq)
 
  array = dbus.Array()
  array.append([1.2.3.5])
  array.append([1.2.3.4#664, foobar.com])
  array.append([1003:1234:abcd::1%eth0, eng.mycorp.com, lab.mycorp.com])
  print l.SetServersEx(array)
 
 
 
 This looks very sensible to me. Your timing is highly suspect as we 
 released 2.63 yesterday and I am about to go away for 10 days or so. 
 When I get back this, or something very like it, will be the first 
 change into 2.64.

Simon,

Had a chance to review these yet?  Looks like we're getting close to
2.64...

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH 2/2] dbus: add SetServersEx method

[Dan Williams]

On Sat, 2012-08-18 at 07:28 +0100, Simon Kelley wrote:
 On 17/08/12 23:35, Dan Williams wrote:
  The SetServers method has a few deficiencies:
 
  First, given its argument structure, you cannot actually
  introspect it since it expects a variable number of arguments.
  Typically these are encoded into arrays, but that's not the
  case with SetServers.  This means it's hard to use the method
  from dbus client libraries like dbus-glib, gdbus, or many bound
  languages like python or javascript.
 
  Second, given that the address arguments are either uint32
  or a number of bytes, additional options like IPv6 scope or
  DNS server port numbers are impossible.
 
  To address these issues, create a new method SetServersEx that
  performs the same function, but accepts arrays of strings as input.
  This allows more complex parsing of addresses and easier groupings
  of addresses and domains from clients.
 
  For example, from Python:
 
  import dbus
 
  bus = dbus.SystemBus()
  p = bus.get_object(uk.org.thekelleys.dnsmasq, 
  /uk/org/thekelleys/dnsmasq)
  l = dbus.Interface(p, dbus_interface=uk.org.thekelleys.dnsmasq)
 
  array = dbus.Array()
  array.append([1.2.3.5])
  array.append([1.2.3.4#664, foobar.com])
  array.append([1003:1234:abcd::1%eth0, eng.mycorp.com, lab.mycorp.com])
  print l.SetServersEx(array)
 
 
 
 This looks very sensible to me. Your timing is highly suspect as we 
 released 2.63 yesterday and I am about to go away for 10 days or so. 
 When I get back this, or something very like it, will be the first 
 change into 2.64.

Yeah, sorry about that; just got some time last week to work on it :(

Dan


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH 1/2] Move common parsing functions to utils.c

[Dan Williams]

Will be needed by the enhanced D-Bus SetServers method.

Signed-off-by: Dan Williams d...@redhat.com
---
 src/dnsmasq.h |  8 +-
 src/option.c  | 92 ---
 src/util.c| 92 ++-
 3 files changed, 98 insertions(+), 94 deletions(-)

diff --git a/src/dnsmasq.h b/src/dnsmasq.h
index b131c96..660ee89 100644
--- a/src/dnsmasq.h
+++ b/src/dnsmasq.h
@@ -891,9 +891,15 @@ void safe_pipe(int *fd, int read_noblock);
 void *whine_malloc(size_t size);
 int sa_len(union mysockaddr *addr);
 int sockaddr_isequal(union mysockaddr *s1, union mysockaddr *s2);
-int hostname_isequal(char *a, char *b);
+int hostname_isequal(const char *a, const char *b);
 time_t dnsmasq_time(void);
 int is_same_net(struct in_addr a, struct in_addr b, struct in_addr mask);
+char *split_chr(char *s, char c);
+char hide_meta(char c);
+char unhide_meta(char cr);
+void unhide_metas(char *cp);
+int atoi_check(char *a, int *res);
+int atoi_check16(char *a, int *res);
 #ifdef HAVE_IPV6
 int is_same_net6(struct in6_addr *a, struct in6_addr *b, int prefixlen);
 u64 addr6part(struct in6_addr *addr);
diff --git a/src/option.c b/src/option.c
index 22c08e7..f2ee306 100644
--- a/src/option.c
+++ b/src/option.c
@@ -380,49 +380,6 @@ static struct {
   { 0, 0, NULL, NULL, NULL }
 }; 
 
-/* We hide metacharaters in quoted strings by mapping them into the ASCII 
control
-   character space. Note that the \0, \t \b \r \033 and \n characters are 
carefully placed in the
-   following sequence so that they map to themselves: it is therefore possible 
to call
-   unhide_metas repeatedly on string without breaking things.
-   The transformation gets undone by opt_canonicalise, atoi_check and 
opt_string_alloc, and a 
-   couple of other places. 
-   Note that space is included here so that
-   --dhcp-option=3, string
-   has five characters, whilst
-   --dhcp-option=3, string
-   has six.
-*/
-
-static const char meta[] = \000123456 \b\t\n78\r90abcdefABCDE\033F:,.;
-
-static char hide_meta(char c)
-{
-  unsigned int i;
-
-  for (i = 0; i  (sizeof(meta) - 1); i++)
-if (c == meta[i])
-  return (char)i;
-  
-  return c;
-}
-
-static char unhide_meta(char cr)
-{ 
-  unsigned int c = cr;
-  
-  if (c  (sizeof(meta) - 1))
-cr = meta[c];
-  
-  return cr;
-}
-
-static void unhide_metas(char *cp)
-{
-  if (cp)
-for(; *cp; cp++)
-  *cp = unhide_meta(*cp);
-}
-
 static void *opt_malloc(size_t size)
 {
   void *ret;
@@ -455,28 +412,6 @@ static char *opt_string_alloc(char *cp)
   return ret;
 }
 
-
-/* find next comma, split string with zero and eliminate spaces.
-   return start of string following comma */
-
-static char *split_chr(char *s, char c)
-{
-  char *comma, *p;
-
-  if (!s || !(comma = strchr(s, c)))
-return NULL;
-  
-  p = comma;
-  *comma = ' ';
-  
-  for (; *comma == ' '; comma++);
- 
-  for (; (p = s)  *p == ' '; p--)
-*p = 0;
-
-  return comma;
-}
-
 static char *split(char *s)
 {
   return split_chr(s, ',');
@@ -502,33 +437,6 @@ static char *canonicalise_opt(char *s)
   return ret;
 }
 
-static int atoi_check(char *a, int *res)
-{
-  char *p;
-
-  if (!a)
-return 0;
-
-  unhide_metas(a);
-  
-  for (p = a; *p; p++)
- if (*p  '0' || *p  '9')
-   return 0;
-
-  *res = atoi(a);
-  return 1;
-}
-
-static int atoi_check16(char *a, int *res)
-{
-  if (!(atoi_check(a, res)) ||
-  *res  0 ||
-  *res  0x)
-return 0;
-
-  return 1;
-}
-   
 static void add_txt(char *name, char *txt)
 {
   size_t len = strlen(txt);
diff --git a/src/util.c b/src/util.c
index a1d47d6..320d4cf 100644
--- a/src/util.c
+++ b/src/util.c
@@ -280,7 +280,7 @@ int sa_len(union mysockaddr *addr)
 }
 
 /* don't use strcasecmp and friends here - they may be messed up by LOCALE */
-int hostname_isequal(char *a, char *b)
+int hostname_isequal(const char *a, const char *b)
 {
   unsigned int c1, c2;
   
@@ -581,3 +581,93 @@ int read_write(int fd, unsigned char *packet, int size, 
int rw)
   return 1;
 }
 
+/* find next comma, split string with zero and eliminate spaces.
+   return start of string following comma */
+
+char *split_chr(char *s, char c)
+{
+  char *comma, *p;
+
+  if (!s || !(comma = strchr(s, c)))
+return NULL;
+  
+  p = comma;
+  *comma = ' ';
+  
+  for (; *comma == ' '; comma++);
+ 
+  for (; (p = s)  *p == ' '; p--)
+*p = 0;
+
+  return comma;
+}
+
+/* We hide metacharaters in quoted strings by mapping them into the ASCII 
control
+   character space. Note that the \0, \t \b \r \033 and \n characters are 
carefully placed in the
+   following sequence so that they map to themselves: it is therefore possible 
to call
+   unhide_metas repeatedly on string without breaking things.
+   The transformation gets undone by opt_canonicalise, atoi_check and 
opt_string_alloc, and a 
+   couple of other places. 
+   Note that space is included here so that
+   --dhcp-option=3, string
+   has five characters

[Dnsmasq-discuss] [PATCH 2/2] dbus: add SetServersEx method

[Dan Williams]

The SetServers method has a few deficiencies:

First, given its argument structure, you cannot actually
introspect it since it expects a variable number of arguments.
Typically these are encoded into arrays, but that's not the
case with SetServers.  This means it's hard to use the method
from dbus client libraries like dbus-glib, gdbus, or many bound
languages like python or javascript.

Second, given that the address arguments are either uint32
or a number of bytes, additional options like IPv6 scope or
DNS server port numbers are impossible.

To address these issues, create a new method SetServersEx that
performs the same function, but accepts arrays of strings as input.
This allows more complex parsing of addresses and easier groupings
of addresses and domains from clients.

For example, from Python:

import dbus

bus = dbus.SystemBus()
p = bus.get_object(uk.org.thekelleys.dnsmasq, /uk/org/thekelleys/dnsmasq)
l = dbus.Interface(p, dbus_interface=uk.org.thekelleys.dnsmasq)

array = dbus.Array()
array.append([1.2.3.5])
array.append([1.2.3.4#664, foobar.com])
array.append([1003:1234:abcd::1%eth0, eng.mycorp.com, lab.mycorp.com])
print l.SetServersEx(array)

Signed-off-by: Dan Williams d...@redhat.com
---
 dbus/DBus-interface |  42 ++
 src/dbus.c  | 419 +---
 2 files changed, 371 insertions(+), 90 deletions(-)

diff --git a/dbus/DBus-interface b/dbus/DBus-interface
index 9fa08f2..58ae03c 100644
--- a/dbus/DBus-interface
+++ b/dbus/DBus-interface
@@ -95,6 +95,48 @@ Each call to SetServers completely replaces the set of 
servers
 specified by via the DBus, but it leaves any servers specified via the
 command line or /etc/dnsmasq.conf or /etc/resolv.conf alone.
 
+SetServersEx
+
+
+This function is more flexible and the SetServers function, in that it can
+handle address scoping, port numbers, and is easier for clients to use.
+
+Returns nothing. Takes a set of arguments representing the new
+upstream DNS servers to be used by dnsmasq. All addresses (both IPv4 and IPv6)
+are represented as STRINGS.  Each server address may be followed by one or more
+STRINGS, which are the domains for which the preceding server should be used.
+
+This function takes an array of STRING arrays, where each inner array 
represents
+a set of DNS servers and domains for which those servers may be used.  Each
+string represents a list of upstream DNS servers first, and domains second.
+Mixing of domains and servers within a the string array is not allowed.
+
+Examples.
+
+[
+  [1.2.3.4, foobar.com],
+  [1003:1234:abcd::1%eth0, eng.mycorp.com, lab.mycorp.com]
+]
+
+is equivalent to
+
+--server=/foobar.com/1.2.3.4 \
+  --server=/eng.mycorp.com/lab.mycorp.com/1003:1234:abcd::1%eth0
+
+An IPv4 address of 0.0.0.0 is interpreted as no address, local only,
+so
+
+[ [0.0.0.0, local.domain] ]
+
+is equivalent to
+
+--local=/local.domain/
+
+
+Each call to SetServersEx completely replaces the set of servers
+specified by via the DBus, but it leaves any servers specified via the
+command line or /etc/dnsmasq.conf or /etc/resolv.conf alone.
+
 2. SIGNALS
 --
 
diff --git a/src/dbus.c b/src/dbus.c
index 16a05e8..9097c89 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -38,6 +38,9 @@ const char* introspection_xml_template =
 method name=\SetServers\\n
   arg name=\servers\ direction=\in\ type=\av\/\n
 /method\n
+method name=\SetServersEx\\n
+  arg name=\servers\ direction=\in\ type=\aas\/\n
+/method\n
 signal name=\DhcpLeaseAdded\\n
   arg name=\ipaddr\ type=\s\/\n
   arg name=\hwaddr\ type=\s\/\n
@@ -99,20 +102,125 @@ static void remove_watch(DBusWatch *watch, void *data)
   w = data; /* no warning */
 }
 
-static void dbus_read_servers(DBusMessage *message)
+static void add_update_server(union mysockaddr *addr,
+  union mysockaddr *source_addr,
+  int flags,
+  const char *interface,
+  const char *domain)
+{
+  struct server *serv;
+
+  /* See if this is already there, and unmark */
+  for (serv = daemon-servers; serv; serv = serv-next)
+if ((serv-flags  SERV_FROM_DBUS) 
+   (serv-flags  SERV_MARK))
+  {
+   if ((serv-flags  SERV_HAS_DOMAIN) 
+   (!domain ||
+!hostname_isequal(domain, serv-domain)))
+  continue;
+
+if (serv-flags  SERV_HAS_SOURCE)
+  {
+/* Not all SERV_HAS_SOURCE servers have an interface */
+if (interface 
+serv-interface 
+(strcmp(interface, serv-interface) != 0))
+ continue;
+   else if (interface != serv-interface)
+ continue;
+  }
+
+serv-flags = ~SERV_MARK;
+break;
+  }
+
+  if (!serv  (serv = whine_malloc(sizeof (struct server
+{
+  /* Not found, create a new one. */
+  memset(serv, 0, sizeof(struct server