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 19467 invoked from network); 1 Jun 2022 14:15:19 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 1 Jun 2022 14:15:19 -0000
Received: (qmail 4017 invoked by uid 550); 1 Jun 2022 14:15:06 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 3985 invoked from network); 1 Jun 2022 14:15:06 -0000
Date: Wed, 1 Jun 2022 10:14:53 -0400
From: Rich Felker <dalias@libc.org>
To: Sascha Braun <sascha.braun.lpz@googlemail.com>
Cc: musl@lists.openwall.com
Message-ID: <20220601141453.GW7074@brightrain.aerifal.cx>
References: <CALATqHnJosLVd71_heHmiKqctO5y=GYC+Nf9_gh-hoLk0nQEeQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALATqHnJosLVd71_heHmiKqctO5y=GYC+Nf9_gh-hoLk0nQEeQ@mail.gmail.com>
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 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