Date: Sun, 23 Sep 2018 14:50:06 -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.a34a5d42cdde2a65@FreeBSD.org> In-Reply-To: <38a2d322-eae9-ec3d-284c-af29aed10c03@saltant.com> References: <38a2d322-eae9-ec3d-284c-af29aed10c03@saltant.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?tkrat.a34a5d42cdde2a65>