On Tuesday 2011-03-15 00:49, Changli Gao wrote: >>>the final tuples will be: >>>src = home dst = router src=1.2.3.4 dst=192.168.0.1 >>> >>>However, the tuple saved by connlimit is src=1.2.3.4 dst=home, so this >>>conn will be removed later as there isn't any conntrack, which has >>>this tuple in any direction. >> >> But I don't yet see how your patch #1 can help. At the time >> conn->tupleÂ= *tuple is done, *tuple still contains the non-SNATed >> tuple, and it is never updated again. > >In this patch, conn->addr is used to save the destination/source >address instead of conn->tuple.src.u3, so the conn->tuple is used for >conntrack lookup only. Just as the original tuple isn't updated, we >can use it to looking up the associated conntrack all the time. The original tuple may not be updated, but the reply tuple is. And we are taking the reply tuple in tuple_ptr = &ct->tuplehash[IP_CT_DIR_REPLY].tuple; which is subsequently copied to conn->tuple on the first invocation. Afterwards, SNAT will update ct->tuplehash[reply].tuple, and so conn->tuple is outdated. Calling nf_conntrack_find_get(conn->tuple) in count_them would then fail, would it not? -- 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
