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, broader call for reproducibility check Date: Mon, 11 Jan 2021 11:07:33 -0600 Message-ID: References: <83sg7mggls.fsf@gnu.org> <83czymc8nq.fsf@gnu.org> <74b7a0a9-0eb3-7944-19d2-f72424ee72d7@dasyatidae.com> <83eeirfqbo.fsf@gnu.org> <87o8hvscfi.fsf@gmail.com> <8335z7fmnz.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="9030"; 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: Robert Pluim , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 11 18:13: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 1kz0lT-0002Ew-32 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 18:13:59 +0100 Original-Received: from localhost ([::1]:49644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kz0lS-00073k-45 for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 12:13:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49230) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz0fF-00086S-0x for emacs-devel@gnu.org; Mon, 11 Jan 2021 12:07:33 -0500 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37513) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz0fC-0005c8-TD; Mon, 11 Jan 2021 12:07:32 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A25315C01D5; Mon, 11 Jan 2021 12:07:29 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 11 Jan 2021 12:07:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dasyatidae.com; h=to:cc:references:from:subject:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=h 6UG+JeDYEwASinBvO7fC2O4cwRIVDtEeyfJW4Vchmw=; b=L0BgBcRyXZ95OzKFD jjKT9Zz/vYo3jGN9I1xE6sfMAyU6oD2NdibtAAcdVsaOAMFy3yMle7e00WSNMs1r EzJjcCR2vpXj2ZEFSp0hN9bkXVytPpEFGQgW6Aeg3vM4vjokEik+BxXziH/nFTyc b90+vUnlZEd8w5J0CceJwTgRIVBbknWJ+qOaKm2yk8SysJDLukV56y6V/yDLVhxu bXpGwCKaEzH+L7N8UmSCKRy5Abc4WNlECUiE7GP9WKOybNXSfJU6WzeZ5TnwJtLA xgNp2+iLQSdTqG6eeag1736L45EKqKasjDtFU5p6ILBjqlAkR3j9vLo97LQxRnHe /jRnw== 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=h6UG+JeDYEwASinBvO7fC2O4cwRIVDtEeyfJW4Vch mw=; b=fEo3Atxyr8aLu95R0bdbJcS3aUoybSh9w2FkShyODgP0rz19nyg4EVLSg BOzhGE9XRLqlZCf7RAwMFFCdRI+TxO5H++vJDXRtc7JUKhi3tEONch/Ua9FJ8iij cjSj2HIL6bNwQgssUgYC0L9Re3t+7YJ4dO4IkiT25jqPMsUl3NvP0ceBr0XDCP5d lcexENqPGrQ2wRDU2mt5nShKISpkXAL0xD+HGpmBbDEO9enEpl7Gt6hrQyLB1lSK 1dsC2o5CzedwU/BQxayEla/Iafyt8awf+xCPN7XM559tPBm5Eorx4M9FYypGBC3X 6L6VEBPKWhIcSyiSzN9kx6CKYmvVQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehuddgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepvfhfhffukffffgggjggtgfesthekredttdefjeenucfhrhhomheptfhosghi nhcuvfgrrhhsihhgvghruceorhhtthesuggrshihrghtihgurggvrdgtohhmqeenucggtf frrghtthgvrhhnpedvudfggeffieegkeeuueefvdekffekheevvddtgeevledthefhkeef fefgkefgkeenucfkphepjeeirddvheefrdejhedrfeegnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprhhtthesuggrshihrghtihgurggvrdgt ohhm 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 2BAFC24005A; Mon, 11 Jan 2021 12:07:29 -0500 (EST) In-Reply-To: <8335z7fmnz.fsf@gnu.org> Content-Language: en-US-large Received-SPF: pass client-ip=66.111.4.27; envelope-from=rtt@dasyatidae.com; helo=out3-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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:262922 Archived-At: Eli Zaretskii wrote: > Is it possible to check this via network-interface-list, and avoid the > test with IPv6 if that is bound to fail? The relevant part of the tests should, generally, be about DNS _lookups_ of IPv6 addresses. This is not "truly" related to whether your local host has IPv6 connectivity at the network layer. I have no IPv6 routing at home currently, but getaddrinfo will still give me all the IPv6 results I want; I just won't be able to connect there. I expect that case to be common. The opposite case, where I could have IPv6 networking available but have restrictive upstream DNS resolvers blocking queries for or results containing IPv6 addresses, is also theoretically possible, though I would expect it to be rare. So basically you'd be testing the wrong thing. You could try to err on the side of caution, but then you'd be excluding the test in a lot of cases that really should work. If your upstream resolvers default to mangling or blocking AAAA queries, as my current best hypothesis suggests, this is not something an application can reasonably take responsibility for fixing up, and we'd want to go the route of "skip network-environment-dependent tests when on hosts that are in strange/broken network environments". I don't know whether there's an existing toggle for that; if not, then that would be the thing to put in (at whatever granularity seems appropriate). There is no _reliable_ way I know of to determine this programmatically, certainly not without sending some probe queries with a high level of specific control over them, and I expect that would be a rather hairy thing to do just for a few tests, and not reasonably maintainable. Another perspective on above is that when you mention "behind firewalls up the kazoo", what my intuition imagines is something like: corporate DNS filtering which only allows specific request types and either was never updated to think of AAAA queries as valid, or is operated in a way assuming that users will never have a legitimate need for them (because they "won't be able to use" the results), or does this as a workaround for some broken behavior elsewhere (such as some other device used in the organization which will prefer an IPv6 address response even when it's not reachable, and fail to fall back to IPv4?) or... any number of things like that. The main thing that hypothesis doesn't explain is the discrepancy in the any-family results, but that could easily be by accident depending on how the specifics of the filtering interact with the specifics of the pattern of queries Windows generates under those circumstances, which is why I was originally thinking of finding out the latter; or it could be some local filtering that Windows does depending on local connectivity for similar reasons to the above, which is why I wanted to see whether those flags made any difference for Windows machines on more "conventional" networks. -RTT