Opened 9 years ago

Last modified 8 years ago

#107 new defect

avahi-reflector seems to cause name conflicts

Reported by: antifuchs Owned by: lennart
Milestone: Component: avahi-core
Keywords: reflector Cc:


We're having troubles with spurious reports of name conflicts when an avahi-reflector is involved.

At the metalab (, we have a simple network setup: a router that does NAT, and a wired and wireless network segment; to ensure that the wired and wireless network segments can get at each others' mdns names, there's an avahi daemon that is configured as a reflector running on the NAT router. The problem with this setup is that since we installed the avahi reflector, machines (most notably apple laptops) report that their name is already in use and pick another name.

This happens at random intervals; sometimes it happens when machines wake up from sleep, sometimes qhen they have been running for some time. At no time could we find an actual naming conflict when one was reported; the affected machine will just pick a new name, but referrals to the old name are (of course) broken.

Thanks, Andreas.

PS: This problem has been plagueing us for quite some time now; I wanted to wait with this bug report until I could provide a packet capture, but I haven't had much luck yet. I'll certainly put one up here if I get lucky.

Change History (5)

comment:1 Changed 9 years ago by lathiat

I've actually noticed this in the past, but have been unable to get a reliable repetition and I think we fixed 1 bug in relation to this.

if you could provide me with a packet dump it would be good if you don't want to file it publically you can e-mail myself and lennart (e-mails available on the website) privately

What version are you running?

comment:2 Changed 9 years ago by antifuchs

Lennart, thanks for the confirmation.

We found a way to reliably reproduce it using Mac OS X clients: Every time a user connects to another network, and then connects to the reflected network, the naming conflict happens: A dialog box pops up, saying that there was a naming conflict. The crucial thing is that they must be connected to the non-reflected network for some time, apparently.

We have acquired a pcap, but it was made without -s0, meaning that none of the actual queries were logged. )-:

So, partial success. Stay tuned for a packet capture.

comment:3 Changed 8 years ago by Sen

I can confirm this problem still persists on 10.4 Tiger and 10.5 Leopard. It does seem to happen when we restart the server (Ubuntu Gutsy with Avahi-daemon 0.6.20) and leave the clients connected.

Any info on how to capture the packets?

comment:4 Changed 8 years ago by anders

A perhaps related observation (i've got the same setup, same problem)...

Assuming a service A on LanA/eth0, avahi-browse -a shows (on the router) that service as being available on TWO interfaces:

+ eth0 IPv4 Notes @ Internet Printer local + wlan0 IPv4 Notes @ Internet Printer local

It seems as if avahi fools itself into thinking that the service is actually available on the two lans (eventhough one is a 'pretend' service fixed by itself). I guess if it _has_ fooled itself, then it's conceivable that it starts to defend that service name on _all_ interfaces, causing havoc when the server the service runs on reboots. I once ended up with a -24 ... :-(


comment:5 Changed 8 years ago by Sen

Any update on this ticket?

Note: See TracTickets for help on using tickets.