[Dnsmasq-discuss] New smart --bind-dynamic is greedy (binds also to interface aliases)
Tomas Hozza
thozza at redhat.com
Mon May 13 10:01:13 BST 2013
----- Original Message -----
> On 13/05/13 01:00, Andrew Bartlett wrote:
> > I've looked over the source code multiple times, and I can't see how it
> > happens, but I've just filed
> > https://bugzilla.redhat.com/show_bug.cgi?id=962246 with Fedora, and
> > figured I would also work here to see how this can be fixed.
> >
> > I do agree that interface detection is some of the most crazy,
> > OS-specific code ever. Oddly Samba has much the same challenge, but
> > seems to use a different set of APIs.
> >
> > In any case what happens is this:
> >
> > dnsmasq is being run by libvirt like this:
> > /sbin/dnsmasq --strict-order --local=// --domain-needed
> > --pid-file=/var/run/libvirt/network/default.pid --conf-file=
> > --except-interface lo --bind-dynamic --interface virbr0 --dhcp-range
> > 192.168.122.2,192.168.122.254
> > --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
> > --dhcp-lease-max=253 --dhcp-no-override
> >
> > I then run:
> > ifconfig virbr0:0 192.168.122.2
> >
> > And then I find dnsmasq has also chosen to bind to 192.168.122.2!
> >
> > eg this in netstat
> >
> > tcp 0 0 192.168.122.2:53 0.0.0.0:*
> > LISTEN 1039/dnsmasq
> > tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN
> > 1039/dnsmasq
> > udp 0 0 192.168.122.2:53 0.0.0.0:*
> > 1039/dnsmasq
> > udp 0 0 192.168.122.1:53 0.0.0.0:*
> > 1039/dnsmasq
> > udp 0 0 0.0.0.0:67 0.0.0.0:*
> > 1039/dnsmasq
> > unix 2 [ ] DGRAM 21571 1039/dnsmasq
> >
> > I'm presuming somewhere we are comparing on a name without the alias (:0)
> > bit, or doing a length-limited comparison, but I've looked and just can't
> > find it!
> >
> > Andrew Bartlett
> >
>
> My guess about what's happening, (and I've not looked thoroughly, at
> least yet) is this.
>
> Linux long ago moved past the idea of interface aliases and into
> complete support for multiple addresses of the same address family per
> interface.
>
> There's backwards compatible support for aliases, so that
>
> ifconfig virbr0:0 192.168.122.2
>
> has been redefined to mean something like "add another IP address to
> eth0, and give it the backwards-compatible name eth0:0"
>
> If you use the more modern "ip" command to look at things, this becomes
> obvious: after
>
> ifconfig eth0:0 192.168.99.1
>
> if I do
>
> ip addr show
>
> I get
>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000
> link/ether 00:11:25:a1:91:c5 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.193/24 brd 192.168.0.255 scope global eth0
> inet 192.168.99.1/24 brd 192.168.99.255 scope global eth0:0
> ........
>
> So, there's just another address in eth0, but it has the wierd eth0:0 on
> the end.
>
> Dnsmasq is using netlink to enumerate all the addresses associated with
> interfaces, passes the interface index to ioctl(..., SIOCGIFNAME, ...)
> to find the name of the interface associated with each address. I think
> that both addresses probably have the same index and therefore that
> always returns eth0 and not eth0:0 in my example. That would explain
> what you're seeing exactly.
>
> There are various ways we could proceed:
>
> 1) I could tell you to stop using old-fashioned aliases, and specify
> which addresses you want dnsmasq to listen in directly using
> --listen-address
>
> 2) I could find out the API to get the "alias name" associated with an
> address and change the behaviour of dnsmasq.
I don't think that changing behaviour of --bind-dynamic is a good thing
to do. If you are going to change anything please make it optional.
--bind-dynamic has been available for some time already and I think
there are some people that might be depending on its behaviour (although
I don't know any).
Maybe another way to go is to better describe the behaviour of --bind-dynamic
when used with interface aliases in dnsmasq man page.
>
> 3) We could check my wild guesses above, and find that something else
> entirely is happening.
>
>
> I'm currently highly agnostic about which will come to pass.
>
>
> Cheers,
>
> Simon.
Regards,
Tomas Hozza
More information about the Dnsmasq-discuss
mailing list