Marc Dionne <marc.c.dio...@gmail.com> wrote: > On Mon, Jun 27, 2016 at 11:22 AM, Florian Westphal <f...@strlen.de> wrote: > > Marc Dionne <marc.c.dio...@gmail.com> wrote: > >> Hi,
> > hlist_nulls_for_each_entry(h, n, &nf_conntrack_hash[hash], hnnode) > > if (nf_ct_key_equal(h, > > &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, > > - zone, net)) > > - goto out; > > + zone, net)) { > > + nf_ct_add_to_dying_list(ct); > > + ret = nf_ct_resolve_clash(net, skb, ctinfo, h); > > + goto dying; > > + } This is bogus as h can be a reply too (key compare does not deal with it). Below is what I actually intended; I can't come up with a reason why you experience this issue other than that we're getting confused over reply/original direction. If the patch doesn't help either, can you tell us what kind of iptables rules are installed on the affected system or perhaps report perf drop monitor stat when things go wrong? Thanks! diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -638,6 +638,12 @@ static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb, struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h); struct nf_conntrack_l4proto *l4proto; + /* skb being confirmed is always original dir; do not attach to + * a reply tuple. + */ + if (NF_CT_DIRECTION(h) != IP_CT_DIR_ORIGINAL) + goto out; + l4proto = __nf_ct_l4proto_find(nf_ct_l3num(ct), nf_ct_protonum(ct)); if (l4proto->allow_clash && !nf_ct_is_dying(ct) && @@ -650,6 +656,7 @@ static int nf_ct_resolve_clash(struct net *net, struct sk_buff *skb, skb->nfct = &ct->ct_general; return NF_ACCEPT; } + out: NF_CT_STAT_INC(net, drop); return NF_DROP; }