From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: ai_flags in calls to getaddrinfo Date: Fri, 01 Jan 2021 09:43:50 +0200 Message-ID: <838s9dgkzt.fsf@gnu.org> References: <83sg7mggls.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26210"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Robin Tarsiger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 01 08:44:59 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kvF7K-0006eG-Hn for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 08:44:58 +0100 Original-Received: from localhost ([::1]:45310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvF7J-0005vH-JD for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 02:44:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41584) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvF6Y-0005RN-P5 for emacs-devel@gnu.org; Fri, 01 Jan 2021 02:44:10 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40137) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvF6Y-0006Nc-F8; Fri, 01 Jan 2021 02:44:10 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2614 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kvF6X-0000O7-30; Fri, 01 Jan 2021 02:44:09 -0500 In-Reply-To: (message from Robin Tarsiger on Thu, 31 Dec 2020 16:40:18 -0600) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262219 Archived-At: > From: Robin Tarsiger > Cc: emacs-devel@gnu.org > Date: Thu, 31 Dec 2020 16:40:18 -0600 > > 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? MS-Windows 10. > Does the host actually have an IPv6 network stack > at all? Yes, I think so. > 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. > What names are you looking up in > order to obtain the EAI_NODATA answer google.com and a few others. > 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)? Happens with all the names I tried, but I didn't try the above two. Yes, there is an Internet connection. > What about "localhost"? Works as expected, without EAI_NODATA. > > 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.) Yes, I understand that much. But it could be better than a total failure, at least in some use cases, no? That's why this flag exists, right? > > - 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. According to the GNU/Linux getaddrinfo man page: 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. 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. > > #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. If this is controversial, maybe having it as opt-in behavior, controlled by some new optional argument, would be useful? 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'. The patch I propose fixed the failures. So at least in this simple case the current code behaves as if IPv6 DNS doesn't work in Emacs, whereas actually it isn't the fault of Emacs at all, and using these flags produces a correct result for the test. Thus, I wonder whether these flags couldn't be useful in other use cases as well. Thanks.