<div dir="ltr">Hi Martin,<div><br></div><div>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.</div><div><br></div><div>I see that several years ago someone posted a similar issue as described in this thread: <a href="http://lists.freedesktop.org/archives/avahi/2012-September/002183.html">http://lists.freedesktop.org/archives/avahi/2012-September/002183.html</a></div><div><br></div><div>He then provided a patch in this thread:</div><div><a href="http://lists.freedesktop.org/archives/avahi/2012-September/002187.html">http://lists.freedesktop.org/archives/avahi/2012-September/002187.html</a><br></div><div><br></div><div>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.</div><div><br></div><div>Why was this patch never acknowledged or pulled?</div><div><br></div><div>-Jared</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Date: Fri, 1 Jan 2016 23:29:52 +0100<br>
From: Martin Nyolt <<a href="mailto:8e3b3cde@gmail.com">8e3b3cde@gmail.com</a>><br>
To: <a href="mailto:avahi@lists.freedesktop.org">avahi@lists.freedesktop.org</a><br>
Subject: Re: [avahi] getaddrinfo (Avahi) returning unreachable IP<br>
        address for .local hostname<br>
Message-ID: <<a href="mailto:5686FDE0.7080702@gmail.com">5686FDE0.7080702@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hi Jared.<br>
<br>
(First, please note that I'm also quite new to avahi and this mailing list. I might not have all necessary information.)<br>
<br>
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.<br>
If the machine has two addresses in two networks (say <a href="http://169.254.0.0/16" rel="noreferrer" target="_blank">169.254.0.0/16</a> and <a href="http://192.16.0.0/24" rel="noreferrer" target="_blank">192.16.0.0/24</a>), it wouldn't know which to prefer:<br>
* there may be machines which are *only* in the <a href="http://169.254.0.0/16" rel="noreferrer" target="_blank">169.254.0.0/16</a> net (because no DHCP was available) and<br>
*there may also be machines which are *only* in the <a href="http://192.16.0.0/24" rel="noreferrer" target="_blank">192.16.0.0/24</a> net (because DHCP was available when setting up the interface).<br>
For this reason, mixing self-configured IPv4 <a href="http://169.254.0.0/16" rel="noreferrer" target="_blank">169.254.0.0/16</a> addresses with addresses in other networks is not recommended [1]. Therefore, you should probably fix the multiple addresses.<br>
<br>
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.<br>
So maybe avahi needs some re-design with regard to that RFC?<br>
<br>
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.<br>
<br>
<br>
Best regards,<br>
Martin<br>
<br>
<br>
[1]: RFC 3972, Section 1.9: <a href="https://tools.ietf.org/html/rfc3927#section-1.9" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc3927#section-1.9</a><br>
[2]: RFC 6762, Section 6.2: <a href="https://tools.ietf.org/html/rfc6762#section-6.2" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc6762#section-6.2</a><br>
<br>
On 31/12/15 19:29, Jared Albers wrote:<br>
> Hi Guys,<br>
><br>
> I'm using 'getaddrinfo' to resolve .local hostnames in an application.<br>
> However I've encountered a scenario in which the address being returned for<br>
> a device is a self-assigned IPv4 address (169.254.X.X) that can't be<br>
> reached on any interface by the host machine. I'm assuming this because the<br>
> host machine has received an IPv4 address via the DHCP server and therefore<br>
> there is no reason to also have a self-assigned address?<br>
><br>
> It is my understanding that 'getaddrinfo' will ultimately use Avahi to<br>
> resolve .local hostnames as defined in the 'hosts:' line of the<br>
> 'nsswitch.conf' file. It is also my understanding according to this old<br>
> thread (<a href="http://lists.freedesktop.org/archives/avahi/2009-May/001644.html" rel="noreferrer" target="_blank">http://lists.freedesktop.org/archives/avahi/2009-May/001644.html</a>),<br>
> that by design Avahi returns only one IP address when resolving.<br>
><br>
> As such, I'd like to better understand why 'getaddrinfo' is returning an<br>
> unreachable address for a host. Is this a bug in Avahi?<br>
><br>
> The device in question has three addresses (1 self-assigned IPv4, 1<br>
> DHCP-assigned IPv4, and 1 IPv6). If by design Avahi will only return a<br>
> single address to 'getaddrinfo', why isn't it returning a reachable address?<br>
><br>
> If I force binding a self-assigned address via 'avahi-autoipd --force-bind<br>
> eth0', then I'm able to communicate with the device. Alternatively, if I<br>
> force communication over IPv6, I'm also able to communicate with the device.<br>
><br>
> However, both of the above mentioned techniques aren't really suitable<br>
> solutions. It seems inappropriate and potentially problematic for an<br>
> application to bind a self-assigned IP address to an interface, and relying<br>
> solely on IPv6 to communicate won't work if the user has disabled IPv6<br>
> addressing (perhaps for compatibility reasons).<br>
><br>
> How do I go about fixing this issue?<br>
><br>
> -Jared<br></blockquote></div></div></div>