From owner-freebsd-net@freebsd.org Mon Sep 24 20:54:04 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 99FE5109183C for ; Mon, 24 Sep 2018 20:54:04 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 5021672888; Mon, 24 Sep 2018 20:54:04 +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 D7F3524755; Mon, 24 Sep 2018 20:54:03 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Mon, 24 Sep 2018 13:54:02 -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: <139c4032-b021-010d-a55d-7203e791ed15@saltant.com> Message-ID: References: <38a2d322-eae9-ec3d-284c-af29aed10c03@saltant.com> <139c4032-b021-010d-a55d-7203e791ed15@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: Mon, 24 Sep 2018 20:54:04 -0000 On 24 Sep, John W. O'Brien wrote: > On 9/23/18 17:50, Don Lewis wrote: >> 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). > > Hi Don, > > I'm looking at this line of code [5] in releng/11.2. It looks to me like > that's what r338406 fixed in head [6]. Am I being obtuse here? > > [5] > https://svnweb.freebsd.org/base/releng/11.2/sys/netinet6/frag6.c?annotate=337828#l219 > [6] > https://svnweb.freebsd.org/base/head/sys/netinet6/frag6.c?r1=338406&r2=338405&pathrev=338406 > The change history here was complicated enough to confuse me. I think you are correct that r338406 should be merged to 11.1 and 11.2 and new patches released.