Hi,

The patch for #517160, filtering out link-local addresses, affects more than
just the reflector feature of avahi-daemon.

With the patch applied, it is impossible to get a link-local IPv6 address
when resolving a service, which is an issue when the LL address is the only
address advertised by the device.

This is the case with Apple's devices (#517160 takes the AirPort Extreme as an
example, the same is true for the AirPort Express) that only advertise their
LL IPv6 address via mDNS, even if they have a global address configured.

So in effect, it is no longer possible to rely on Avahi to reach any device
with a similar behaviour over IPv6.

The LL filtering should be done only for the reflector.

JB.

Hi Julien,

I just uploaded 0.6.26-1 which contains a fix for
http://avahi.org/ticket/300

Could you please test if that also solves your particular issue and report back.

Thanks,
Michael

Michael Biebl <biebl@debian.org> wrote:

Hi,

I do get the link local addresses now, but alas I only get the
link local addresses now.

While working on this a couple months back, reverting the original patch
for #517160 would give me all the addresses.

So there's still something that isn't quite right.

JB.

Michael Biebl <biebl@debian.org> wrote:

Hi Michael,

Looking at the code again, the patch does the right thing and the code
is now correct in its handling of link local addresses wrt reflector.

The remaining issue is that avahi should be better at choosing the IPv4
address it sends back to the client when resolving a service. Working
IPv4 LL is all but a given.

I think avahi should not return an IPv4 LL address when a global address
is also advertised if the host doesn't have a link local address
configured on the interface avahi got the mDNS response from.

I'll leave it up to you to close or retitle this bug.

Thanks,

JB.

some mDNS stack that's not Avahi which announces both an IPv4LL and a global
address. And another one which runs Avahi and when contacting the first
machine ends up using the IPv4LL address of the first one, and you dont
want that to happen? Is that correct?

Avahi tries to be smart with the addresses it announces, and it only
announces one address at a timne, and picks the best local address it
can find for that. (i.e. preferring gloabl addresses over IPv4LL if both
are available).

Now, for the A/AAAA records it receives from other hosts it will just
return to the resolving applications the first one the hosts sends. This
is kinda mandated by the resolving scheme which basically says "browse
for an A/AAAA record and return the first one you find".

Or in other words: it should be the job of the announcer to pick the
best address to announce, not the lookup client to pick the best address
it finds. Because the former can have complete knowledge of what is
available and the latter cannot.

What really puzzles me though is why this is even a problem. Doesn't
Debian set up the IP4VLL routes properly? i.e. see:
http://avahi.org/wiki/AvahiAutoipd

If those routes are in place it shouldn't matter much which address
Avahi returns to the lookup clients, because all are equally usable.

Lennart

Lennart Poettering <lennart@poettering.net> wrote:

Hi Lennart, Michael,

It is. The peer is an Apple device, an AirPort Express in this case, but
this is true of other Apple devices. They advertise their IPv4LL,
IPv6LL and global IPv4 address if configured. Funny thing, they don't
advertise their global-scope IPv6 address if they have one.

But then, IPv6LL works out of the box, so there isn't really a need for
the global-scope v6 address, unless you count on reflecting the mDNS
annoucements to another network which, I guess, is totally outside the
use case for Apple ;)

A quick test with wireshark running during an avahi-browse -r -k _raop._tcp
shows that the answer contains 1 RR (PTR) and the additional section
contains 5 RRs in this order:
 - AAAA with IPv6LL
 - A with global IPv4 address
 - SRV
 - TXT
 - A with IPv4LL

So if the first A RR returned by the peer was the one returned by Avahi
when resolving, I shouldn't be getting the IPv4LL here. Unless there's
more to it?

I read up on IPv4 LL yesterday and actually added the routes (well not
the default route, as it's supposedly not needed in this case) on two
different machines, running two different kernels with different network
interfaces, and it did not work.

Tried again just now and it did work. Not sure what's going on here.

The avahi-autoipd package installs an if-up.d script that adds the
IPv4LL routes. AIUI avahi-autoipd is meant to act as a fallback when
DHCP fails, so it will generally not be installed on hosts configured
with a static IP address.

That if-up.d script should probably be moved to ifupdown. Note that it
could also be enhanced to handle more than one interface; as it is,
only the first interface brought up will get the LL route due to the
way the check is done.

Michael, any thoughts on that?

As long as the routes do work and the machine isn't multihomed :) As I
wrote earlier, working IPv4LL is all but a given...

Thanks,

JB.