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, broader call for reproducibility check
Date: Mon, 11 Jan 2021 04:47:11 -0600	[thread overview]
Message-ID: <74b7a0a9-0eb3-7944-19d2-f72424ee72d7@dasyatidae.com> (raw)
In-Reply-To: <83czymc8nq.fsf@gnu.org>

I'm sorry I haven't been able to get back to this the way I'd hoped;
too many things to deal with last week, and the machines I was planning
to use are having their own issues which I want to make sure are fixed
first...

Eli Zaretskii wrote:
>   With AI_ALL and AI_V4MAPPED flags:
> 
>     (network-lookup-address-info "he.net")
>       => ([216 218 236 2 0] [8193 1136 0 1283 0 0 0 2 0])
> 
>     (network-lookup-address-info "he.net" 'ipv6)
>       => ([0 0 0 0 0 65535 55514 60418 0])
> 
>     (network-lookup-address-info "ipv6.google.com")
>       => nil: WSANO_DATA error
> 
>     (network-lookup-address-info "ipv6.google.com" 'ipv6)
>       => nil: WSAHOST_NOT_FOUND error
> 
>   Without the AI_* flags:
> 
>     (network-lookup-address-info "he.net")
>       => ([216 218 236 2 0])
> 
>     (network-lookup-address-info "he.net" 'ipv6)
>       => nil: WSANO_DATA error
> 
>     (network-lookup-address-info "ipv6.google.com")
>       => nil: WSAHOST_NOT_FOUND error
> 
>     (network-lookup-ddress-info "ipv6.google.com" 'ipv6)
>       => nil: WSANO_DATA error
> 
> Note the difference in he.net resolution with and without the 'ipv6
> argument, and also the behavior of ipv6.google.com with the ipv6
> argument.  Interesting, no?

Definitely. The behavior of "he.net" with 'ipv6 in the former group
is something I think of as to be avoided, per elsethread, but this
shows the latter truncation for nil more concretely, of course...
and the error-swapping behavior with "ipv6.google.com" is bizarre
and hard to reconcile with earlier observations, especially the
nil-family case. I wonder whether that changes with 'ipv4?

Your ipconfig result showed no "real" IPv6 connectivity, which is
about what I'd have expected but at least sweeps some tangential
possibilities away. Unfortunately there isn't a clear way to get
an idea of what upstream resolvers might be doing from the host
configuration. It occurs to me that there may be something
nsswitch-like going on as well, but I don't know what that would
be on Windows OTTOMH and I haven't had time to research it.

Thanks for showing the details; it helps avoid misunderstandings.

In the meantime, if others on the list would be willing to test these
on Windows and/or with unusual resolver configurations, especially
if you can get or point to a packet dump of how a Windows system
converts different getaddrinfo parameters to DNS requests on the
wire (and the responses, if comfortable with that), that would also
be useful. In particular, if this turns out to be specific to
Windows but not specific to that one host's network, then it may
make sense to set some flags conditioned on OS. I am also curious
whether AI_ALL _without_ AI_V4MAPPED does anything on Windows, per
what I mentioned upthread.

-RTT "Why is wanting things to be correct so messy sometimes"



  reply	other threads:[~2021-01-11 10:47 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
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     ` Robin Tarsiger [this message]
2021-01-11 12:42       ` ai_flags in calls to getaddrinfo, broader call for reproducibility check 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=74b7a0a9-0eb3-7944-19d2-f72424ee72d7@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).