[Pkg-utopia-maintainers] Bug#587961: Bug#587961: avahi-daemon: patch for #517160 affects more than just reflector

[Julien BLACHE]

Lennart Poettering <lennart at poettering.net> wrote:

Hi Lennart, Michael,

> Hmm, if I parse this correctly then you have two machines. One running
> 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?

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 ;)

> 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".

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?

> 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

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?

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

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.

-- 
 Julien BLACHE <jblache at debian.org>  |  Debian, because code matters more 
 Debian & GNU/Linux Developer        |       <http://www.debian.org>
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169