Date: Mon, 24 Sep 2018 13:54:02 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: "John W. O'Brien" <john@saltant.com> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: IPv6 fragment reassembly regression following FreeBSD-SA-18:10.ip Message-ID: <tkrat.d83417e672d6ce60@FreeBSD.org> In-Reply-To: <139c4032-b021-010d-a55d-7203e791ed15@saltant.com> References: <38a2d322-eae9-ec3d-284c-af29aed10c03@saltant.com> <tkrat.a34a5d42cdde2a65@FreeBSD.org> <139c4032-b021-010d-a55d-7203e791ed15@saltant.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?tkrat.d83417e672d6ce60>