From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robin Tarsiger Newsgroups: gmane.emacs.devel Subject: Re: ai_flags in calls to getaddrinfo Date: Thu, 31 Dec 2020 16:40:18 -0600 Message-ID: References: <83sg7mggls.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19743"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 31 23:41:08 2020 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 1kv6d1-000536-NN for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Dec 2020 23:41:07 +0100 Original-Received: from localhost ([::1]:40200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kv6d0-0007IU-QB for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Dec 2020 17:41:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kv6c6-0006gP-48 for emacs-devel@gnu.org; Thu, 31 Dec 2020 17:40:10 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:60821) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kv6c4-0002wp-Ev; Thu, 31 Dec 2020 17:40:09 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 254C45C00DB; Thu, 31 Dec 2020 17:40:05 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 31 Dec 2020 17:40:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=miHpYTqJQ+h8AAsURfce3o91eOj26h+GVoE2IxE9r hM=; b=ngMD6M2mI2Ai4+yZh21rrfat39Vu1ZkI5B+G0VIbg0Nv6VH0FcvJbflBu p3/1M9fLYeSwM1pUM7xT/SlUgoPlTnQJYDOEGpsL4ftFwnlD9qPka55dAl3Nmxoj IAbmYmiMek5DNgWtZAxNxIqvz3zqqTJ7PD6vLWpyLoFyxAcatN9eHhuTOCxbuotr RTKNSLpn0I8PAM1Em00ZIPhWM2D5GGnWnqnSHYfYyaHJEfuwK1pemHFA5TrBG2qm wmTx3lxnWgnJT04fI3X6oxL2X0vRWeyIxzFxZsZ2Fqy/hnBpx1Pqoxva8xU1pGb/ CUeteF0M86JHytvkrtX33vuLwuWeQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvhedgudeihecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefvfhfhuffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeftohgs ihhnucfvrghrshhighgvrhcuoehrthhtsegurghshigrthhiuggrvgdrtghomheqnecugg ftrfgrthhtvghrnhepudfgueeuheehieeukedvieetgfejjedtiedutdegtdffiefgieef udehvdejfefgnecuffhomhgrihhnpehhvgdrnhgvthenucfkphepjeeirddvheefrdejhe drfeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rhhtthesuggrshihrghtihgurggvrdgtohhm X-ME-Proxy: Original-Received: from [192.168.1.65] (76-253-75-34.lightspeed.austtx.sbcglobal.net [76.253.75.34]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A94424005B; Thu, 31 Dec 2020 17:40:03 -0500 (EST) In-Reply-To: <83sg7mggls.fsf@gnu.org> Content-Language: en-US-large Received-SPF: none client-ip=66.111.4.29; envelope-from=rtt@dasyatidae.com; helo=out5-smtp.messagingengine.com X-Spam_score_int: -59 X-Spam_score: -6.0 X-Spam_bar: ------ X-Spam_report: (-6.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-3.399, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:262210 Archived-At: 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