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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
