netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: Shan Wei <shanwei@cn.fujitsu.com>,
	Pascal Hambourg <pascal.mail@plouf.fr.eu.org>,
	YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
	David Miller <davem@davemloft.net>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	netfilter-devel@vger.kernel.org
Subject: Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
Date: Thu, 25 Mar 2010 11:20:20 +0100	[thread overview]
Message-ID: <4BAB38E4.7050706@trash.net> (raw)
In-Reply-To: <alpine.DEB.2.00.1003251028580.21825@blackhole.kfki.hu>

[-- Attachment #1: Type: text/plain, Size: 719 bytes --]

Jozsef Kadlecsik wrote:
> Why the order of the raw table and defragmentation is reversed for IPv6?
> 
> That makes impossible to use the NOTRACK target in IPv6: for example if 
> someone enters
> 
> ip6tables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
> 
> and if we receive fragmented packets then the first fragment will be 
> untracked and thus skip nf_ct_frag6_gather (and conntrack), while all 
> subsequent fragments enter nf_ct_frag6_gather and reassembly will never 
> successfully be finished.
> 
> IMHO this is a bug and should be fixed. Patrick, please consider applying 
> the patch below.

Indeed. I've applied your patch with a minor fixup (attached) to
apply cleanly to the current tree, thanks.


[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1657 bytes --]

commit 9c13886665c43600bd0af4b38e33c654e648e078
Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date:   Thu Mar 25 11:17:26 2010 +0100

    netfilter: ip6table_raw: fix table priority
    
    The order of the IPv6 raw table is currently reversed, that makes impossible
    to use the NOTRACK target in IPv6: for example if someone enters
    
    ip6tables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK
    
    and if we receive fragmented packets then the first fragment will be
    untracked and thus skip nf_ct_frag6_gather (and conntrack), while all
    subsequent fragments enter nf_ct_frag6_gather and reassembly will never
    successfully be finished.
    
    Singed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/include/linux/netfilter_ipv6.h b/include/linux/netfilter_ipv6.h
index d654873..1f7e300 100644
--- a/include/linux/netfilter_ipv6.h
+++ b/include/linux/netfilter_ipv6.h
@@ -59,6 +59,7 @@
 enum nf_ip6_hook_priorities {
 	NF_IP6_PRI_FIRST = INT_MIN,
 	NF_IP6_PRI_CONNTRACK_DEFRAG = -400,
+	NF_IP6_PRI_RAW = -300,
 	NF_IP6_PRI_SELINUX_FIRST = -225,
 	NF_IP6_PRI_CONNTRACK = -200,
 	NF_IP6_PRI_MANGLE = -150,
diff --git a/net/ipv6/netfilter/ip6table_raw.c b/net/ipv6/netfilter/ip6table_raw.c
index aef31a2..b9cf7cd 100644
--- a/net/ipv6/netfilter/ip6table_raw.c
+++ b/net/ipv6/netfilter/ip6table_raw.c
@@ -13,7 +13,7 @@ static const struct xt_table packet_raw = {
 	.valid_hooks = RAW_VALID_HOOKS,
 	.me = THIS_MODULE,
 	.af = NFPROTO_IPV6,
-	.priority = NF_IP6_PRI_FIRST,
+	.priority = NF_IP6_PRI_RAW,
 };
 
 /* The work comes in here from netfilter.c. */

  reply	other threads:[~2010-03-25 10:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-27  6:39 [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment Shan Wei
2010-03-10 17:13 ` YOSHIFUJI Hideaki
2010-03-11  9:16   ` Shan Wei
2010-03-13 13:47     ` YOSHIFUJI Hideaki
2010-03-15 16:27       ` Patrick McHardy
2010-03-23 16:28         ` YOSHIFUJI Hideaki
2010-03-23 17:16           ` Patrick McHardy
2010-03-23 18:58             ` YOSHIFUJI Hideaki
2010-03-23 20:10               ` Jozsef Kadlecsik
2010-03-25  4:20                 ` YOSHIFUJI Hideaki
2010-03-25  9:23                   ` Jozsef Kadlecsik
2010-03-25 14:14                     ` YOSHIFUJI Hideaki
2010-03-25 10:25                   ` Patrick McHardy
2010-03-25  8:38                 ` Pascal Hambourg
2010-03-25  9:13                   ` Shan Wei
2010-03-25 10:07                     ` Jozsef Kadlecsik
2010-03-25 10:20                       ` Patrick McHardy [this message]
2010-03-25  2:22               ` Shan Wei
2010-03-23 15:05     ` Patrick McHardy
2010-03-25  2:28       ` Shan Wei
2010-03-25  4:19         ` YOSHIFUJI Hideaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BAB38E4.7050706@trash.net \
    --to=kaber@trash.net \
    --cc=adobriyan@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pascal.mail@plouf.fr.eu.org \
    --cc=shanwei@cn.fujitsu.com \
    --cc=yasuyuki.kozakai@toshiba.co.jp \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).