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: > >> On 23.08.2015, at 17:09, Kristof Provost <kp@FreeBSD.org> wrote: >> >> - 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. > > 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. > > I’ve updated the PR with some more thoughts about this. > 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’t expect the fragmentation and reassembly to work at all in that scenario. I’ll see what I can do about at least fixing the panic in the short term. Even if the reassembly/refragmentation doesn’t 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>