[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