The user should only reference a conntrack entry by the forward direction context, as per 'conntrack_flush()', enforce this by checking for 'default' conn_type. The likelihood of a user not using the original tuple is low, but it should be guarded against, logged and documented.
Signed-off-by: Darrell Ball <[email protected]> --- lib/conntrack.c | 3 ++- lib/dpctl.man | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/lib/conntrack.c b/lib/conntrack.c index 92b2db4..41232f4 100644 --- a/lib/conntrack.c +++ b/lib/conntrack.c @@ -2572,9 +2572,10 @@ conntrack_flush_tuple(struct conntrack *ct, const struct ct_dpif_tuple *tuple, ct_lock_lock(&ct->buckets[bucket].lock); conn_key_lookup(&ct->buckets[bucket], &ctx, time_msec()); - if (ctx.conn) { + if (ctx.conn && ctx.conn->conn_type == CT_CONN_TYPE_DEFAULT) { conn_clean(ct, ctx.conn, &ct->buckets[bucket]); } else { + VLOG_WARN("Must flush tuple using the original pre-NATed tuple"); error = ENOENT; } ct_lock_unlock(&ct->buckets[bucket].lock); diff --git a/lib/dpctl.man b/lib/dpctl.man index 68274d8..b18f38e 100644 --- a/lib/dpctl.man +++ b/lib/dpctl.man @@ -231,6 +231,8 @@ If \fBzone\fR=\fIzone\fR is specified, only flushes the connections in .IP If \fIct-tuple\fR is provided, flushes the connection entry specified by \fIct-tuple\fR in \fIzone\fR. The zone defaults to 0 if it is not provided. +The userspace connection tracker requires flushing with the original pre-NATed +tuple and a warning log will be otherwise generated. An example of an IPv4 ICMP \fIct-tuple\fR: .IP "ct_nw_src=10.1.1.1,ct_nw_dst=10.1.1.2,ct_nw_proto=1,icmp_type=8,icmp_code=0,icmp_id=10" -- 1.9.1 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
