Re: [Dnsmasq-discuss] dns/resolv.conf shoud follow DNS server as learned via DHCP
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
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
On Mon, 2016-04-11 at 09:24 +0200, Albert ARIBAUD wrote: > Hi Leandro, > > Le Sun, 10 Apr 2016 21:42:57 +0200 > Leandro Noferinia é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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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