unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Robin Tarsiger <rtt@dasyatidae.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: ai_flags in calls to getaddrinfo
Date: Thu, 31 Dec 2020 16:40:18 -0600	[thread overview]
Message-ID: <bdba96d2-18be-cc93-0f48-d2c0b9e4ef13@dasyatidae.com> (raw)
In-Reply-To: <83sg7mggls.fsf@gnu.org>

Eli Zaretskii wrote:
> On one of the systems on which I work, getaddrinfo called with
> AF_INET6 fails with EAI_NODATA, for some reason.  That causes
> network-lookup-address-info to fail when passed 'ipv6' as the last
> argument.
What OS is this on? Does the host actually have an IPv6 network stack
at all? Does it have any IPv6 addresses configured, or no? What is
its resolver configuration like? What names are you looking up in
order to obtain the EAI_NODATA answer---does it happen with all
names, including for instance "he.net" or "ipv6.google.com" (assuming
this system is connected to the Internet in the first place)? What
about "localhost"?

> Adding the AI_V4MAPPED flag, as in the patch below, seems to solve the
> problem.  So I wonder why we don't do this in general.  I'm not an
> expert on DNS, so would people who know more than I do about this
> please comment on whether the patch below is a good idea?

AI_V4MAPPED is meant for the case where an application expects only
IPv6-formatted addresses in a list, but a host with only IPv4 addresses
should have those addresses included in a mangled form. It is an
address format compatibility hack. (The compatibility hack extends
to other parts of the network stack, so that attempting to connect to
such an address actually results in IPv4 packets on the wire, etc.)

> diff --git a/src/process.c b/src/process.c
> index 28ab15c903..f550703c2a 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -4559,12 +4559,18 @@ DEFUN ("network-lookup-address-info", Fnetwork_lookup_address_info,
>  
>    memset (&hints, 0, sizeof hints);
>    if (EQ (family, Qnil))
> -    hints.ai_family = AF_UNSPEC;
> +    {
> +      hints.ai_family = AF_UNSPEC;
> +      hints.ai_flags = AI_ALL | AI_V4MAPPED;
> +    }

On a GNU system, I think this will do nothing; it's not clear to me
what AI_V4MAPPED would even mean when ai_family = AF_UNSPEC,
because AF_UNSPEC means IPv4 addresses can be returned directly.

>  #ifdef AF_INET6
>    else if (EQ (family, Qipv6))
> -    hints.ai_family = AF_INET6;
> +    {
> +      hints.ai_family = AF_INET6;
> +      hints.ai_flags = AI_V4MAPPED;
> +    }
>  #endif

And what this would do is allow returning IPv4 addresses crammed
into the IPv6 compatibility format to an elisp caller that has
specifically asked for IPv6, when looking up a host with only
IPv4 addresses. I would consider this unexpected behavior; I
would think the elisp code would pass nil and receive those
addresses in native IPv4 format if it wanted to process them.
There is not nearly as much need for the compatibility hack when
data structures are not as rigid as in C.

So I think the new code looks wrong, but per the more extended
questions above, it's possible I don't understand the problem
it's meant to fix; my experience with this part of networking
code is primarily from the perspective of GNU/Linux systems
in fairly conventional configurations.

-RTT



  reply	other threads:[~2020-12-31 22:40 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-31 15:06 ai_flags in calls to getaddrinfo Eli Zaretskii
2020-12-31 22:40 ` Robin Tarsiger [this message]
2021-01-01  7:43   ` Eli Zaretskii
2021-01-01 11:40     ` Robin Tarsiger
2021-01-01 12:04       ` Robin Tarsiger
2021-01-01 12:48       ` Eli Zaretskii
2021-01-02  0:19         ` Robin Tarsiger
2021-01-03 16:00   ` Eli Zaretskii
2021-01-11 10:47     ` ai_flags in calls to getaddrinfo, broader call for reproducibility check Robin Tarsiger
2021-01-11 12:42       ` Robert Pluim
2021-01-11 15:25       ` Eli Zaretskii
2021-01-11 15:47         ` Robert Pluim
2021-01-11 16:44           ` Eli Zaretskii
2021-01-11 17:07             ` Robin Tarsiger
2021-01-11 17:53               ` Robert Pluim
2021-01-11 18:30                 ` Robin Tarsiger
2021-01-11 18:42                   ` Robert Pluim
2021-01-11 19:28                     ` Stefan Monnier
2021-01-11 20:12                       ` Robert Pluim
2021-01-11 20:41                         ` Eli Zaretskii
2021-01-11 20:55                           ` Stefan Monnier
2021-01-11 21:02                           ` Robert Pluim
2021-01-11 21:09                             ` Lars Ingebrigtsen
2021-01-11 21:15                               ` Robert Pluim
2021-01-11 22:42                                 ` Lars Ingebrigtsen
2021-01-12  9:40                                   ` Robert Pluim
2021-01-12 12:49                                     ` Lars Ingebrigtsen
2021-01-12 13:04                                       ` Robert Pluim
2021-01-12 14:08                                         ` Lars Ingebrigtsen
2021-01-12 14:29                                           ` Robert Pluim
2021-01-12 18:06                                             ` Lars Ingebrigtsen
2021-01-12 15:14                                       ` Stefan Monnier
2021-01-12 15:45                                         ` Eli Zaretskii
2021-01-12  3:29                             ` Eli Zaretskii
2021-01-11 20:46                 ` Eli Zaretskii
2021-01-11 20:56                   ` Robert Pluim
2021-01-12 15:01                     ` Eli Zaretskii
2021-01-12 15:36                       ` Robert Pluim
2021-01-12 15:42                       ` Eli Zaretskii
2021-01-12 16:00                         ` Robert Pluim
2021-01-12 16:05                           ` Eli Zaretskii
2021-01-12 17:56                             ` Robert Pluim
2021-01-11 19:32           ` Basil L. Contovounesios
2021-01-11 20:19             ` Robert Pluim
2021-01-11 23:57           ` Andy Moreton
2021-01-12  9:44             ` Robert Pluim
2021-01-12 11:56               ` tomas
2021-01-01 10:59 ` ai_flags in calls to getaddrinfo Lars Ingebrigtsen
2021-01-01 12:50   ` Eli Zaretskii
2021-01-02  5:40     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bdba96d2-18be-cc93-0f48-d2c0b9e4ef13@dasyatidae.com \
    --to=rtt@dasyatidae.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).