From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9159 invoked from network); 1 Jun 2022 21:30:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Jun 2022 21:30:38 -0000 Received: (qmail 32256 invoked by uid 550); 1 Jun 2022 21:30:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 32221 invoked from network); 1 Jun 2022 21:30:34 -0000 Date: Wed, 1 Jun 2022 17:30:22 -0400 From: Rich Felker To: Sascha Braun Cc: musl@lists.openwall.com Message-ID: <20220601213022.GX7074@brightrain.aerifal.cx> References: <20220601141453.GW7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Problably Issue in name_from_dns // __res_msend_rc (lookup_name.c) On Wed, Jun 01, 2022 at 10:35:52PM +0200, Sascha Braun wrote: > Hi Rich, > > Thanks for your time. The EADDRINUSE is in reality an EAGAIN, this is a > glitch in the Emscripten/WASI modification for musl (there are different > values for errnos per implementation): > __WASI_ERRNO_ADDRINUSE == -3 == EAI_AGAIN. > > My question currently breaks down to: Is it common for this implementation > of getaddrinfo to return EAGAIN sometimes (I experience 1:100), even if > answers from DNS servers came in? > If not, I need to investigate much further. I really could not find issues > with my sockets implementation, although your thought is of course very > reasonable. OK, looking at your code again, part of your problem is that you're misusing perror. You need to save the return value of getaddrinfo. Unless it's EAI_SYSTEM, errno is meaningless and you need to use gai_strerror to get a string for the error code (the value that was returned) rather than inspecting errno. If getaddrinfo actually returned EAI_AGAIN, this probably means you got an inconclusive result from one of the nameservers, probably ServFail. However if your debug output is packet dumps, I'm not seeing a ServFail there, and I'm not convinced it actually returned EAI_AGAIN since you're not saving the value to check it. The value that happens to be in errno is NOT the error getaddrinfo returned. Can you check what it's actually returning? > Am Mi., 1. Juni 2022 um 16:14 Uhr schrieb Rich Felker : > > > On Tue, May 31, 2022 at 12:24:19PM +0200, Sascha Braun wrote: > > > Hi everyone, > > > > > > I'm implementing a socket protocol with similar works to Emscripten - ok: > > > > > > Here's what I noticed > > > > > > - resolv.conf using multiple DNS servers > > > options timeout:22 attempts:5 > > > nameserver 8.8.4.4 > > > nameserver 208.67.222.222 > > > nameserver 9.9.9.9 > > > nameserver 1.1.1.1 > > > > > > - getaddrinfo with no hints, so that IPV6 and IPV4 is resolved > > > void socketstest1_client_dnsonly(void) { > > > > > > struct addrinfo hints, * res; > > > memset(&hints, 0, sizeof(hints)); > > > printf("begin lookup1...\n"); > > > if (getaddrinfo("www.web.de", "80", &hints, &res) != 0) { > > > perror("getaddrinfo1"); > > > } > > > printf("begin lookup2...\n"); > > > if (getaddrinfo("www.google.de", "80", &hints, &res) != 0) { > > > perror("getaddrinfo2"); > > > } > > > printf("begin lookup3...\n"); > > > if (getaddrinfo("www.google.com", "80", &hints, &res) != 0) { > > > perror("getaddrinfo3"); > > > } > > > > > > } > > > > > > When repeating socketstest1_client_dnsonly often, it appears that IPV6 > > > answers for IPV4 requests to another server [or vice-versa] responses can > > > get mixed up and getaddrinfo reports sometimes only an error where none > > is. > > > > > > Below is a console dump of my test where you see the critical situation > > > (end) > > > 8.8.4.4:53 was queried, 9.9.9.9:53 responded for a (different IP Proto), > > > resulting in error getaddrinfo1: Address in use > > > > > > This happens in about 1/100 tests. When you specify IPV4 or IPV6 in > > hints, > > > this issue does NOT show up. > > > > Can you provide more information on how to interpret the console dump, > > and in particular, which of your syscalls is returning the EADDRINUSE > > error? I'm pretty sure this is just a bug in your socket > > stack/emulation. It looks like it's coming from recvfrom, and > > EADDRINUSE is not a valid error for recvfrom to produce. > > > > Rich > >