From: Pablo Neira Ayuso <pablo@netfilter.org>
To: "Nicolas Maître" <nimai@skynet.be>
Cc: Netfilter Developer Mailing List <netfilter-devel@vger.kernel.org>
Subject: Re: Drop a packet while keeping the conntrack alive
Date: Thu, 21 Mar 2013 17:07:20 +0100 [thread overview]
Message-ID: <20130321160720.GA14783@localhost> (raw)
In-Reply-To: <CACd4Q00XP-OS8=9QM-Oyks9sp2qSGzQBYLHvmCh6r3J-JgjjWA@mail.gmail.com>
On Thu, Mar 21, 2013 at 04:17:47PM +0100, Nicolas Maître wrote:
> On Thu, Mar 21, 2013 at 2:53 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Packets that are invalid do not destroy the conntrack entry. The TCP
> > tracker explicitly destroys the entry by calling nf_ct_kill function
> > in some situations (RST seen / tracking is out-of-sync).
>
> Well, it means that nf_conntrack_put doesn't kill the conntrack as I
> thought. I still can't understand how the nfct from skb works. What is
> that "use" value that makes nf_conntrack_put() call
> nf_conntrack_destroy() when it equals zero?
That "use" field in the nf_conn object is a refcounter. In SMP, you
may have several packets traveling through the stack referencing to
the same conntrack object. The refcount is initially set to 1 because
there is a timer that releases the conntrack if it expires.
You may also have a conntrack entries that are related to another
master conntrack (eg. FTP helper scenario: the control flow is the
master conntrack, and all data flows are related to it). In that case,
the refcount is also incremented depending on the amount of references
to it.
nf_conntrack_find_get increments the refcount, nf_ct_put decrements it
and it checks if it has become 0, in that case the nf_conn object is
released.
This article may help you to understand better how conntrack works:
https://www.usenix.org/publications/login/june-2006-volume-31-number-3/netfilters-connection-tracking-system
Regards.
--
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
next prev parent reply other threads:[~2013-03-21 16:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 0:57 Drop a packet while keeping the conntrack alive Nicolas Maître
2013-03-21 1:53 ` Pablo Neira Ayuso
2013-03-21 15:17 ` Nicolas Maître
2013-03-21 16:07 ` Pablo Neira Ayuso [this message]
2013-03-21 16:16 ` Nicolas Maître
2013-03-21 2:05 ` Jorge Dávila
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=20130321160720.GA14783@localhost \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=nimai@skynet.be \
/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.