Spurious name conflicts

[callegar]

Hi, hope this is the right place for reporting issues with avahi-daemon as the readme on my system points to the bugtracker on freedesktop.org that does not list avahi as a bug report target.

I am experiencing spurious name conflicts on various systems, all of which have a common trait in having two interfaces, one on the local lan, having a static IP address and the other getting a dhcp address from somewhere (typically an ADSL router).

What happens is the following. Suppose that the host is called "foo". Initially, it is correctly advertised as foo.local. After some time the name conflict occurs and the host starts being advertised as foo-2.local, foo-3.local, etc., even if it is certainly the sole host named foo on the network. In practice there is a spurious name conflict with the host itself, probably due to some race in avahi. The unfortunate result is that no other system cannot find "foo" no more on the network, since they look for foo.local.

I see the issue on a couple of debian jessie systems (avahi version 0.6.31); on a raspbian jessie system (same); and on an openwrt chaos calmer system (avahi version 0.6.31 again).

I see a lot of reports for this same issue (or possibly something similar) on many distro bugtrackers, applications bugtrackers and question sites:

• https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/831022
• https://serverfault.com/questions/714917/host-name-conflict-with-avahi-daemon-on-ubuntu-14-04-lts
• avahi hostname conflict foosel/netconnectd#8
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771806
• https://lists.freedesktop.org/archives/avahi/2011-March/001995.html

I wonder if there is something misconfigured on my systems (and in this case some hit at diagnosing would be appreciated) or if this is an issue (possibly a race) with the avahi daemon.

Even if this cannot be fixed rapidly, I'd like to suggest an interim point release of avahi with an option to disable the name conflict analysis when he/she is absolutely sure that it won't be needed on his/her network.

[lathiat]

I agree that I have seen this from time to time, unfortunately I am not currently sure what causes it. I think in some cases it might be related to the reflector, but if that is not in use I am not sure.

How often is this happening? I wonder if we can setup a long term pcap capture to try and figure out what happens.

[callegar]

Rather frequently, I see it almost every odd day.

It seems to be associated to a lease expire on the interface getting the address from dhcp and probably has to do with the fact that there is both an IPv4 and an IPv6 address configured for the interface...

Apr 27 07:30:57 xyz dhcpcd[365]: eth0: soliciting a DHCPv6 lease
Apr 27 07:30:57 xyz dhcpcd[365]: eth0: fe80::6a7f:74ff:fe15:6a2e router available
Apr 27 07:30:57 xyz dhcpcd[365]: eth0: ADV fd57:81fe:80da::218/128 from fe80::6a7f:74ff:fe15:6a2e
Apr 27 07:30:57 xyz dhcpcd[365]: eth0: REPLY6 received from fe80::6a7f:74ff:fe15:6a2e
Apr 27 07:30:57 xyz dhcpcd[365]: eth0: adding address fd57:81fe:80da::218/128
Apr 27 07:30:57 xyz dhcpcd[365]: eth0: renew in 21600 seconds, rebind in 34560 seconds
Apr 27 07:30:57 xyz dhcpcd[365]: eth0: using IPv4LL address 169.254.139.60
Apr 27 07:30:57 xyz dhcpcd[365]: eth0: adding route to 169.254.0.0/16
Apr 27 07:30:57 xyz avahi-daemon[24276]: Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.139.60.
Apr 27 07:30:57 xyz avahi-daemon[24276]: New relevant interface eth0.IPv4 for mDNS.
Apr 27 07:30:57 xyz avahi-daemon[24276]: Registering new address record for 169.254.139.60 on eth0.IPv4.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::600c:b99e:4f17:ce61.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Joining mDNS multicast group on interface eth0.IPv6 with address fd57:81fe:80da:0:c99b:6cc1:2a7c:c139.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Registering new address record for fd57:81fe:80da:0:c99b:6cc1:2a7c:c139 on eth0.*.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing address record for fe80::600c:b99e:4f17:ce61 on eth0.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing address record for fe80::a92:e068:3cb:7ae2 on wlan0.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing address record for 169.254.208.59 on wlan0.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing address record for 192.168.32.1 on wlan0.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing workstation service for wlan0.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing address record for 169.254.139.60 on eth0.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing workstation service for eth0.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Withdrawing workstation service for lo.
Apr 27 07:30:58 xyz avahi-daemon[24276]: Host name conflict, retrying with xyz-2

[callegar]

I don't think that the reflector should be on anywhere, as it should be disabled by default, shouldn't it?

[callegar]

Preventing avahi-daemon from using the interface where the address is received from a dhcp server makes the issue disappear, but obviously it is not a solution.

[midicase]

Avahi can't handle inter-connected multi-homed systems. We have to use the option to disable one of the interfaces to avoid the daemon from seeing mutliple name registration requests (one from each network).

Best I can tell there isn't a better solution since this is really an issue with the design of the protocol.

[callegar]

Still I wonder...

1. why do I not just see a -1, but also a -2 and every now and then a -3 too?
2. wouldn't it be possible to have the two interfaces both managed by avahi-daemon with a reproducible name assignment? Like getting from the very start hostname.local for the IP on the one of the two nics and hostname-2.local for the name on the other nic, rather than having things in one way at boot and then getting the -x suffix when the dhcp lease is renewed?
   I am asking because the issue is not the -2, but not knowing in advance how an host will be reachable.

[lathiat]

I totally had this happen on one of my own systems, with a very similar looking log to you. Downed and uped a bunch of interfaces rapidly. There must definitely be a bug there I'll have to try and figure out if I can make it reproducible.

Some kind of race to do with the new interfaces appearing while probing perhaps.. there is a related issue for services that get stuck registering. So maybe the logic for interfaces coming and going needs to be reviewed.

[lathiat]

OK I think I figured it out. What's happening is an address is withdrawn before it finishes probing, but we receive a copy of our own probe immediately after and thus assume a conflict (our own multicast probes are mirrored back to us by the kernel). A bit of a race condition.

This happens a lot with IPv6 where we withdraw the fe80 link-local address once we receive a global address and can happen very rapidly on boot. Of note you are using IPv6 on your site, as well as mine where I am seeing this. On IPv4 address withdrawls while probing are quite uncommon.

So we'll need to identify those in some way, either with a ghost list or otherwise determining that the probe looped back. I'll look at that.

[lathiat]

Confirmed the issue as I suspected, we withdraw our address record but only then receive a copy of our own probe and decide it is a conflict:

Jun 20 15:40:58 hyper avahi-daemon[6567]: Joining mDNS multicast group on interface vsw3.IPv6 with address fe80::9cf5:4ff:fef6:ec81.
Jun 20 15:40:58 hyper avahi-daemon[6567]: Registering new address record for fe80::9cf5:4ff:fef6:ec81 on vsw3.*.
Jun 20 15:40:58 hyper avahi-daemon[6567]: Leaving mDNS multicast group on interface vsw3.IPv6 with address fe80::9cf5:4ff:fef6:ec81.
Jun 20 15:40:58 hyper avahi-daemon[6567]: Withdrawing address record for fe80::9cf5:4ff:fef6:ec81 on vsw3.
Jun 20 15:40:58 hyper avahi-daemon[6567]: Received conflicting probe [hyper.local#011IN#011AAAA fe80::9cf5:4ff:fef6:ec81 ; ttl=120]. Local host lost. Withdrawing.

This happens because we revoke the link-local address from being advertised once we receive a global address.

Hope to have a fix for this shortly