Re: ai_flags in calls to getaddrinfo

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Robin Tarsiger <rtt@dasyatidae.com>
> Date: Fri, 1 Jan 2021 05:40:48 -0600
> 
> Some non-zero return values from getaddrinfo, including EAI_NODATA,
> don't actually indicate resolution failures. From glibc getaddrinfo(3),
> there's also EAI_NONAME and EAI_ADDRFAMILY. I think the real point
> of difficulty is that network_lookup_address_info_1 always turns these
> into messageable warnings. To be clear, is that the behavior you are
> seeing on the Windows 10 machine, or is there some different
> failure occurring?

That's exactly what I see: the addresses return as nil and a warning
message is displayed.

> I notice that EAI_NODATA isn't mentioned in the Windows docs[1],

Yes, because Windows has its own codes for socket-related errors.
Look for WSANO_DATA.  I said "EAI_NODATA" to avoid using Windows
specific terminology that people might be unfamiliar with.

> but if it's actually getting returned, I'd guess it has the same
> semantics as in glibc: "got a valid result indicating no addresses
> found".

The Windows text is "The requested name is valid, but no data of the
requested type was found."

> From an elisp standpoint, what do you want to have actually happen:
> 
>  1. If a program requests a name that doesn't exist at all?

A failure, of course.

>  2. If a program requests a name that exists and has addresses of
>     some families (such as IPv4 addresses), but the program has
>     specifically requested another family (such as IPv6)?

The address returned when AI_V4MAPPED is used is a valid IPv6 address,
isn't it?  That is, it can be used in IPv6 connections, and will allow
such connections to work as intended, right?  Then I'd expect to have
them if a "real" IPv6 address is not available for some reason.

>  3. If a program requests a name that exists but has no addresses
>     at all? This is entirely possible in the DNS; dasyatidae.com
>     is even currently such a name, having only MX records and no
>     address records.

In that case, wouldn't using AI_V4MAPPED produce an error and/or an
empty list of addresses anyway?  If so, that is the result I'd expect.

> Based on the docstring, I would imagine a silent nil for all three.
> In particular, the docstring implies that out-of-family addresses
> are _not_ returned when FAMILY is not nil. But I don't know how
> elisp programs currently use network-lookup-address-info.

If this is a documentation issue, we can easily make the doc string
more detailed (until yesterday it didn't even mention the warning
message that is displayed in the case of a problem).  the current text
is not sacred, nor does it define a spec or the contract for that API
in any shape or form.

I don't have enough experience with using the results of the address
resolution in Emacs, which is why I asked the questions.  But it seems
to me that if using these additional flags produces usable addresses,
then using these flags is a good idea, because it will allow
connections using the resolution results in more cases.

> >From another perspective, when would a program pass a non-nil
> FAMILY value in the first place? If a program just wants any
> address, that's already handled by passing nil for FAMILY.

Again, isn't the address returns when AF_INET6 and AI_V4MAPPED are
used a valid IPv6 address that can be used in IPv6 connections?  If
so, then the program which specified FAMILY does get what it asked
for.

> >> Does it have any IPv6 addresses configured, or no? What is
> >> its resolver configuration like?
> > 
> > No idea.  If you tell me how to find out, I will try.  This system is
> > behind firewalls up the kazoo, so it could be something essential for
> > IPv6 DNS is blocked or intentionally disabled.
> 
> If you run 'ipconfig/all' from a command line (which, if you are not
> familiar, you can launch by running 'cmd' from the 'Run' dialog,
> which in turn can be accessed through the Windows+R shortcut), it
> should display a bunch of information about active network connections,
> including local IP addresses and DNS resolver addresses.

Will do, thanks.

> To put it differently: from my perspective, the main use for AI_V4MAPPED
> is when there is no IPv4-handling code path at all, and all IPv4 addresses
> are routed through the "IPv6" path as compatibility-mapped, which can
> save some complexity and hassle elsewhere.

Isn't that the common use case?

> If you code against "true" multi-address-family, then it's just a
> faucet for bugs (say, trying to filter out some IPv4 netblocks but
> then letting them through anyway when they come through mapped into
> pseudo-IPv6 addresses).

Lisp programs that want to be so strict will have no problem
identifying "fake" IPv6 addresses and filtering them out, I think.

> >        If hints.ai_flags specifies the AI_V4MAPPED flag, and
> >        hints.ai_family was specified as AF_INET6, and no matching IPv6
> >        addresses could be found, then return IPv4-mapped IPv6 addresses
> >        in the list pointed to by res.  If both AI_V4MAPPED and AI_ALL
> >        are specified in hints.ai_flags, then return both IPv6 and
> >        IPv4-mapped IPv6 addresses in the list pointed to by res.  AI_ALL
> >        is ignored if AI_V4MAPPED is not also specified.
> > 
> > So it does sound like these flags do have effect on GNU/Linux.
> 
> If ai_family is AF_INET6, it does. I don't think it has an effect if
> ai_family is AF_UNSPEC. I am not 100% sure, but a quick test with
> resolving some names from a GNU/Linux machine (v4-only, v6-only,
> dual-stack) with AF_UNSPEC didn't return anything different with
> AI_V4MAPPED or AI_V4MAPPED | AI_ALL compared to none of those.

It did change on Windows.  I don't have a GNU/Linux machine on that
network to try that.

> >> What about "localhost"?
> > Works as expected, without EAI_NODATA.
> 
> I interpret "as expected" to mean that when you ask for localhost
> in AF_INET6, you get ::1 back. Is that right?

Yes.

> > On the
> > system in question, using the patched code and nil as FAMILY in the
> > network-lookup-address-info yields the expected result, including,
> > surprisingly, what looks like a valid IPv6 address, even though
> > specifying 'ipv6 for FAMILY does indeed return a compatibility-hacked
> > IPv4 address.
> 
> What happens if you pass nil for FAMILY but without the AI_V4MAPPED
> patch, on that system?

I get only an IPv4 address.

> Have you observed AI_V4MAPPED producing better
> results in any circumstance when you do not set FAMILY to ipv6?

Yes, as reported in my original message: I get both IPv4 and IPv6
addresses if I use AI_ALL | AI_V4MAPPED.

> > I found about this issue because 2 tests in test/src/process-tests.el
> > failed, both of them called network-lookup-address-info with second
> > arg 'ipv6'.
> 
> You mean lookup-family-specification and lookup-google, I imagine?

Yes.

> Hmm. If I get a chance, I will see what Emacs does with the forms
> from those tests on one of my Windows machines and report back.

Thanks.