From owner-freebsd-net@freebsd.org Sun Sep 23 21:50:09 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB892109AA2D for ; Sun, 23 Sep 2018 21:50:09 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F69884688; Sun, 23 Sep 2018 21:50:09 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 00CAB1BAAA; Sun, 23 Sep 2018 21:50:08 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Sun, 23 Sep 2018 14:50:06 -0700 (PDT) From: Don Lewis Subject: Re: IPv6 fragment reassembly regression following FreeBSD-SA-18:10.ip To: "John W. O'Brien" cc: FreeBSD Net In-Reply-To: <38a2d322-eae9-ec3d-284c-af29aed10c03@saltant.com> Message-ID: References: <38a2d322-eae9-ec3d-284c-af29aed10c03@saltant.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 21:50:09 -0000 On 23 Sep, John W. O'Brien wrote: > I'd like to check my understanding and then ask a procedural question. > > FreeBSD-SA-18:10.ip [0], released on 08/14, was resolved by r337828 [1]. > That changeset, resulting in 11.1R-p13 and 11.2R-p2, included a patch to > the way IPv6 fragment reassembly is handled [2] that was part of the > merge to releng. In an ensuing thread [3] two weeks later, an > implementation defect was identified, but not before that defect had > shipped. The defect is now being tracked as a bug [4], as of 09/03 has > been fixed in head and stable/11, and is registered as a blocker for 12.0. > > I believe this defect is the cause of a problem I detected recently > where postfix would query BIND on ::1 for the DNSSEC-signed AAAA of an > MX, and never receive a response. I'm a little puzzled that lo0 is > affected in spite of having a 16k MTU, but the other signs are there: > the symptoms appeared after upgrading from 11.2R-p1 to -p3, and I can > perform that query successfully on UDPv4 or TCPv6. > > What I have been unable so far to determine is, will another 11.2R patch > be forthcoming to resolve this regression, and if so, when? I can limp > along without UDPv6 for a little while, but not until 11.3. The only > clear alternative is to downgrade to -p1. > > [0] https://www.freebsd.org/security/advisories/FreeBSD-SA-18:10.ip.asc > [1] https://svnweb.freebsd.org/changeset/base/337828 > [2] https://svnweb.freebsd.org/changeset/base/337776 > [3] https://lists.freebsd.org/pipermail/svn-src-head/2018-August/117514.html > [4] https://bugs.freebsd.org/231045 > It looks to me like r337776 is a further performance improvement, only present in head, which also introduced a new bug that was fixed by r338406. I don't know why r338406 was merged to stable/11 since r337776 was not. Stable/11 only has the original fix (r337787 in head, r337803 in stable/11).