Date: Mon, 24 Aug 2015 18:16:12 +0200 From: Kristof Provost <kp@FreeBSD.org> To: Markus Gebert <markus.gebert@hostpoint.ch> Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Near-term pf plans Message-ID: <1DDBFAD5-9AFB-4A21-8D16-BD85AB30F448@FreeBSD.org> In-Reply-To: <3121D8E4-A27E-475B-9771-C09347D1D793@hostpoint.ch> References: <20150823150957.GK48727@vega.codepro.be> <3121D8E4-A27E-475B-9771-C09347D1D793@hostpoint.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 24 Aug 2015, at 17:33, Markus Gebert <markus.gebert@hostpoint.ch> = wrote: >=20 >> On 23.08.2015, at 17:09, Kristof Provost <kp@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1DDBFAD5-9AFB-4A21-8D16-BD85AB30F448>