[Dnsmasq-discuss] New smart --bind-dynamic is greedy (binds also to interface aliases)
Simon Kelley
simon at thekelleys.org.uk
Mon May 13 09:28:19 BST 2013
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.
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.
More information about the Dnsmasq-discuss
mailing list