NetBSD Problem Report #56799

From martin@aprisoft.de  Thu Apr 21 15:41:59 2022
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4A3A21A921F
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 21 Apr 2022 15:41:59 +0000 (UTC)
Message-Id: <20220421154150.3872C5CC906@emmas.aprisoft.de>
Date: Thu, 21 Apr 2022 17:41:50 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: possible ICMP6 issue
X-Send-Pr-Version: 3.95

>Number:         56799
>Category:       kern
>Synopsis:       possible ICMP6 issue
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 21 15:45:00 +0000 2022
>Originator:     Martin Husemann
>Release:        NetBSD 9.99.96
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD martins.aprisoft.de 9.99.96 NetBSD 9.99.96 (GENERIC) #116: Fri Apr 1 16:13:37 CEST 2022 martin@martins.aprisoft.de:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:

The QEMU project received problem reports when using NetBSD as a guest
that trying to add binariy pkgs from our CDN with certain qemu networking
setups would be very slow.

Here is a ticket: https://gitlab.com/qemu-project/qemu/-/issues/985#note_916327854

and it claims the ICMP6 "destination unreachable" packet would be ignored
by NetBSD. There is another thread here:

https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04704.html and

which includes a pcap dump that clearly shows QEMU thinks it is sending
this packet to the emulated wm(4) interface:

20:01:57.725593 IP6 fe80::2 > fec0::bcc0:a861:b1ae:147: ICMP6, destination unreachable, unreachable route ftp.NetBSD.org, length 88

but apparently the IPv6 TCP connection still times out after one minute and
only then the IPv4 connection is established.

For unrelated reasons I can not easy reproduce the test setup here right
now, so haven't been able to verify it locally.

>How-To-Repeat:

See instructions in the first link.

>Fix:
n/a

Home	PR Database Search