On Tue, Mar 15, 2011 at 9:16 AM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote: > > > 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? > After my patch, tuple is only used to look up the corresponding conntrack. And as you know, one conntrack has two tuples, you can look up a conntrack by either one. The old implementation uses the conn->tuple.src.u3 to save target address, so you need to use the reply tuple to work around the DNAT issue. In my patch, the target address isn't saved in conn->tuple.src.u3 but in conn->addr, so we can use the constant tuple in the original direction to look up the corresponding conntrack in count_them(). No reply tuple involved, no failed nf_conntrack_find_get(). -- Regards, Changli Gao(xiaosuo@xxxxxxxxx) -- 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
