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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, NORMAL_HTTP_TO_IP,NUMERIC_HTTP_ADDR,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3032 invoked from network); 1 Jun 2022 20:46:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 1 Jun 2022 20:46:46 -0000 Received: (qmail 24308 invoked by uid 550); 1 Jun 2022 20:46:41 -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 13480 invoked from network); 1 Jun 2022 20:36:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VGBETIY41iP+fVPZXbq/t2F9Q3sIIFa1ZKYLniSo4/Q=; b=pDJnXZ+ykit8BEskV29/QBaZfpeNLiS3WkRZE2JDa48O9xkNffaweVz4xmbqHT84nv /GKT6xjEG0Zx62OnWfIJpK7wSFhauz9IbCrnE/uLUx9U++3/jugVk8j3iZD76Wumt94i Sf5hCp0QvtcmFt7z+KcWcaFPunEHmCGzI6H14nl71tx5tSR6Sc/0l5xrG687m4wDwP6T vwbEOLg6Bixbm3cFrP+v7UhZzCmNWAYG+UUXcXIPnfeJZOms3OU6eD9bHcTcI8sz3hcN 90DD4Scg5xB7PUMDK2QOdManytw05pgOFcj9gXp+Xt5QnooY2qB7YNApUUHQw7moEXSG wJgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VGBETIY41iP+fVPZXbq/t2F9Q3sIIFa1ZKYLniSo4/Q=; b=O3J0br2znPALOrgpLpo6Zdrh9Fo49tzm5C5YUl8wz0r03fE0xw1iQCN2HebND6Rk/+ HPO/MJw+WbK5ID3yGSMx844vIgWqpA2q9G13aJAU9osaVodJzNqEJli7iF0iWCMqsIl0 zExLGHrBPQ++Vsn+k/gXk3yZ4/VcpRxxkwDT3aCZU56xjXa4h6VHVQFdtqs1/cou+KMK fN3TMESUT0TiVzn7V64RgcyXVvJkquC0AeedLte3ECooLVEd0FGoc6reeD5HfUaLEsU3 +a/HVN+bCZnPwavGWGFeUDPMX5b7NDV7dY2IYMvKPSS632zRwBoHk1hvo1nX1u4FzxJv oXjA== X-Gm-Message-State: AOAM530kdBU46kpHJZUGZVJNHKMi0Aqfs7CNgReT9t7frIkVgJrDiHYR jPVQQgTpYqO6ZrJq906hAJ95ScPT1CUy0MSV2n8= X-Google-Smtp-Source: ABdhPJx0Ox/bLgLB3/K5SNvQeMJNSzx9yhT2zwukl2B4zizvH8aildRPSiYQ8z67/z+Qe4p7stIEv9h7zwAe2oKmcEE= X-Received: by 2002:a67:dd19:0:b0:349:dfd1:fd09 with SMTP id y25-20020a67dd19000000b00349dfd1fd09mr816045vsj.69.1654115763145; Wed, 01 Jun 2022 13:36:03 -0700 (PDT) MIME-Version: 1.0 References: <20220601141453.GW7074@brightrain.aerifal.cx> In-Reply-To: <20220601141453.GW7074@brightrain.aerifal.cx> From: Sascha Braun Date: Wed, 1 Jun 2022 22:35:52 +0200 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000007acfc105e068d64b" Subject: Re: [musl] Problably Issue in name_from_dns // __res_msend_rc (lookup_name.c) --0000000000007acfc105e068d64b Content-Type: text/plain; charset="UTF-8" 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. Regards S. 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 > --0000000000007acfc105e068d64b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rich,

Thanks for your time. The=20 EADDRINUSE is in reality an EAGAIN, this is a glitch in the Emscripten/WASI= modification for musl (there are different values for errnos per implement= ation):
__WASI_ERRNO_ADDRINUSE =3D=3D -3 =3D=3D EAI_AGAIN.=

My question currently breaks down t= o: Is it common for this implementation of getaddrinfo to return EAGAIN som= etimes (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 you= r thought is of course very reasonable.

Regards
S.


Am Mi., 1. J= uni 2022 um 16:14=C2=A0Uhr schrieb Rich Felker <dalias@libc.org>:
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 Emscripte= n - 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, &r= es) !=3D 0) {
> perror("getaddrinfo1");
> }
> printf("begin lookup2...\n");
> if (getaddrinfo("www.google.de", "80", &hints, = &res) !=3D 0) {
> perror("getaddrinfo2");
> }
> printf("begin lookup3...\n");
> if (getaddrinfo("www.google.com", "80", &hints= , &res) !=3D 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 non= e is.
>
> Below is a console dump of my test where you see the critical situatio= n
> (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 hi= nts,
> 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
--0000000000007acfc105e068d64b--