From patchwork Thu Jun 28 15:50:50 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kristof Provost X-Patchwork-Id: 167918 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 41B9BB7001 for ; Fri, 29 Jun 2012 02:00:50 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751808Ab2F1QAs (ORCPT ); Thu, 28 Jun 2012 12:00:48 -0400 Received: from mercury.codepro.be ([95.142.164.132]:59147 "EHLO mercury.codepro.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751293Ab2F1QAs (ORCPT ); Thu, 28 Jun 2012 12:00:48 -0400 X-Greylist: delayed 566 seconds by postgrey-1.27 at vger.kernel.org; Thu, 28 Jun 2012 12:00:47 EDT Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id D4EF211F for ; Thu, 28 Jun 2012 17:51:20 +0200 (CEST) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id 9EA6499DD for ; Thu, 28 Jun 2012 17:50:50 +0200 (CEST) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id 864F04A45C; Thu, 28 Jun 2012 17:50:50 +0200 (CEST) Date: Thu, 28 Jun 2012 17:50:50 +0200 From: Kristof Provost To: netfilter-devel@vger.kernel.org Subject: IPv6 fragment packet handling Message-ID: <20120628155050.GK9423@thebe.jupiter.sigsegv.be> MIME-Version: 1.0 Content-Disposition: inline X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org I've noticed an annoying difference between IPv4 and IPv6 regarding fragmented packet handling. The IPv4 netfilter code defragments packets before the hit the filter table, but the IPv6 code does not. As a result the following means that the host won't receive fragmented ICMPv6 echo packets (for example ping6 -s 3000 ): ip6tables -F INPUT ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT ip6tables -P INPUT DROP The first fragment makes it through (hitting the icmpv6 rule), but subsequent fragments are dropped. In the IPv4 case the packet does make it through. 'iptables -L INPUT -vn' then shows that the ICMP rule hit one packet for about 3000 bytes. Am I missing something obvious? Is there a reason for this difference? The following proof-of-concept patch changes the IPv6 behavior to match that of IPv4: Regards, Kristof --- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c index c9c78c2..5bb44eb 100644 --- a/net/ipv6/netfilter/nf_conntrack_reasm.c +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c @@ -593,6 +593,11 @@ void nf_ct_frag6_output(unsigned int hooknum, struct sk_buff *skb, { struct sk_buff *s, *s2; + nf_conntrack_get_reasm(skb); + + NF_HOOK_THRESH(NFPROTO_IPV6, hooknum, skb, in, out, okfn, + NF_IP6_PRI_CONNTRACK_DEFRAG + 1); + for (s = NFCT_FRAG6_CB(skb)->orig; s;) { nf_conntrack_put_reasm(s->nfct_reasm); nf_conntrack_get_reasm(skb); @@ -601,8 +606,8 @@ void nf_ct_frag6_output(unsigned int hooknum, struct sk_buff *skb, s2 = s->next; s->next = NULL; - NF_HOOK_THRESH(NFPROTO_IPV6, hooknum, s, in, out, okfn, - NF_IP6_PRI_CONNTRACK_DEFRAG + 1); + nf_conntrack_put_reasm(s); + s = s2; } nf_conntrack_put_reasm(skb);