All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Florian Westphal <fw@strlen.de>,
	netdev@vger.kernel.org, davem@davemloft.net, pablo@netfilter.org,
	netfilter-devel@vger.kernel.org, yoshfuji@linux-ipv6.org,
	kadlec@blackhole.kfki.hu, mleitner@redhat.com,
	kuznet@ms2.inr.ac.ru, jmorris@namei.org, wensong@linux-vs.org,
	horms@verge.net.au, ja@ssi.bg, edumazet@google.com,
	pshelar@nicira.com, jasowang@redhat.com,
	alexander.h.duyck@intel.com, coreteam@netfilter.org
Subject: Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
Date: Tue, 5 Nov 2013 22:02:23 +0000	[thread overview]
Message-ID: <20131105220222.GA9115@macbook.localnet> (raw)
In-Reply-To: <20131105205520.GD2438@minipsycho.orion>

On Tue, Nov 05, 2013 at 09:55:20PM +0100, Jiri Pirko wrote:
> Tue, Nov 05, 2013 at 07:16:33PM CET, kaber@trash.net wrote:
>
> >> I'm a bit lost. What "nfct_frag" are you reffering to here?
> >
> >I meant nfct_reasm of course.
> 
> The patch is not moving this to struct sk_buff. It is already there.

Right again, sorry, I was replying to Florian's mail without the
quoted patch, so I seem to have mixed up things in between :)

> >> >So if someone wants to change this, simply *only* pass the reassembled
> >> >packet through the netfilter hooks and drop the fragments, as in IPv4.
> >> 
> >> This is unfortunatelly not possible because in forwarding use case, the
> >> fragments have to be send out as they come in.
> >
> >No, the IPv6 NAT patches fixed that, we still do proper refragmentation
> >and we still respect the original fragment sizes, thus are not responsible
> >for potentially exceeding the PMTU on the following path.
> 
> Ok. So the plan is to remove net/ipv6/netfilter/nf_conntrack_reasm.c
> code entirely and use net/ipv6/reassembly.c code directly from
> nf_defrag_ipv6. This would result in very similar code currently ipv4
> has. 

If its possible to use net/ipv6/reassembly.c directly, even better,
so far I was thinking of just getting rid of the fragment replay,
but you're most likely right that this is the proper way to do it.

  reply	other threads:[~2013-11-05 22:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 11:02 [patch net-next 0/3] couple of reasm fixes Jiri Pirko
2013-11-05 11:02 ` [patch net-next 1/3] move skb_nfct_reasm into skbuff.h Jiri Pirko
2013-11-05 11:50   ` Marcelo Ricardo Leitner
2013-11-06  1:00   ` Simon Horman
2013-11-05 11:02 ` [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching Jiri Pirko
2013-11-05 11:50   ` Marcelo Ricardo Leitner
2013-11-05 13:32   ` Florian Westphal
2013-11-05 13:41     ` Patrick McHardy
2013-11-05 15:01       ` Jiri Pirko
2013-11-05 15:39         ` Florian Westphal
2013-11-05 18:19           ` Patrick McHardy
2013-11-05 18:21             ` Jiri Pirko
2013-11-05 18:16         ` Patrick McHardy
2013-11-05 20:55           ` Jiri Pirko
2013-11-05 22:02             ` Patrick McHardy [this message]
2013-11-06 14:18           ` Jiri Pirko
2013-11-06 14:33             ` Florian Westphal
2013-11-06 14:44               ` Jiri Pirko
2013-11-06 14:51                 ` Patrick McHardy
2013-11-06 15:29                   ` Jiri Pirko
2013-11-06 16:12                     ` Eric Dumazet
2013-11-05 11:02 ` [patch net-next 3/3] fix skb_morph to preserve skb->sk and skb->destructor pointers Jiri Pirko
2013-11-05 11:50   ` Marcelo Ricardo Leitner
2013-11-05 14:06   ` Eric Dumazet
2013-11-05 14:47     ` Jiri Pirko

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=20131105220222.GA9115@macbook.localnet \
    --to=kaber@trash.net \
    --cc=alexander.h.duyck@intel.com \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fw@strlen.de \
    --cc=horms@verge.net.au \
    --cc=ja@ssi.bg \
    --cc=jasowang@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=jmorris@namei.org \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=mleitner@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=pshelar@nicira.com \
    --cc=wensong@linux-vs.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.