From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 3/8] netfilter: xtables: inclusion of xt_TEE Date: Tue, 13 Apr 2010 19:31:15 +0200 Message-ID: <4BC4AA63.8050208@trash.net> References: <1271162268-28131-1-git-send-email-jengelh@medozas.de> <1271162268-28131-4-git-send-email-jengelh@medozas.de> <4BC4756B.4090307@trash.net> <4BC49C9D.9020902@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@vger.kernel.org To: Jan Engelhardt Return-path: Received: from stinky.trash.net ([213.144.137.162]:53788 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979Ab0DMRbR (ORCPT ); Tue, 13 Apr 2010 13:31:17 -0400 In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: Jan Engelhardt wrote: > On Tuesday 2010-04-13 18:32, Patrick McHardy wrote: > >>>>> +#ifdef WITH_CONNTRACK >>>>> + nf_conntrack_put(skb->nfct); >>>>> + skb->nfct = &tee_track.ct_general; >>>>> + skb->nfctinfo = IP_CT_NEW; >>>>> + nf_conntrack_get(skb->nfct); >>>>> +#endif >>>> Why do we still need this? I thought the reentrancy-counter should take >>>> care of this? >>> Did I really delete that commit... it's done so that conntrack >>> does not count the duplicated packets towards the original >>> connection. >> Simply untrack it perhaps? > > Well, that's what the four lines do, that's what NOTRACK does - > assigning to a fake nfct, isn't it? Yeah, but a different one from the untracked conntrack, which is already explicitly checked for where necessary.