From owner-freebsd-pf@freebsd.org Mon Aug 24 16:16:15 2015 Return-Path: Delivered-To: freebsd-pf@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 E6A189C1DE0; Mon, 24 Aug 2015 16:16:15 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C8FCCFA; Mon, 24 Aug 2015 16:16:15 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [IPv6:2a02:1811:2419:4e02:6d:6d9f:9966:b7fe] (unknown [IPv6:2a02:1811:2419:4e02:6d:6d9f:9966:b7fe]) by venus.codepro.be (Postfix) with ESMTPSA id 628EBB5A9; Mon, 24 Aug 2015 18:16:12 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3083\)) Subject: Re: Near-term pf plans From: Kristof Provost X-Mailer: Apple Mail (2.3083) In-Reply-To: <3121D8E4-A27E-475B-9771-C09347D1D793@hostpoint.ch> Date: Mon, 24 Aug 2015 18:16:12 +0200 Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1DDBFAD5-9AFB-4A21-8D16-BD85AB30F448@FreeBSD.org> References: <20150823150957.GK48727@vega.codepro.be> <3121D8E4-A27E-475B-9771-C09347D1D793@hostpoint.ch> To: Markus Gebert X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 16:16:16 -0000 > On 24 Aug 2015, at 17:33, Markus Gebert = wrote: >=20 >> On 23.08.2015, at 17:09, Kristof Provost wrote: >>=20 >> - PR 202351 >> This is a panic after ip6 reassembly in pf. We set the rcvif to NULL >> when refragmenting. That seems to go OK execpt when we're = refragmenting >> broadcast/multicast packets in the forwarding path. It's not at all >> clear to me how that could happen. >=20 > if_bridge wants to forward ipv6 multicasts. pf refragmentation code = tries to send out the resulting packets using ip6_forward() which does = not handle multicasts, drops the packet and tries to log that fact, = which causes the panic. >=20 > I=E2=80=99ve updated the PR with some more thoughts about this. >=20 Yes, I saw that pass by earlier. Thanks for that, I think you did a = great analysis. Unfortunately there are other issues with pf on bridges. (See PR 185633 = for example) I wouldn=E2=80=99t expect the fragmentation and reassembly to work at = all in that scenario. I=E2=80=99ll see what I can do about at least fixing the panic in the = short term. Even if the reassembly/refragmentation doesn=E2=80=99t work (on bridges) = we should at least no panic. Regards, Kristof