From owner-svn-src-head@FreeBSD.ORG Tue Apr 7 06:33:21 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D590873C; Tue, 7 Apr 2015 06:33:21 +0000 (UTC) Received: from testsoekris.hotsoft.nl (unknown [IPv6:2001:888:1227:0:200:24ff:fec9:5934]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88E4E8C4; Tue, 7 Apr 2015 06:33:21 +0000 (UTC) Received: from beastie.hotsoft.nl (beastie.hotsoft.nl [IPv6:2001:888:1227:0:219:d1ff:fee8:91eb]) by testsoekris.hotsoft.nl (8.14.7/8.14.7) with ESMTP id t376XHFE047586; Tue, 7 Apr 2015 08:33:17 +0200 (CEST) (envelope-from hans@beastielabs.net) Message-ID: <55237A2D.2000602@beastielabs.net> Date: Tue, 07 Apr 2015 08:33:17 +0200 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kristof Provost , svn-src-head@freebsd.org Subject: Re: svn commit: r281164 - head/sys/netpfil/pf References: <201504061905.t36J51EX005483@svn.freebsd.org> In-Reply-To: <201504061905.t36J51EX005483@svn.freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 06:33:22 -0000 On 04/06/15 21:05, Kristof Provost wrote: > Author: kp > Date: Mon Apr 6 19:05:00 2015 > New Revision: 281164 > URL: https://svnweb.freebsd.org/changeset/base/281164 > > Log: > pf: Skip firewall for refragmented ip6 packets > > In cases where we scrub (fragment reassemble) on both input and output > we risk ending up in infinite loops when forwarding packets. > > Fragmented packets come in and get collected until we can defragment. At > that point the defragmented packet is handed back to the ip stack (at > the pfil point in ip6_input(). Normal processing continues. > > Eventually we figure out that the packet has to be forwarded and we end > up at the pfil hook in ip6_forward(). After doing the inspection on the > defragmented packet we see that the packet has been defragmented and > because we're forwarding we have to refragment it. > > In pf_refragment6() we split the packet up again and then ip6_forward() > the individual fragments. Those fragments hit the pfil hook on the way > out, so they're collected until we can reconstruct the full packet, at > which point we're right back where we left off and things continue until > we run out of stack. > > Break that loop by marking the fragments generated by pf_refragment6() > as M_SKIP_FIREWALL. There's no point in processing those packets in the > firewall anyway. We've already filtered on the full packet. > > Differential Revision: https://reviews.freebsd.org/D2197 > Reviewed by: glebius, gnn > Approved by: gnn (mentor) > > Modified: > head/sys/netpfil/pf/pf_norm.c > > Modified: head/sys/netpfil/pf/pf_norm.c > ============================================================================== > --- head/sys/netpfil/pf/pf_norm.c Mon Apr 6 18:56:02 2015 (r281163) > +++ head/sys/netpfil/pf/pf_norm.c Mon Apr 6 19:05:00 2015 (r281164) > @@ -1152,6 +1152,7 @@ pf_refragment6(struct ifnet *ifp, struct > for (t = m; m; m = t) { > t = m->m_nextpkt; > m->m_nextpkt = NULL; > + m->m_flags |= M_SKIP_FIREWALL; > memset(&pd, 0, sizeof(pd)); > pd.pf_mtag = pf_find_mtag(m); > if (error == 0) > _______________________________________________ > svn-src-all@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-all > To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" > Hi, Is there any chance that this commit and your previous pf and inet6 related changes will get MFC'd to 10.1-STABLE. Is it safe or even possible to incorporate these changes myself? Kind regards, Hans