[avahi] getaddrinfo (Avahi) returning unreachable IP address for .local hostname

[Jared Albers]

Hi Martin,

Unfortunately the device in question is a 3rd-party embedded device, more
specifically the Apple AirPort Express. I have no control over its
self-assigned addresses.

I see that several years ago someone posted a similar issue as described in
this thread:
http://lists.freedesktop.org/archives/avahi/2012-September/002183.html

He then provided a patch in this thread:
http://lists.freedesktop.org/archives/avahi/2012-September/002187.html

I do not see if/when the patch was acknowledged and committed. I've also
downloaded the latest 0.6.31 source tarball and I do not see any reference
to the proposed changes.

Why was this patch never acknowledged or pulled?

-Jared


> Date: Fri, 1 Jan 2016 23:29:52 +0100
> From: Martin Nyolt <8e3b3cde at gmail.com>
> To: avahi at lists.freedesktop.org
> Subject: Re: [avahi] getaddrinfo (Avahi) returning unreachable IP
>         address for .local hostname
> Message-ID: <5686FDE0.7080702 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Jared.
>
> (First, please note that I'm also quite new to avahi and this mailing
> list. I might not have all necessary information.)
>
> As far as I understand from that old thread, avahi publishes only one
> address per interface - i.e. the machine decides which of its addresses it
> will publish.
> If the machine has two addresses in two networks (say 169.254.0.0/16 and
> 192.16.0.0/24), it wouldn't know which to prefer:
> * there may be machines which are *only* in the 169.254.0.0/16 net
> (because no DHCP was available) and
> *there may also be machines which are *only* in the 192.16.0.0/24 net
> (because DHCP was available when setting up the interface).
> For this reason, mixing self-configured IPv4 169.254.0.0/16 addresses
> with addresses in other networks is not recommended [1]. Therefore, you
> should probably fix the multiple addresses.
>
> Yet, in contrast to that old post from 2009, RFC 6762 says that a response
> MUST include all addresses for the interface [2]. Section 6.4 also
> recommends response aggregation, which aleviates the problem of waiting for
> multiple responses to "guarantee" an exhaustive answer.
> So maybe avahi needs some re-design with regard to that RFC?
>
> Of course, it might be possible to determine which address to return based
> on the source address of the querying machine. But this is not how avahi
> publishing and mDNS works, I think.
>
>
> Best regards,
> Martin
>
>
> [1]: RFC 3972, Section 1.9:
> https://tools.ietf.org/html/rfc3927#section-1.9
> [2]: RFC 6762, Section 6.2:
> https://tools.ietf.org/html/rfc6762#section-6.2
>
> On 31/12/15 19:29, Jared Albers wrote:
> > Hi Guys,
> >
> > I'm using 'getaddrinfo' to resolve .local hostnames in an application.
> > However I've encountered a scenario in which the address being returned
> for
> > a device is a self-assigned IPv4 address (169.254.X.X) that can't be
> > reached on any interface by the host machine. I'm assuming this because
> the
> > host machine has received an IPv4 address via the DHCP server and
> therefore
> > there is no reason to also have a self-assigned address?
> >
> > It is my understanding that 'getaddrinfo' will ultimately use Avahi to
> > resolve .local hostnames as defined in the 'hosts:' line of the
> > 'nsswitch.conf' file. It is also my understanding according to this old
> > thread (http://lists.freedesktop.org/archives/avahi/2009-May/001644.html
> ),
> > that by design Avahi returns only one IP address when resolving.
> >
> > As such, I'd like to better understand why 'getaddrinfo' is returning an
> > unreachable address for a host. Is this a bug in Avahi?
> >
> > The device in question has three addresses (1 self-assigned IPv4, 1
> > DHCP-assigned IPv4, and 1 IPv6). If by design Avahi will only return a
> > single address to 'getaddrinfo', why isn't it returning a reachable
> address?
> >
> > If I force binding a self-assigned address via 'avahi-autoipd
> --force-bind
> > eth0', then I'm able to communicate with the device. Alternatively, if I
> > force communication over IPv6, I'm also able to communicate with the
> device.
> >
> > However, both of the above mentioned techniques aren't really suitable
> > solutions. It seems inappropriate and potentially problematic for an
> > application to bind a self-assigned IP address to an interface, and
> relying
> > solely on IPv6 to communicate won't work if the user has disabled IPv6
> > addressing (perhaps for compatibility reasons).
> >
> > How do I go about fixing this issue?
> >
> > -Jared
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/avahi/attachments/20160102/3e6273bb/attachment.html>