Re: [Dnsmasq-discuss] Cannot look up disa.mil (dnssec related)
Something to do with the recent change of the root DNSSEC key? (dnsmasq has the new key in its codebase, but perhaps your config isn't pulling it in correctly?) On Mon, Oct 22, 2018 at 6:23 PM Craig Andrews wrote: > > I'm unable to look up *.disa.mil when using dnsmasq - I'm hoping that we > can figure out why that is. > > I have dnsmasq configured to use Cloudflare's 1.1.1.1 as its upstream > DNS server; dnsmasq is running on 192.168.0.1. > > Here are some a couple tests demonstrating the problem: > -- > $ dig disa.mil @192.168.0.1 +dnssec +short > > $ dig disa.mil @8.8.8.8 +dnssec +short > 156.112.108.76 > A 8 2 7200 20181117145327 20181018145327 52983 disa.mil. > dMS5WbQ5xJ0HuCBPZUkuoshf0A2n1tvxA75smhcFZNS5SHSOA0zsQaSc > YOzNdu5gH6qFXA7TbKhPYN0RcPD+vVcmtfbzv3eJZfh4343IXlBznG6w > aLaLt+kI6GGnPQ7skNWOcO4yLct+yaeNxTT95CZnHtwRUx3vzGHS3dJF GYc= > [candrews@craigatwork vars]$ dig disa.mil @1.1.1.1 +dnssec +short > 156.112.108.76 > -- > So looking it up using Google's 8.8.8.8 or Cloudflare's 1.1.1.1 with > dnssec works, but not with dnsmasq. > > -- > # dnsmasq --version > Dnsmasq version 2.80test3 Copyright (c) 2000-2018 Simon Kelley > Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 > no-Lua TFTP conntrack ipset auth DNSSEC no-ID loop-detect inotify > dumpfile > > This software comes with ABSOLUTELY NO WARRANTY. > Dnsmasq is free software, and you are welcome to redistribute it > under the terms of the GNU General Public License, version 2 or 3. > -- > > Thanks in advance for your help and for this great software, > ~Craig > > ___ > 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] Ready for dnssec key signing key rollover on Oct 11?
On Sun, Oct 7, 2018 at 12:05 PM Loganaden Velvindron wrote: > On Sun, Oct 7, 2018 at 2:13 PM Rick Thomas wrote: > > > > What do I need to do to be ready for the DNSSEC Root KSK (key signing > key) rollover on October 11, 2018? > > > > Well, dnsmasq already commited a patch for the new trust anchor : > > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=05da782f8f45933915af0ef3cc1ba35e31d20c59 I was also looking into this last week, and would appreciate if anyone wanted to review and confirm or correct my observations. If I've understood correctly: - An installation of dnsmasq can only possibly be impacted by the KSK rollover if it - was built with HAVE_DNSSEC enabled; AND - is configured (--dnssec) to use DNSSEC at runtime; AND - is actually used as a DNS server / forwarder. - There is no cross-dependency between DNSSEC and dnsmasq's DHCP and RA function. So if you're mainly using dnsmasq for DHCP and RA, as OpenStack does, that function can't be degraded by not having installed or configured the new DNSSEC KSK. - While it is true that the dnsmasq repo has included the new KSK fingerprint since February 2017 (as in the commit cited above), I couldn't see anything hardcoded in the dnsmasq code to read and use the content of trust-anchors.conf. So, even if you have that file in your dnsmasq install, and it includes the new KSK fingerprint, I _think_ you still need to configure dnsmasq somehow to read that file and trust the fingerprints in it (presumably at the same time as you'd configure --dnssec). Any comments much appreciated. Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] RFC: allowing arbitrarily long options
Thanks Simon! On Thu, Jan 18, 2018 at 10:50 PM Simon Kelley wrote: > Patch applied. > > > Cheers, > > Simon. > > On 18/01/18 14:15, Neil Jerram wrote: > > On Sun, Jan 14, 2018 at 10:35 PM Simon Kelley > <mailto:si...@thekelleys.org.uk>> wrote: > > > > On 14/01/18 18:14, Neil Jerram wrote: > > > Thanks for looking at this, Simon. Some thoughts below... > > > > > > On Sat, Jan 13, 2018 at 5:34 PM Simon Kelley > > mailto:si...@thekelleys.org.uk> > > > <mailto:si...@thekelleys.org.uk <mailto:si...@thekelleys.org.uk>>> > > wrote: > > > > > > I'm in favour, in theory at least, of removing arbitrary > limits. > > > Experience has shown that no matter how big, someone, > > somewhere, will > > > always find them. The code originally used a fixed buffer > > which happened > > > to be unused at that point, to reduce the memory footprint. > Whilst > > > dnsmasq is still intended to be "small", small is a relative > > thing, and > > > absolutely, rather bigger than it was 15 years ago, so > > allocating a big > > > enough buffer is fine. > > > > > > In this case, though, as you hint, it's likely that shell > > limits will > > > also be a problem. Even eliminating that by using > > configuration files, > > > you still have very long lines, which is ugly. > > > > > > Can't we solve this problem by allowing repeated interface > > names, so > > > > > > --bridge-interface=eth1,alias-1,alias-2 > > > > > > becomes identical to > > > > > > --bridge-interface=eth1,alias-1 > > > --bridge-interface=eth1,alias-2 > > > > > > the patch to implement that is probably smaller than your > > offering. > > > > > > > > > It looks like a nice alternative, but note that it doesn't help at > all > > > with any shell limit. (In fact it would hit any such limit > > sooner.) So > > > I think this is a matter of what you think is more elegant for > dnsmasq > > > itself; particularly in the configuration file context where shell > > > limits don't apply. > > > > > > > > > > > > > > > Maybe we should do both? > > > > > > > > > In principle I'm happy to code up and test multiple solutions > > here; it's > > > not a large amount of work in any case. So please do let me know > what > > > you would prefer. > > > > I'll take both, for preference. > > > > Actually - no. You test the long-options patch and I'll take that. > I'll > > do the split-into-multiple lines one. > > > > > > I have (or in fact my colleague has) successfully tested this now (with > > a real OpenStack rig, 90 cirros VMs at the same time on a GCE > > n1-standard-64 compute node), with no further changes to the patch that > > I attached before. > > > > So I believe the patch is good - please would you consider it for > merging? > > > > Many thanks - Neil > > > > > > > > Cheers, > > > > Simon. > > > > > > > > Best wishes - Neil > > > > > > > > > > > > > > > On 07/01/18 14:25, Neil Jerram wrote: > > > > Calico [1] with OpenStack > > > > > > (https://docs.projectcalico.org/v2.6/getting-started/openstack/) > uses > > > > dnsmasq with a very long --bridge-interface option: > > > > > > > > > > > > > > --bridge-interface=,,,..., > > > > > > > > where each occurrence of "," occupies 15 > > > characters, and > > > > there can in principle be as many s as you > > can have VMs > > > > on a single OpenStack compute host. Currently an option arg > is > > > limited > > > > in dnsmasq to 1025 chars overall, which only allows for 67 > > > > s, which is not necessarily enough, on a > powerful > > > compute > >
Re: [Dnsmasq-discuss] RFC: allowing arbitrarily long options
On Sun, Jan 14, 2018 at 10:35 PM Simon Kelley wrote: > On 14/01/18 18:14, Neil Jerram wrote: > > Thanks for looking at this, Simon. Some thoughts below... > > > > On Sat, Jan 13, 2018 at 5:34 PM Simon Kelley > <mailto:si...@thekelleys.org.uk>> wrote: > > > > I'm in favour, in theory at least, of removing arbitrary limits. > > Experience has shown that no matter how big, someone, somewhere, will > > always find them. The code originally used a fixed buffer which > happened > > to be unused at that point, to reduce the memory footprint. Whilst > > dnsmasq is still intended to be "small", small is a relative thing, > and > > absolutely, rather bigger than it was 15 years ago, so allocating a > big > > enough buffer is fine. > > > > In this case, though, as you hint, it's likely that shell limits will > > also be a problem. Even eliminating that by using configuration > files, > > you still have very long lines, which is ugly. > > > > Can't we solve this problem by allowing repeated interface names, so > > > > --bridge-interface=eth1,alias-1,alias-2 > > > > becomes identical to > > > > --bridge-interface=eth1,alias-1 > > --bridge-interface=eth1,alias-2 > > > > the patch to implement that is probably smaller than your offering. > > > > > > It looks like a nice alternative, but note that it doesn't help at all > > with any shell limit. (In fact it would hit any such limit sooner.) So > > I think this is a matter of what you think is more elegant for dnsmasq > > itself; particularly in the configuration file context where shell > > limits don't apply. > > > > > > > > > > Maybe we should do both? > > > > > > In principle I'm happy to code up and test multiple solutions here; it's > > not a large amount of work in any case. So please do let me know what > > you would prefer. > > I'll take both, for preference. > > Actually - no. You test the long-options patch and I'll take that. I'll > do the split-into-multiple lines one. > I have (or in fact my colleague has) successfully tested this now (with a real OpenStack rig, 90 cirros VMs at the same time on a GCE n1-standard-64 compute node), with no further changes to the patch that I attached before. So I believe the patch is good - please would you consider it for merging? Many thanks - Neil > > Cheers, > > Simon. > > > > > Best wishes - Neil > > > > > > > > > > On 07/01/18 14:25, Neil Jerram wrote: > > > Calico [1] with OpenStack > > > (https://docs.projectcalico.org/v2.6/getting-started/openstack/) > uses > > > dnsmasq with a very long --bridge-interface option: > > > > > > > > > --bridge-interface=,,,..., > > > > > > where each occurrence of "," occupies 15 > > characters, and > > > there can in principle be as many s as you can have > VMs > > > on a single OpenStack compute host. Currently an option arg is > > limited > > > in dnsmasq to 1025 chars overall, which only allows for 67 > > > s, which is not necessarily enough, on a powerful > > compute > > > host. > > > > > > So I wonder what folk would think about reallocating as necessary > to > > > allow an option arg to be arbitrarily long? (Or at least, as long > as > > > getopt and the containing shell will allow.) For reference I've > > > attached a patch that I think would implement that - but I haven't > yet > > > been able to test it at all, so please don't merge it yet! > > > > > > Thanks in advance for your thoughts! > > > Neil > > > > > > > > > > > > ___ > > > Dnsmasq-discuss mailing list > > > Dnsmasq-discuss@lists.thekelleys.org.uk > > <mailto: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 > > <mailto: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] RFC: allowing arbitrarily long options
Thanks for looking at this, Simon. Some thoughts below... On Sat, Jan 13, 2018 at 5:34 PM Simon Kelley wrote: > I'm in favour, in theory at least, of removing arbitrary limits. > Experience has shown that no matter how big, someone, somewhere, will > always find them. The code originally used a fixed buffer which happened > to be unused at that point, to reduce the memory footprint. Whilst > dnsmasq is still intended to be "small", small is a relative thing, and > absolutely, rather bigger than it was 15 years ago, so allocating a big > enough buffer is fine. > > In this case, though, as you hint, it's likely that shell limits will > also be a problem. Even eliminating that by using configuration files, > you still have very long lines, which is ugly. > > Can't we solve this problem by allowing repeated interface names, so > > --bridge-interface=eth1,alias-1,alias-2 > > becomes identical to > > --bridge-interface=eth1,alias-1 > --bridge-interface=eth1,alias-2 > > the patch to implement that is probably smaller than your offering. > It looks like a nice alternative, but note that it doesn't help at all with any shell limit. (In fact it would hit any such limit sooner.) So I think this is a matter of what you think is more elegant for dnsmasq itself; particularly in the configuration file context where shell limits don't apply. > > > Maybe we should do both? > In principle I'm happy to code up and test multiple solutions here; it's not a large amount of work in any case. So please do let me know what you would prefer. Best wishes - Neil > > > On 07/01/18 14:25, Neil Jerram wrote: > > Calico [1] with OpenStack > > (https://docs.projectcalico.org/v2.6/getting-started/openstack/) uses > > dnsmasq with a very long --bridge-interface option: > > > > --bridge-interface=,,,..., > > > > where each occurrence of "," occupies 15 characters, and > > there can in principle be as many s as you can have VMs > > on a single OpenStack compute host. Currently an option arg is limited > > in dnsmasq to 1025 chars overall, which only allows for 67 > > s, which is not necessarily enough, on a powerful compute > > host. > > > > So I wonder what folk would think about reallocating as necessary to > > allow an option arg to be arbitrarily long? (Or at least, as long as > > getopt and the containing shell will allow.) For reference I've > > attached a patch that I think would implement that - but I haven't yet > > been able to test it at all, so please don't merge it yet! > > > > Thanks in advance for your thoughts! > > Neil > > > > > > > > ___ > > 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
[Dnsmasq-discuss] RFC: allowing arbitrarily long options
Calico [1] with OpenStack (
https://docs.projectcalico.org/v2.6/getting-started/openstack/) uses
dnsmasq with a very long --bridge-interface option:
--bridge-interface=,,,...,
where each occurrence of "," occupies 15 characters, and
there can in principle be as many s as you can have VMs on a
single OpenStack compute host. Currently an option arg is limited in
dnsmasq to 1025 chars overall, which only allows for 67 s,
which is not necessarily enough, on a powerful compute host.
So I wonder what folk would think about reallocating as necessary to allow
an option arg to be arbitrarily long? (Or at least, as long as getopt and
the containing shell will allow.) For reference I've attached a patch that
I think would implement that - but I haven't yet been able to test it at
all, so please don't merge it yet!
Thanks in advance for your thoughts!
Neil
From b39df72629f4226a2fcba104ff108d155a7e7372 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Sat, 6 Jan 2018 01:03:26 +
Subject: [PATCH] Allow options longer than 1025 chars
Calico [1] with OpenStack uses dnsmasq with a very long
--bridge-interface option:
--bridge-interface=,,,...,
where each occurrence of "," occupies 15 characters, and
there can in principle be as many s as you can have VMs
on a single OpenStack compute host.
Currently the option is limited to 1025 chars overall, which only allows
for 67 s, which is not necessarily enough. This patch
removes the limit by reallocating the arg buffer when necessary.
[1] https://docs.projectcalico.org/v2.6/getting-started/openstack/
---
src/option.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/option.c b/src/option.c
index 3ab1533..9c3d85a 100644
--- a/src/option.c
+++ b/src/option.c
@@ -4612,6 +4612,8 @@ void reread_dhcp(void)
void read_opts(int argc, char **argv, char *compile_opts)
{
+ size_t argbuf_size = MAXDNAME;
+ char *argbuf = opt_malloc(argbuf_size);
char *buff = opt_malloc(MAXDNAME);
int option, conffile_opt = '7', testmode = 0;
char *arg, *conffile = CONFFILE;
@@ -4681,9 +4683,15 @@ void read_opts(int argc, char **argv, char *compile_opts)
/* Copy optarg so that argv doesn't get changed */
if (optarg)
{
- strncpy(buff, optarg, MAXDNAME);
- buff[MAXDNAME-1] = 0;
- arg = buff;
+ if (strlen(optarg) >= argbuf_size)
+ {
+ free(argbuf);
+ argbuf_size = strlen(optarg) + 1;
+ argbuf = opt_malloc(argbuf_size);
+ }
+ strncpy(argbuf, optarg, argbuf_size);
+ argbuf[argbuf_size-1] = 0;
+ arg = argbuf;
}
else
arg = NULL;
@@ -4731,6 +4739,8 @@ void read_opts(int argc, char **argv, char *compile_opts)
}
}
+ free(argbuf);
+
if (conffile)
{
one_file(conffile, conffile_opt);
--
2.7.4
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Spelling fixes for dnsmasq
https://github.com/jsoref/dnsmasq/commit/56dc618b840dd893a65f02df2fb14752bb7ef33d is wrong; the word should be 'amended'. Original Message From: Josh Soref Sent: Thursday, 2 February 2017 06:58 To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] Spelling fixes for dnsmasq Hi... I'm wondering if you'd be interested in any of these commits: https://github.com/jsoref/dnsmasq/commits/spelling https://github.com/jsoref/dnsmasq/compare/master...jsoref:spelling?expand=1 I could send a single diff for the changes, but I find that it's usually best to let people think about changes individually, and it's much easier for me to drop things when they're isolated commits than after I've squashed them together. 144 misspelled word families; 47 files changed; 214 lines changed; There are only a handful of changes to actual code: dnsservers errsave ra_start_unsolicited I understand that some pieces in the git repo are contrib/ including a tarball with misspellings (contrib/webmin/dnsmasq.wbm). I can easily drop more things, but I'd need guidance. ___ 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] many tap devices, provide dhcp and ipv6 slaac
Hmm, one correction here - I just discovered that it is not true that "Linux does not allow overlapping CIDRs to be defined on multiple interfaces (in the same namespace)". So perhaps --interface=tap* on its own could work after all... Neil On Mon, May 30, 2016 at 7:48 PM Neil Jerram wrote: > Hi Vasiliy, > > My understanding is that Dnsmasq requires each IP allocation to be > associated with a Linux interface, and that the allocated IP must be > contained within one of the CIDRs on that Linux interface (e.g. as shown by > ifconfig ). In Dnsmasq terminology, a 'DHCP context' is defined > on the interface, and the IP allocation comes from the DHCP context. I > believe this is true even when all the allocations are static, i.e. defined > explicitly in the host file, as well as when allocations are from a dynamic > range. > > Therefore --interface=tap* does not work on its own - because Linux does > not allow overlapping CIDRs to be defined on multiple interfaces (in the > same namespace). > > (I would also be interested to hear the outcome of your libvirt > discussions about unbridged Ethernet interfaces. I believe libvirt > currently regards that scenario as deprecated and possibly insecure, but it > is the scenario that networking-calico uses too.) > > Regards, > Neil > > > Original Message > From: Vasiliy Tolstov > Sent: Friday, 27 May 2016 22:50 > To: Neil Jerram > Cc: dnsmasq-discuss > Subject: Re: [Dnsmasq-discuss] many tap devices, provide dhcp and ipv6 > slaac > > 2016-05-27 17:56 GMT+03:00 Neil Jerram : > > Hi Vasiliy, > > > > I assume your TAP devices are _not_ bridged on the host? > > > > If so, you can use the same approach as we use for Calico networking in > > OpenStack - > > > http://docs.openstack.org/developer/networking-calico/implementation-notes.html#dhcp > > > > You'll need: > > > > a dummy interface, with an address in the 85.143.220/24 CIDR > > to populate the dnsmasq hosts file with the IP/MAC mappings for your VMs > > to tell dnsmasq to listen on the dummy interface and all the TAPs, and > treat > > the TAPs as aliases of the dummy interface (using --bridge-interfaces). > > > > Hope that helps - happy to provide more detail if you need. > > > > Neil > > > > > > > Thanks! Does i need on dummy interface address with corresponding > netmask or i can use /32 address that acts like gateway for vm? > I have some discussion on libvirt mailing list about plain ethernet > devices and my next plans add ability to configure dnsmasq via libvirt > for this networks. > So in case of libvirt i have running dnsmasq on virtbr0 for example > and on each vm start i need to reconfigure dnsmasq to add needed tap > device to it? Why i can't use --interface=tap* ? DOes dnsmasq monitors > network intnerfaces via netlink and automatic listen it when it added > to the host? > > -- > Vasiliy Tolstov, > e-mail: v.tols...@yoctocloud.net > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] many tap devices, provide dhcp and ipv6 slaac
Hi Vasiliy, My understanding is that Dnsmasq requires each IP allocation to be associated with a Linux interface, and that the allocated IP must be contained within one of the CIDRs on that Linux interface (e.g. as shown by ifconfig ). In Dnsmasq terminology, a 'DHCP context' is defined on the interface, and the IP allocation comes from the DHCP context. I believe this is true even when all the allocations are static, i.e. defined explicitly in the host file, as well as when allocations are from a dynamic range. Therefore --interface=tap* does not work on its own - because Linux does not allow overlapping CIDRs to be defined on multiple interfaces (in the same namespace). (I would also be interested to hear the outcome of your libvirt discussions about unbridged Ethernet interfaces. I believe libvirt currently regards that scenario as deprecated and possibly insecure, but it is the scenario that networking-calico uses too.) Regards, Neil Original Message From: Vasiliy Tolstov Sent: Friday, 27 May 2016 22:50 To: Neil Jerram Cc: dnsmasq-discuss Subject: Re: [Dnsmasq-discuss] many tap devices, provide dhcp and ipv6 slaac 2016-05-27 17:56 GMT+03:00 Neil Jerram : > Hi Vasiliy, > > I assume your TAP devices are _not_ bridged on the host? > > If so, you can use the same approach as we use for Calico networking in > OpenStack - > http://docs.openstack.org/developer/networking-calico/implementation-notes.html#dhcp > > You'll need: > > a dummy interface, with an address in the 85.143.220/24 CIDR > to populate the dnsmasq hosts file with the IP/MAC mappings for your VMs > to tell dnsmasq to listen on the dummy interface and all the TAPs, and treat > the TAPs as aliases of the dummy interface (using --bridge-interfaces). > > Hope that helps - happy to provide more detail if you need. > > Neil > > Thanks! Does i need on dummy interface address with corresponding netmask or i can use /32 address that acts like gateway for vm? I have some discussion on libvirt mailing list about plain ethernet devices and my next plans add ability to configure dnsmasq via libvirt for this networks. So in case of libvirt i have running dnsmasq on virtbr0 for example and on each vm start i need to reconfigure dnsmasq to add needed tap device to it? Why i can't use --interface=tap* ? DOes dnsmasq monitors network intnerfaces via netlink and automatic listen it when it added to the host? -- Vasiliy Tolstov, e-mail: v.tols...@yoctocloud.net ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] many tap devices, provide dhcp and ipv6 slaac
Hi Vasiliy, I assume your TAP devices are _not_ bridged on the host? If so, you can use the same approach as we use for Calico networking in OpenStack - http://docs.openstack.org/developer/networking-calico/implementation-notes.html#dhcp You'll need: - a dummy interface, with an address in the 85.143.220/24 CIDR - to populate the dnsmasq hosts file with the IP/MAC mappings for your VMs - to tell dnsmasq to listen on the dummy interface and all the TAPs, and treat the TAPs as aliases of the dummy interface (using --bridge-interfaces). Hope that helps - happy to provide more detail if you need. Neil On Fri, May 27, 2016 at 3:32 PM Vasiliy Tolstov wrote: > Hi. I have such setup: > > ip -4 a s tap37183 > 148: tap37183: mtu 1500 qdisc htb > state UNKNOWN group default qlen 500 > link/ether fe:54:00:00:58:9f brd ff:ff:ff:ff:ff:ff > inet 85.143.216.1/32 scope global tap37183 >valid_lft forever preferred_lft forever > inet 192.168.240.110 peer 85.143.220.84/32 scope global tap37183 >valid_lft forever preferred_lft forever > > 85.143.216.1/32 is gw address for vm > > 192.168.240.110 peer 85.143.220.84/32 scope global tap37183 > this is host address with vm address added as peer (/32) > > What i need to add to dnsmasq conf to serve for this vm for dhcp > request with mac 25:54:00:00:58:9f address 85.143.220.84 with netmask > /24? > > Thanks! > -- > Vasiliy Tolstov, > e-mail: v.tols...@yoctocloud.net > > ___ > 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] Fix DHCPv4 reply via --bridge-interface alias interface
Thank you! Neil On 03/05/16 23:28, Simon Kelley wrote: > That seems quite straightforward. Thanks. Patch applied without change. > > Cheers, > > Simon. > > > > On 08/04/16 19:27, Neil Jerram wrote: >> I'm sorry not to have noticed this before now, but I just spotted that >> DHCPv4 handling via --bridge-interface interfaces was broken between >> v2.72 and v2.73. My further analysis and fix are in the attached patch. >> >> Regards, >> Neil >> >> >> >> ___ >> 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
[Dnsmasq-discuss] [PATCH] Fix DHCPv4 reply via --bridge-interface alias interface
I'm sorry not to have noticed this before now, but I just spotted that
DHCPv4 handling via --bridge-interface interfaces was broken between
v2.72 and v2.73. My further analysis and fix are in the attached patch.
Regards,
Neil
From f3d832b41f44c856003517c583fbd7af4dca722c Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Fri, 8 Apr 2016 19:23:47 +0100
Subject: [PATCH] Fix DHCPv4 reply via --bridge-interface alias interface
Sending a DHCPv4 reply through a --bridge-interface alias interface
was inadvertently broken by
commit 65c721200023ef0023114459a8d12f8b0a24cfd8
Author: Lung-Pin Chang
Date: Thu Mar 19 23:22:21 2015 +
dhcp: set outbound interface via cmsg in unicast reply
If multiple routes to the same network exist, Linux blindly picks
the first interface (route) based on destination address, which might not be
the one we're actually offering leases. Rather than relying on this,
always set the interface for outgoing unicast DHCP packets.
because in the aliasing case, iface_index is changed from the index of
the interface on which the packet was received, to be the interface
index of the 'bridge' interface (where the DHCP context is expected to
be defined, and so needs to be looked up).
For the cmsg code that the cited commit added, we need the original
iface_index; so this commit saves that off before the aliasing code
can change it, as rcvd_iface_index, and then uses rcvd_iface_index
instead of iface_index for the cmsg code.
---
src/dhcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index 658c934..5841f73 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -146,6 +146,7 @@ void dhcp_packet(time_t now, int pxe_fd)
struct iovec iov;
ssize_t sz;
int iface_index = 0, unicast_dest = 0, is_inform = 0;
+ int rcvd_iface_index;
struct in_addr iface_addr;
struct iface_param parm;
#ifdef HAVE_LINUX_NETWORK
@@ -230,6 +231,7 @@ void dhcp_packet(time_t now, int pxe_fd)
--bridge-interface option), change ifr.ifr_name so that we look
for DHCP contexts associated with the aliased interface instead
of with the aliasing one. */
+ rcvd_iface_index = iface_index;
for (bridge = daemon->bridges; bridge; bridge = bridge->next)
{
for (alias = bridge->alias; alias; alias = alias->next)
@@ -387,7 +389,7 @@ void dhcp_packet(time_t now, int pxe_fd)
msg.msg_controllen = sizeof(control_u);
cmptr = CMSG_FIRSTHDR(&msg);
pkt = (struct in_pktinfo *)CMSG_DATA(cmptr);
- pkt->ipi_ifindex = iface_index;
+ pkt->ipi_ifindex = rcvd_iface_index;
pkt->ipi_spec_dst.s_addr = 0;
msg.msg_controllen = cmptr->cmsg_len = CMSG_LEN(sizeof(struct in_pktinfo));
cmptr->cmsg_level = IPPROTO_IP;
--
1.9.1
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] prevent dnsmasq from releasing IPs
On 26/01/16 15:09, Stefan Priebe - Profihost AG wrote: >> Am 26.01.2016 um 14:46 schrieb Simon Kelley : >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> >> >>> On 26/01/16 13:42, Stefan Priebe - Profihost AG wrote: >>> what about writing and sending kill 1 / HUP? >> >> No. The only only way to make that work would be to >> >> 1) Stop dnsmasq with SIGTERM >> 2) modify the leases file >> 3) restart dnsmasq >> >> >> in that > Last idea isn't it possible to make the host static on add? If it is which > file should I use to add the mac hostname IP combination FYI, at https://github.com/projectcalico/calico/issues/233 we have a long trail about what we think is the opposite problem. Namely, that Dnsmasq will not reallocate an IP that should have been released, and whose old IP/MAC mapping has been removed from the 'host' config file. As you'll see if you read that trail, we thought this was caused by a problem in the delivery of the DHCP_RELEASE message to Dnsmasq, and hence Dnsmasq retaining a record of the old lease in its internal data. Based on that, I'd expect that if you deliberately did something to stop the DHCP_RELEASE message from reaching Dnsmasq, Dnsmasq would then retain the old lease (which I believe is what you're asking for). However, that understanding does seem to be contradicted by what Simon has said in this thread, and I would strongly assume that Simon is right - but perhaps there might still be some hint or useful information in that issue trail. Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcpv6 problem with static allocations and "no addresses available"
On 22/10/15 00:06, Carlos Carvalho wrote: > Simon Kelley (si...@thekelleys.org.uk) wrote on Wed, Oct 21, 2015 at > 07:51:32PM BRST: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> >> >> On 20/10/15 22:33, Carlos Carvalho wrote: >>> I'm stumbling on an important problem that looks like a bug in >>> dnsmasq. Clients declared statically in a zone are being denied >>> their address with the message "no addresses available": >>> >>> Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 available DHCPv6 >>> subnet: 2801:82:80ff:7f05::/64 Oct 20 09:56:10 dnsmasq-dhcp[18342]: >>> 6947286 vendor class: 40712 Oct 20 09:56:10 dnsmasq-dhcp[18342]: >>> 6947286 client MAC address: 10:bf:48:71:65:99 Oct 20 09:56:10 >>> dnsmasq-dhcp[18342]: 6947286 DHCPSOLICIT(meteo) >>> 00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99 Oct 20 09:56:10 >>> dnsmasq-dhcp[18342]: 6947286 DHCPADVERTISE(meteo) >>> 00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99 no addresses available >>> Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 tags: known, dhcpv6, >>> meteo Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 sent size: 14 >>> option: 1 client-id 00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99 Oct >>> 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 sent size: 10 option: 2 >>> server-id 00:03:00:01:00:24:8c:0c:37:90 Oct 20 09:56:10 >>> dnsmasq-dhcp[18342]: 6947286 sent size: 24 option: 13 status 2 no >>> addresses available >>> >>> Note that the client is recognized because the known tag is set. >>> The dhcp config is the following: >>> >>> interface=meteo dhcp-range=::,constructor:meteo,static,infinite >>> enable-ra dhcp-range=192.168.5.1,static Could it be because even static allocations still require a matching IP range to be configured? Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Serving DHCP requests from a subnet not matching the interface
Hi Johannes, Sorry, I've only just noticed this... On 03/06/15 06:52, Johannes Martin wrote: Hi, I have the following network setup: - eth0: 192.168.1.254/24 - br0: 192.168.10.254/24 bridging virtual interfaces eth0.10 and wlan0.10 (plain virtual interfaces, no vlan tagging) I have a dynamic dhcp range defined on the 192.168.1.0 subnet and a static dhcp range with static host entries (by mac address) defined on the 192.168.10.0 subnet. When a device connects through the wlan0 interface, dnsmasq properly serves the defined static addresses. However, when the devices connects through the eth0 interface, dnsmasq serves an address from the dynamic range even when a static address is defined for the device. So, dnsmasq does not realize that eth0 and eth0.10 are the same physical interface and that it is fine to serve an address that is valid only for eth0.10 on that physical interface. I wonder if --bridge-interface=br0,eth0 would do what you want? Except that I don't understand when you would actually _want_ a dynamic allocation from 192.168.1/24. I think that using --bridge-interface would mean that you'd _never_ get an allocation from 192.168.1/24. Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
Thanks Simon! On 10/06/15 22:49, Simon Kelley wrote: On 10/06/15 10:57, Neil Jerram wrote: Alternatively, here is the whole patch set again, regenerated so as to incorporate those deltas at the appropriate places. Many thanks for your time looking at these enhancements. Regards, Neil Many thanks. Patches applied, and 2.73rc10 generated. Unless anyone can give me a reason why not, this will become 2.73 in a couple of days. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
On 10/06/15 10:15, Neil Jerram wrote:
On 09/06/15 22:11, Simon Kelley wrote:
A couple of (very small quibbles)
-/* The source interface can only appear in at most
- one --bridge-interfaces. */
+/* The source interface! can only appear in at most
+ one --bridge-interface. */
Why does the interface get an exclamation mark? That's a typo? (I
probably only saw this because it's at the end)
second, the DHCPv4 code for the bridging looks like this.
for (bridge = daemon->bridges; bridge; bridge = bridge->next)
{
for (alias = bridge->alias; alias; alias = alias->next)
if (wildcard_matchn(alias->iface, ifr.ifr_name, IF_NAMESIZE))
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
my_syslog(LOG_WARNING, _("unknown interface %s in
bridge-interface"), ifr.ifr_name);
return;
}
else
{
strncpy(ifr.ifr_name, bridge->iface, IF_NAMESIZE);
break;
}
}
if (alias)
break;
which is wrong: the log message should be logging bridge->iface, not
ifr.ifr_name, but at least it does warn you when you do
--bridge-interface = somenonexistinginterface, alias
and therefore it's throwing away you DHCP packets.
The DHCPv6 code should implement that warning too.
I've been threatening a 2.73 release for so long that people have
stopped believing me, but the ducks do seem to be almost in a row, so
getting this finished soon would be good, if it's to go in.
Many thanks, Simon, I'll work on these remaining points immediately.
Would you prefer the deltas for them to be as additional patches, or to
have the patch set regenerated with the required deltas incorporated at
the appropriate places?
Here are the deltas to address those points.
Regards,
Neil
>From 67793b1936c99bd55241b7db90de74c88c463e60 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:20:14 +0100
Subject: [PATCH 6/9] Remove stray exclamation mark in radv.c comment
---
src/radv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/radv.c b/src/radv.c
index 532b698..39f1e92 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -826,7 +826,7 @@ time_t periodic_ra(time_t now)
free(aparam.alias_ifs);
}
-/* The source interface! can only appear in at most
+/* The source interface can only appear in at most
one --bridge-interface. */
break;
}
--
2.1.4
>From 21ede1039470657f4e0ae0a7161f629604cc8f38 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:25:42 +0100
Subject: [PATCH 7/9] dhcp.c: Log correct bridge interface name when
if_nametoindex fails for it
---
src/dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index daca6de..a2aa898 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -237,7 +237,7 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), ifr.ifr_name);
+ my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), bridge->iface);
return;
}
else
--
2.1.4
>From ac901e6fe7864e4e67c8199609d6e9c0c39620cf Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:42:50 +0100
Subject: [PATCH 8/9] dhcp6.c: Warn if if_nametoindex fails for bridge
interface name
---
src/dhcp6.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/dhcp6.c b/src/dhcp6.c
index 9683170..8286ff4 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -174,6 +174,13 @@ void dhcp6_packet(time_t now)
if (wildcard_matchn(alias->iface, ifr.ifr_name, IF_NAMESIZE))
{
parm.ind = if_nametoindex(bridge->iface);
+ if (!parm.ind)
+ {
+ my_syslog(MS_DHCP | LOG_WARNING,
+ _("unknown interface %s in bridge-interface"),
+ bridge->iface);
+ return;
+ }
break;
}
if (alias)
--
2.1.4
>From 594e4ceb58e533b3b31a4e983cfcd9937271cd70 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:43:54 +0100
Subject: [PATCH 9/9] dhcp.c: Add MS_DHCP to log about unrecognized bridge
interface name
---
src/dhcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index a2aa898..e6fceb1 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -237,7 +237,9 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), br
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
On 10/06/15 10:47, Neil Jerram wrote:
On 10/06/15 10:15, Neil Jerram wrote:
On 09/06/15 22:11, Simon Kelley wrote:
A couple of (very small quibbles)
-/* The source interface can only appear in at most
- one --bridge-interfaces. */
+/* The source interface! can only appear in at most
+ one --bridge-interface. */
Why does the interface get an exclamation mark? That's a typo? (I
probably only saw this because it's at the end)
second, the DHCPv4 code for the bridging looks like this.
for (bridge = daemon->bridges; bridge; bridge = bridge->next)
{
for (alias = bridge->alias; alias; alias = alias->next)
if (wildcard_matchn(alias->iface, ifr.ifr_name, IF_NAMESIZE))
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
my_syslog(LOG_WARNING, _("unknown interface %s in
bridge-interface"), ifr.ifr_name);
return;
}
else
{
strncpy(ifr.ifr_name, bridge->iface, IF_NAMESIZE);
break;
}
}
if (alias)
break;
which is wrong: the log message should be logging bridge->iface, not
ifr.ifr_name, but at least it does warn you when you do
--bridge-interface = somenonexistinginterface, alias
and therefore it's throwing away you DHCP packets.
The DHCPv6 code should implement that warning too.
I've been threatening a 2.73 release for so long that people have
stopped believing me, but the ducks do seem to be almost in a row, so
getting this finished soon would be good, if it's to go in.
Many thanks, Simon, I'll work on these remaining points immediately.
Would you prefer the deltas for them to be as additional patches, or to
have the patch set regenerated with the required deltas incorporated at
the appropriate places?
Here are the deltas to address those points.
Alternatively, here is the whole patch set again, regenerated so as to
incorporate those deltas at the appropriate places.
Many thanks for your time looking at these enhancements.
Regards,
Neil
>From c5748da52f2d789637d50f899862f0a83f385ea2 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:25:42 +0100
Subject: [PATCH 1/7] dhcp.c: Log correct bridge interface name when
if_nametoindex fails for it
---
src/dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index f1f43f8..ef976e8 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -236,7 +236,7 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), ifr.ifr_name);
+ my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), bridge->iface);
return;
}
else
--
2.1.4
>From 1ee8223a1d26cda1ecbdc421f530ceb594592899 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Wed, 10 Jun 2015 10:43:54 +0100
Subject: [PATCH 2/7] dhcp.c: Add MS_DHCP to log about unrecognized bridge
interface name
---
src/dhcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/dhcp.c b/src/dhcp.c
index ef976e8..eb1ea81 100644
--- a/src/dhcp.c
+++ b/src/dhcp.c
@@ -236,7 +236,9 @@ void dhcp_packet(time_t now, int pxe_fd)
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
- my_syslog(LOG_WARNING, _("unknown interface %s in bridge-interface"), bridge->iface);
+ my_syslog(MS_DHCP | LOG_WARNING,
+ _("unknown interface %s in bridge-interface"),
+ bridge->iface);
return;
}
else
--
2.1.4
>From 138dd675f9bbfa87894af3c9d83ba25960cdf18d Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Mon, 15 Sep 2014 14:45:01 +0100
Subject: [PATCH 3/7] Implement aliasing idea (per --bridge-interfaces) for
DHCPv6 as well as for v4
---
src/dhcp6.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/src/dhcp6.c b/src/dhcp6.c
index ee2aa5d..4c60c6e 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -144,6 +144,8 @@ void dhcp6_packet(time_t now)
if ((port = relay_reply6(&from, sz, ifr.ifr_name)) == 0)
{
+ struct dhcp_bridge *bridge, *alias;
+
for (tmp = daemon->if_except; tmp; tmp = tmp->next)
if (tmp->name && wildcard_match(tmp->name, ifr.ifr_name))
return;
@@ -160,6 +162,30 @@ void dhcp6_packet(time_t now)
memset(&parm.fallback, 0, IN6ADDRSZ);
memset(&parm.ll_addr, 0, IN6ADDRSZ);
memset(&parm.ula_addr, 0, IN6ADDRSZ);
+
+ /* If the interface on which the DHCPv6 request was received is
+ an alias of some other interface (as specified by the
+ --bridge-interfaces option), change par
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
On 09/06/15 22:11, Simon Kelley wrote:
On 08/06/15 12:37, Neil Jerram wrote:
I'm sorry, this is a really old thread that I'm only just now getting
back to.
As a reminder, it's a set of patches that extend the semantics of
--bridge-interface to DHCPv6 and router advertisements. Our last
exchange (as below) was about fixing a subtle difference in behaviour
between the v4 and v6 cases, and this email provides the revised patch
set that addresses that point, and also:
- is rebased to current master
- improves the documentation around --bridge-interface, specifically so
that it doesn't appear to be for BSD platforms only.
My team has been running with this for a while - albeit on a base of
2.72 - so we have some confidence that the patches are correct.
Please would you consider merging these patches into upstream dnsmasq?
Yes. How can I resist a patchset which not only updated the
documentation, but does it in multiple languages?
0004 made me scratch my head for a while, but I think I got it. The
method of expanding the alias wildcard is scary, but I can't see a
better way to do it.
A couple of (very small quibbles)
-/* The source interface can only appear in at most
- one --bridge-interfaces. */
+/* The source interface! can only appear in at most
+ one --bridge-interface. */
Why does the interface get an exclamation mark? That's a typo? (I
probably only saw this because it's at the end)
second, the DHCPv4 code for the bridging looks like this.
for (bridge = daemon->bridges; bridge; bridge = bridge->next)
{
for (alias = bridge->alias; alias; alias = alias->next)
if (wildcard_matchn(alias->iface, ifr.ifr_name, IF_NAMESIZE))
{
if (!(iface_index = if_nametoindex(bridge->iface)))
{
my_syslog(LOG_WARNING, _("unknown interface %s in
bridge-interface"), ifr.ifr_name);
return;
}
else
{
strncpy(ifr.ifr_name, bridge->iface, IF_NAMESIZE);
break;
}
}
if (alias)
break;
which is wrong: the log message should be logging bridge->iface, not
ifr.ifr_name, but at least it does warn you when you do
--bridge-interface = somenonexistinginterface, alias
and therefore it's throwing away you DHCP packets.
The DHCPv6 code should implement that warning too.
I've been threatening a 2.73 release for so long that people have
stopped believing me, but the ducks do seem to be almost in a row, so
getting this finished soon would be good, if it's to go in.
Many thanks, Simon, I'll work on these remaining points immediately.
Would you prefer the deltas for them to be as additional patches, or to
have the patch set regenerated with the required deltas incorporated at
the appropriate places?
Regards,
Neil
Cheers,
Simon.
Many thanks,
Neil
On 13/10/14 17:45, Simon Kelley wrote:
On 07/10/14 18:28, Neil Jerram wrote:
On 03/10/14 16:54, Neil Jerram wrote:
I'd like to propose the attached patches, which extend the aliasing
concept of the --bridge-interface option to DHCPv6 and Router
Advertisement processing. [...]
A query: the semantics you've provided for DHCPv6 are subtly different
than those that exist for DHCPv4.
In DHCPv4, the alias is absolute, eg
bridge-interface=eth0,tap0
when a packet arrives at tap0, then it is processed as if it arrived at
eth0, any addresses associated with tap0 are ignored.
With this patch, for DHCPv6, dnsmasq first attempts to find a
DHCP-context by using the addresses associated with tap0, and only if
that fails does it use the addresses associated with eth0.
Indeed, good catch - I had missed that.
If this is required behaviour, I guess we should document the
difference
in the v4 and v6 cases. If it's like that by chance, we should think
about if providing the same behaviour in both cases might be
preferable.
It isn’t required behaviour. At least, for the compute host scenario
that I am interested in, the alias interfaces will never have any IP
addressing or contexts of their own, and also the aliased interface -
i.e. the one that _does_ have the DHCP context - will never receive a
packet directly itself. Therefore, for my purposes, it would be fine
to align the DHCPv6 behaviour precisely with the v4 behaviour.
Logically I think the same should also apply to solicited RA
processing, i.e. in the ND_ROUTER_SOLICIT block of icmp6_packet.
Would you agree?
Yes, certainly.
Finally, I guess I should also update the "One form of bridging ..."
comment in dhcp_packet, and the man page text on --bridge-interfaces,
to mention my scenario in addition to the BSD one.
Yes, that's well out-of-date.
If that all sounds good to you, I'm
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
I'm sorry, this is a really old thread that I'm only just now getting
back to.
As a reminder, it's a set of patches that extend the semantics of
--bridge-interface to DHCPv6 and router advertisements. Our last
exchange (as below) was about fixing a subtle difference in behaviour
between the v4 and v6 cases, and this email provides the revised patch
set that addresses that point, and also:
- is rebased to current master
- improves the documentation around --bridge-interface, specifically so
that it doesn't appear to be for BSD platforms only.
My team has been running with this for a while - albeit on a base of
2.72 - so we have some confidence that the patches are correct.
Please would you consider merging these patches into upstream dnsmasq?
Many thanks,
Neil
On 13/10/14 17:45, Simon Kelley wrote:
On 07/10/14 18:28, Neil Jerram wrote:
On 03/10/14 16:54, Neil Jerram wrote:
I'd like to propose the attached patches, which extend the aliasing
concept of the --bridge-interface option to DHCPv6 and Router
Advertisement processing. [...]
A query: the semantics you've provided for DHCPv6 are subtly different
than those that exist for DHCPv4.
In DHCPv4, the alias is absolute, eg
bridge-interface=eth0,tap0
when a packet arrives at tap0, then it is processed as if it arrived at
eth0, any addresses associated with tap0 are ignored.
With this patch, for DHCPv6, dnsmasq first attempts to find a
DHCP-context by using the addresses associated with tap0, and only if
that fails does it use the addresses associated with eth0.
Indeed, good catch - I had missed that.
If this is required behaviour, I guess we should document the difference
in the v4 and v6 cases. If it's like that by chance, we should think
about if providing the same behaviour in both cases might be preferable.
It isn’t required behaviour. At least, for the compute host scenario
that I am interested in, the alias interfaces will never have any IP
addressing or contexts of their own, and also the aliased interface -
i.e. the one that _does_ have the DHCP context - will never receive a
packet directly itself. Therefore, for my purposes, it would be fine
to align the DHCPv6 behaviour precisely with the v4 behaviour.
Logically I think the same should also apply to solicited RA
processing, i.e. in the ND_ROUTER_SOLICIT block of icmp6_packet.
Would you agree?
Yes, certainly.
Finally, I guess I should also update the "One form of bridging ..."
comment in dhcp_packet, and the man page text on --bridge-interfaces,
to mention my scenario in addition to the BSD one.
Yes, that's well out-of-date.
If that all sounds good to you, I'm happy to work on updating the
patches - please let me know what you think.
Please do. Happy to have this.
Cheers,
Simon.
Regards,
Neil
>From db3a9ba6b21694b9583f87e948d9de722004697c Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Mon, 15 Sep 2014 14:45:01 +0100
Subject: [PATCH 1/5] Implement aliasing idea (per --bridge-interfaces) for
DHCPv6 as well as for v4
---
src/dhcp6.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/src/dhcp6.c b/src/dhcp6.c
index ee2aa5d..e803f35 100644
--- a/src/dhcp6.c
+++ b/src/dhcp6.c
@@ -144,6 +144,8 @@ void dhcp6_packet(time_t now)
if ((port = relay_reply6(&from, sz, ifr.ifr_name)) == 0)
{
+ struct dhcp_bridge *bridge, *alias;
+
for (tmp = daemon->if_except; tmp; tmp = tmp->next)
if (tmp->name && wildcard_match(tmp->name, ifr.ifr_name))
return;
@@ -160,6 +162,23 @@ void dhcp6_packet(time_t now)
memset(&parm.fallback, 0, IN6ADDRSZ);
memset(&parm.ll_addr, 0, IN6ADDRSZ);
memset(&parm.ula_addr, 0, IN6ADDRSZ);
+
+ /* If the interface on which the DHCPv6 request was received is
+ an alias of some other interface (as specified by the
+ --bridge-interfaces option), change parm.ind so that we look
+ for DHCPv6 contexts associated with the aliased interface
+ instead of with the aliasing one. */
+ for (bridge = daemon->bridges; bridge; bridge = bridge->next)
+ {
+ for (alias = bridge->alias; alias; alias = alias->next)
+ if (wildcard_matchn(alias->iface, ifr.ifr_name, IF_NAMESIZE))
+ {
+ parm.ind = if_nametoindex(bridge->iface);
+ break;
+ }
+ if (alias)
+ break;
+ }
for (context = daemon->dhcp6; context; context = context->next)
if (IN6_IS_ADDR_UNSPECIFIED(&context->start6) && context->prefix == 0)
@@ -208,7 +227,7 @@ void dhcp6_packet(time_t now)
/* May have configured relay, but not DHCP server */
if (!daemon->doing_dhcp6)
return;
-
+
lease_prune(NULL, now); /* lose any expired leases */
port = dhcp6_reply(parm.current, if_index, ifr.ifr_name, &parm.fallback,
--
2.1.4
>F
[Dnsmasq-discuss] Multiple dnsmasq instances binding to same interfaces?
Hi there! Does anyone know offhand what the detailed semantics are for multiple dnsmasq instances trying to bind to and receive DHCP packets from the same interfaces? My reason for asking is that I'm running a test with two dnsmasq instances, both of which are instructed to bind to all TAP interfaces (--interface=tap* --bind-dynamic). Each instance is intended to provide DHCP for a subset of those TAP interfaces, and each subset is specified by putting the expected MAC and IP addresses for that subset in the host file that that dnsmasq instance will read. (This is in the context of an OpenStack compute host, where each TAP interfaces connects through to a VM.) The strange thing is that this test reliably works - in the sense of each TAP interface getting its correct IP address - whereas I would expect it sometimes to fail because of an incoming DHCP request sometimes being delivered to the wrong dnsmasq instance. Dnsmasq uses SO_REUSEPORT, which I think means that multiple instances can successfully bind to the same interface. However, I believe the per-packet semantic for SO_REUSEPORT is that a particular incoming packet will only be delivered to one of the bindings. So, I don't understand how things are currently working! Can anyone throw any light on this? Many thanks, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] SLAAC is working, but DHCPv6 isn't
> > Hi Ken, > > > >> Running a packet capture on both my server and a host, I can see the > >> "solict" packet from the host to the server; however the server doesn't > >> send an "advertise" packet back to the client (but logging in syslog > >> says that it *did* send a DHCPADVERTISE, and shows a valid IPv6 address > >> that it "offered" the client.) > >> > >> No firewall rules prevent this communication; they're wide open for > >> internal traffic. > >> > >> Would anyone have ideas on why dnsmasq isn't replying to the solicit > >> (but saying that it did)? > > > > How sure are you that dnsmasq doesn't send the DHCPADVERTISE? Have > > you already done something else, e.g. running tcpdump, in order to be > > sure that that message isn't sent? Could it be that the message is > > sent but for some reason doesn't reach the client? > > > > Regards, > > Neil > > > > > > Hi Neil, > > I did say that I was running packet captures on both the server and the > host. If dnsmasq had sent any replies, I would have seen them leaving > the server, even if they didn't reach the client for whatever reason. I'm sorry. I don't know how I managed to miss that you'd written that. > I'm wondering if there's some complex interaction between the items in > my configuration that causes some rare bug to manifest; again, SLAAC > works just fine at the same time. I assume others have it working fine > - anything strange about the config I posted? Surely the order doesn't > matter, right? I'm afraid I'm stumped. Your config looks reasonable to me. Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] SLAAC is working, but DHCPv6 isn't
Hi Ken, > Running a packet capture on both my server and a host, I can see the > "solict" packet from the host to the server; however the server doesn't > send an "advertise" packet back to the client (but logging in syslog > says that it *did* send a DHCPADVERTISE, and shows a valid IPv6 address > that it "offered" the client.) > > No firewall rules prevent this communication; they're wide open for > internal traffic. > > Would anyone have ideas on why dnsmasq isn't replying to the solicit > (but saying that it did)? How sure are you that dnsmasq doesn't send the DHCPADVERTISE? Have you already done something else, e.g. running tcpdump, in order to be sure that that message isn't sent? Could it be that the message is sent but for some reason doesn't reach the client? Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
> On 03/10/14 16:54, Neil Jerram wrote: > > I'd like to propose the attached patches, which extend the aliasing > > concept of the --bridge-interface option to DHCPv6 and Router > > Advertisement processing. [...] > > A query: the semantics you've provided for DHCPv6 are subtly different > than those that exist for DHCPv4. > > In DHCPv4, the alias is absolute, eg > > bridge-interface=eth0,tap0 > > when a packet arrives at tap0, then it is processed as if it arrived at > eth0, any addresses associated with tap0 are ignored. > > With this patch, for DHCPv6, dnsmasq first attempts to find a > DHCP-context by using the addresses associated with tap0, and only if > that fails does it use the addresses associated with eth0. Indeed, good catch - I had missed that. > If this is required behaviour, I guess we should document the difference > in the v4 and v6 cases. If it's like that by chance, we should think > about if providing the same behaviour in both cases might be preferable. It isn’t required behaviour. At least, for the compute host scenario that I am interested in, the alias interfaces will never have any IP addressing or contexts of their own, and also the aliased interface - i.e. the one that _does_ have the DHCP context - will never receive a packet directly itself. Therefore, for my purposes, it would be fine to align the DHCPv6 behaviour precisely with the v4 behaviour. Logically I think the same should also apply to solicited RA processing, i.e. in the ND_ROUTER_SOLICIT block of icmp6_packet. Would you agree? Finally, I guess I should also update the "One form of bridging ..." comment in dhcp_packet, and the man page text on --bridge-interfaces, to mention my scenario in addition to the BSD one. If that all sounds good to you, I'm happy to work on updating the patches - please let me know what you think. Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 Server for Android
Hi Praveen, > I would like to run the DHCPv6 Server on android devices. > Please provide us the info to run the dnsmasq for such use case. > Please provide all necessary info like configuration and command line > arguments etc. May I suggest that you first look at the dnsmasq man page? You can find this at http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html. In particular please see the documentation for the "--dhcp-range" option; this is fundamentally what enables DHCP server operation (IIUC). After that, I expect you'll be able to ask more precise questions about anything that you still don't understand. Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Patches: Extend --bridge-interface aliasing to DHCPv6 and Router Advertisements
Hi all, I'd like to propose the attached patches, which extend the aliasing concept of the --bridge-interface option to DHCPv6 and Router Advertisement processing. Prior to these patches, the effect of the --bridge-interface option is limited to DHCPv4. I think it's a natural extension for it to apply to DHCPv6 and RAs as well. I should give a little background about the scenario motivating this. As with my previous patch [1, 2], the scenario is that of a compute host providing connectivity and DHCP for a number of VMs or containers, where the data into and out of the TAP (or veth) interfaces to those VMs/containers is routed rather than being bridged. In this scenario, the desire is to provide DHCPv4, DHCPv6 and Router Advertisements to all the TAP/veth interfaces, from a DHCP/RA context specification on some other interface. [1] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008600.html [2] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=70772c909199ad6701dc25593bc185938fa4cd23 I hope that makes sense. Please can you let me know what you think, including whether these patches are suitable for dnsmasq? Many thanks, Neil 0001-Implement-aliasing-idea-per-bridge-interfaces-for-DH.patch Description: 0001-Implement-aliasing-idea-per-bridge-interfaces-for-DH.patch 0002-Allow-configuration-of-on-link-L-bit-in-Router-Adver.patch Description: 0002-Allow-configuration-of-on-link-L-bit-in-Router-Adver.patch 0003-Implement-aliasing-idea-per-bridge-interfaces-for-so.patch Description: 0003-Implement-aliasing-idea-per-bridge-interfaces-for-so.patch 0004-Implement-aliasing-for-unsolicited-router-advertisem.patch Description: 0004-Implement-aliasing-for-unsolicited-router-advertisem.patch 0005-Documentation-for-IPv6-enhancements.patch Description: 0005-Documentation-for-IPv6-enhancements.patch ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Patch: Allow wildcard aliases in --bridge-interface option
Simon Kelley wrote: > On 11/06/14 15:49, Neil Jerram wrote: > > Hi Simon, > > > > Please would you consider the attached patch, which allows a trailing '*' > wildcard > > in each that is specified in the --bridge-interface option. My team > is > > working on a new form of host/VM networking where VM data is routed instead > of > > bridged, and this patch allows us to use dnsmasq as the DHCP server in that > scenario. > > > > [...] > > That's very clever. Patch accepted and applied in git. Many thanks! As a followup, may I ask broadly when you might do a next dnsmasq feature release (assuming that that would include this change)? I don't mean to suggest any pressure one way or the other, but just to get some feeling for your schedule or release algorithm. Regards, Neil ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Patch: Allow wildcard aliases in --bridge-interface option
Hi Simon, Please would you consider the attached patch, which allows a trailing '*' wildcard in each that is specified in the --bridge-interface option. My team is working on a new form of host/VM networking where VM data is routed instead of bridged, and this patch allows us to use dnsmasq as the DHCP server in that scenario. You'll see that the patch updates the English and French man pages accordingly. It doesn't update the Spanish one because - assuming I've understood it correctly - that version doesn't yet mention the existing wildcarding possibility for the --interface option; hence there wasn't some nice idiomatic text that I could reuse for --bridge-interface. Many thanks, Neil 0001-Allow-wildcard-aliases-in-bridge-interface-option.patch Description: 0001-Allow-wildcard-aliases-in-bridge-interface-option.patch ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
