> Because conntrack has to process packets in both directions, and the > packet header fields in the reply direction may not be obtained just by > swapping the fields in the original direction. Thanks. That makes sense. I still have some confusion however: in the case where the original/reply connection information is not equal, how does the connection tracking system ensure that both hash tuples are embedded in the same conntrack struct (nf_conn)? Let's say an original packet arrives with some new original direction connection information. I'm assuming conntrack will allocate a new nf_conn struct with just the original hash tuple embedded. When a packet arrives from the reply direction, how does conntrack find the correct nf_conn to embed it in? From what I can tell the orifginal connection information is required to look this up. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
