From owner-freebsd-net@freebsd.org Mon Nov 6 14:53:20 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5AE3AE5FE53 for ; Mon, 6 Nov 2017 14:53:20 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 169C572086 for ; Mon, 6 Nov 2017 14:53:19 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id BA0487A330D for ; Mon, 6 Nov 2017 14:53:17 +0000 (UTC) (envelope-from freebsd@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: FreeBSD 11.1-RELEASE: Kernel panic in ipv6_output() via tcp6_usr_connect() From: Viktor Dukhovni In-Reply-To: Date: Mon, 6 Nov 2017 09:53:09 -0500 Content-Transfer-Encoding: 7bit Reply-To: freebsd-net@freebsd.org Message-Id: <39EFBDF9-B313-4472-85CF-D2D5D508E991@dukhovni.org> References: <86dcc06d-b98c-cc1f-8726-8afb011871e3@yandex.ru> <94e12e46-f54a-ae22-3f4c-0bd9ac7e1fc9@yandex.ru> <20171106044000.GM3322@mournblade.imrryr.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Nov 2017 14:53:20 -0000 > On Nov 6, 2017, at 6:28 AM, Andrey V. Elsukov wrote: > >> Reverting the rule on a running system back to "ip", still yields >> no panics, but I am now running a different 11.1 kernel built from >> SVN with my "stf" patch. So it is sadly not quite clear where the >> problem was, my original configuration, the older kernel, something >> else? > > I think it is the right assumption, that IPv6 packet got corrupted by > nat44 and then ip6_output() is confused by incorrect packet, especially > wrong packet length may lead to fragmentation and due to the discrepancy > between ip6_plen and m_pkthdr.len ip6_fragment() creates wrong fragments > chain. > > I think the following patch should be enough to fix the problem: > > Index: sys/netpfil/ipfw/ip_fw2.c > =================================================================== > --- sys/netpfil/ipfw/ip_fw2.c (revision 325354) > +++ sys/netpfil/ipfw/ip_fw2.c (working copy) > @@ -2563,7 +2563,7 @@ do { \ > case O_NAT: > l = 0; /* exit inner loop */ > done = 1; /* exit outer loop */ > - if (!IPFW_NAT_LOADED) { > + if (!is_ipv4 || !IPFW_NAT_LOADED) { > retval = IP_FW_DENY; > break; > } > > Would this cause the packet to be denied, or passed through without nat? Presumably, I would then have to have "ip4" and not "ip" as "ip6" would then be denied by the "nat" rule. Right? Any comments on my message (and patch) with subject: [Patch] The 6to4 stf0 interface flapping in/out of tentative in FreeBSD 11 How do I get this addressed by the maintainer of stf? -- Viktor.