From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 3D0402B477 for ; Sun, 18 Feb 2024 13:10:59 +0100 (CET) Received: (qmail 29983 invoked by uid 550); 18 Feb 2024 12:07:44 -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 17431 invoked from network); 18 Feb 2024 07:49:24 -0000 x-libjamoibt: 1601 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libero.it; s=s2021; t=1708242745; bh=iZx4j+DVl0Wj5zLn9i9nhkFpyT2GTD/VeQcG7iaGZBY=; h=From; b=GUmTpsc1MZz0mUbKiWDxhHCG1vVvM/NluhrgDdCjKd2tRskMxzlvxD3gpJJlGPTQu qMPexqPJYkiBmxQYrabbeFurM7pXvsbzklAMMiWgREPdKO4e7ghkjaVpKccai8g2sB JZVuGUp2KtwTDFQE6JCRVjejZvvIpsg3YsQsEmHN/TNVUkR0SNCAVmTZrCV7PHmNJi g2MJDjfQ8l61CJvVENvTkyDT2vOdAerrfWibtZ4kMtTM6llQ7Hq6G1vJimrNkQXsAp hh4tht7ai2MJBZAotc3su9t0O9yJXzREXNbbB6THG454rIhGc/dxEqya6vS8vseroT EfI4vRDbM+7JQ== X-CNFS-Analysis: v=2.4 cv=SqQz6+O0 c=1 sm=1 tr=0 ts=65d1b739 cx=a_exe a=ysqyREb6S0hakrSWcZdePw==:117 a=ysqyREb6S0hakrSWcZdePw==:17 a=kj9zAlcOel0A:10 a=A1X0JdhQAAAA:8 a=apPdu9B6BZBwITzi1GUA:9 a=CjuIK1q_8ugA:10 a=Df3jFdWbhGDLdZNm0fyq:22 Date: Sun, 18 Feb 2024 08:51:29 +0100 From: g1pi@libero.it To: musl@lists.openwall.com Cc: g1pi@libero.it Message-ID: References: <20240217184534.GI4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240217184534.GI4163@brightrain.aerifal.cx> X-CMAE-Envelope: MS4xfEG5K5Vyu8dU7JAS/dk+JOc5gXpi93ouCGcvN+s5xlW995aOZ4R7WFkm6jUL0xtANYxHDfKnyL+3jxhEVH1PbjdektrMiFRwexQ8sgCuhC3u0xNvhPk/ HxtIuV3lsqtBl2umy30qCJwUu2scljxfYvQUi6tO4XzRreOJsIy2RwOY0mdv3qFDqmN/cd711uZq+Hz93Fd6JG+vbnz3sEtppow= Subject: Re: [musl] dns resolution failure in virtio-net guest On Sat, Feb 17, 2024 at 01:45:34PM -0500, Rich Felker wrote: > [...] > > UDP is "allowed" to drop packets any time for any reason, but that > doesn't mean it's okay to do so in the absence of a good reason, or > that musl should work around bugs where that happens, especially when > they're not a fundamental part of Linux but a particular > virtualization configuration. I expected the network to drop a UDP packet anywhere, just not at the boundary between kernel-space and user-space: it's gratuitously rude. I agree a workaround is not worth the effort, although I suspect such a configuration to be more common than not. > > I suggest you run tcpdump on the host and watch what's happening, and > I suspect you'll find this is qemu's virtio network being... qemu. It > probably does not do any real NAT, but directly rewrites source and > destination addresses so that your local caching DNS sees *two > identical queries* (same source/dest host/port combination, same query > id) and treats the second as a duplicated packet and ignores it. Or it > may be something different, but at least inspecting the actual network > traffic coming out of the qemu process will tell you what's going on. > On the host side all is fine: the cache log shows that it receives the request and replies correctly, and tcpdump agrees. I had already checked that. But tcpdump on the guest side surprised me: Good case -- 16 msec delay before second sendto() 7:32:44.332 IP 10.0.2.15.43276 > 10.0.2.2.53: 33452+ A? example.com. (29) 7:32:44.333 IP 10.0.2.2.53 > 10.0.2.15.43276: 33452 1/0/0 A 93.184.216.34 (45) 7:32:44.349 IP 10.0.2.15.43276 > 192.168.1.123.53: 33452+ A? example.com. (29) Bad case -- rushing the sendto()s 7:32:55.358 IP 10.0.2.15.46537 > 10.0.2.2.53: 33452+ A? example.com. (29) 7:32:55.358 IP 10.0.2.15.46537 > 192.168.1.123.53: 33452+ A? example.com. (29) 7:32:55.358 IP *127.0.0.1*.53 > 10.0.2.15.46537: 33452 1/0/0 A 93.184.216.34 (45) The response packet does arrive, but has wrong src host. Same behaviour in linux and bsd guests. I believe you guessed correctly that this is a bug in qemu, just more interesting than I initially thought. Most likely it's in the virtio-net driver, which was ported also to the BSDs. Any suggestion about how to report it? g.b.