It is possible that the ct flow key information would have
gone stale for the packets received from the userspace due to
clone or ct_clear actions.
In the case of OVN, it adds ping responder flows, which modifies
the original icmp4 request packet to a reply packet. It uses the
OVS actions - clone and ct_clear. When the reply packet hits the
"ovs_ct_execute" function, and since the ct flow key info is not
cleared, the connection tracker doesn't set the state to
ESTABLISHED state.
Note: This patch is marked as RFC, as I am not sure if this is the correct
place to address this issue or it should be addressed in ovs-vswitchd
to set the OVS_KEY_ATTR_CT_STATE and other related attributes
properly for ct_clear action.
Signed-off-by: Numan Siddique <nusid...@redhat.com>
---
net/openvswitch/flow.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 9d4bb8e..72b73db 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -836,6 +836,11 @@ int ovs_flow_key_extract_userspace(struct net *net, const
struct nlattr *attr,
if (err)
return err;
+ /* Clear the ct flow key after key_extract to avoid using
+ * stale ct key information.
+ */
+ ovs_ct_fill_key(skb, key);
+
/* Check that we have conntrack original direction tuple metadata only
* for packets for which it makes sense. Otherwise the key may be
* corrupted due to overlapping key fields.
--
2.9.3
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
