[ovs-dev] conntrack: Fix conntrack new state
diff mbox series

Message ID 1576864268-130410-1-git-send-email-yihung.wei@gmail.com
State New
Headers show
Series
  • [ovs-dev] conntrack: Fix conntrack new state
Related show

Commit Message

Yi-Hung Wei Dec. 20, 2019, 5:51 p.m. UTC
In connection tracking system, a connection is established if we
see packets from both directions.  However, in userspace datapath's
conntrack, if we send a connection setup packet in one direction
twice, it will make the connection to be in established state.

This patch fixes the aforementioned issue, and adds a system traffic
test for UDP and TCP traffic to avoid regression.

Fixes: a489b16854b59 ("conntrack: New userspace connection tracker.")
Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
---
Travis CI: https://travis-ci.org/YiHungWei/ovs/builds/627518780

---
 lib/conntrack-other.c   |  4 +++-
 lib/conntrack-private.h |  1 +
 lib/conntrack-tcp.c     | 15 ++++++++++-----
 lib/conntrack.c         |  3 +++
 tests/system-traffic.at | 41 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 58 insertions(+), 6 deletions(-)

Comments

Ben Pfaff Dec. 20, 2019, 9:16 p.m. UTC | #1
On Fri, Dec 20, 2019 at 09:51:08AM -0800, Yi-Hung Wei wrote:
> In connection tracking system, a connection is established if we
> see packets from both directions.  However, in userspace datapath's
> conntrack, if we send a connection setup packet in one direction
> twice, it will make the connection to be in established state.
> 
> This patch fixes the aforementioned issue, and adds a system traffic
> test for UDP and TCP traffic to avoid regression.
> 
> Fixes: a489b16854b59 ("conntrack: New userspace connection tracker.")
> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
> ---
> Travis CI: https://travis-ci.org/YiHungWei/ovs/builds/627518780

Good catch!

Darrell, will you review this?
Darrell Ball Dec. 26, 2019, 5:23 p.m. UTC | #2
Sure Ben, I will take a look.

Thanks Darrell

On Fri, Dec 20, 2019 at 1:16 PM Ben Pfaff <blp@ovn.org> wrote:

> On Fri, Dec 20, 2019 at 09:51:08AM -0800, Yi-Hung Wei wrote:
> > In connection tracking system, a connection is established if we
> > see packets from both directions.  However, in userspace datapath's
> > conntrack, if we send a connection setup packet in one direction
> > twice, it will make the connection to be in established state.
> >
> > This patch fixes the aforementioned issue, and adds a system traffic
> > test for UDP and TCP traffic to avoid regression.
> >
> > Fixes: a489b16854b59 ("conntrack: New userspace connection tracker.")
> > Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
> > ---
> > Travis CI: https://travis-ci.org/YiHungWei/ovs/builds/627518780
>
> Good catch!
>
> Darrell, will you review this?
>
William Tu Jan. 29, 2020, 6:58 p.m. UTC | #3
On Fri, Dec 20, 2019 at 01:16:39PM -0800, Ben Pfaff wrote:
> On Fri, Dec 20, 2019 at 09:51:08AM -0800, Yi-Hung Wei wrote:
> > In connection tracking system, a connection is established if we
> > see packets from both directions.  However, in userspace datapath's
> > conntrack, if we send a connection setup packet in one direction
> > twice, it will make the connection to be in established state.
> > 
> > This patch fixes the aforementioned issue, and adds a system traffic
> > test for UDP and TCP traffic to avoid regression.
> > 
> > Fixes: a489b16854b59 ("conntrack: New userspace connection tracker.")
> > Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
> > ---

LGTM. I applied this to master, and branch 2.13.
Thanks
William
Dumitru Ceara Jan. 31, 2020, 10:07 a.m. UTC | #4
On 1/29/20 7:58 PM, William Tu wrote:
> On Fri, Dec 20, 2019 at 01:16:39PM -0800, Ben Pfaff wrote:
>> On Fri, Dec 20, 2019 at 09:51:08AM -0800, Yi-Hung Wei wrote:
>>> In connection tracking system, a connection is established if we
>>> see packets from both directions.  However, in userspace datapath's
>>> conntrack, if we send a connection setup packet in one direction
>>> twice, it will make the connection to be in established state.
>>>
>>> This patch fixes the aforementioned issue, and adds a system traffic
>>> test for UDP and TCP traffic to avoid regression.
>>>
>>> Fixes: a489b16854b59 ("conntrack: New userspace connection tracker.")
>>> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
>>> ---
> 
> LGTM. I applied this to master, and branch 2.13.
> Thanks
> William
> 

Hi William, Yi-Hung,

This patch breaks OVN switch load balancer system tests when running
with the OVS userspace datapath. I only had a glance at the code and
didn't dig into why exactly the tests fail yet but it's quite easy to
reproduce:

$ cd /tmp/
$ git clone https://github.com/openvswitch/ovs
$ cd /tmp/ovs
$ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e
$ ./boot.sh && ./configure && make -j8
$ cd /tmp/
$ git clone https://github.com/ovn-org/ovn
$ cd /tmp/ovn/
$ ./boot.sh && ./configure --with-ovs-source=/tmp/ovs
--with-ovs-build=/tmp/ovs && make -j8
$ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
[...]
system-ovn

  7: ovn -- load-balancing                           FAILED
(system-ovn.at:1121)
  8: ovn -- load-balancing - IPv6                    FAILED
(system-ovn.at:1268)
  9: ovn -- load-balancing - same subnet.            FAILED
(system-ovn.at:1389)
 10: ovn -- load-balancing - same subnet. - IPv6     FAILED
(system-ovn.at:1498)
 11: ovn -- load balancing in gateway router         ok
 12: ovn -- load balancing in gateway router - IPv6  ok
 13: ovn -- multiple gateway routers, load-balancing ok
 14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
 15: ovn -- load balancing in router with gateway router port ok
 16: ovn -- load balancing in router with gateway router port - IPv6 ok

# Reverting commit a867c010ee9183885ee9d3eb76a0005c075c4d2e

$ cd /tmp/ovs
$ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e~
$ make -j8
$ cd /tmp/ovn
$ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
[...]
system-ovn

  7: ovn -- load-balancing                           ok
  8: ovn -- load-balancing - IPv6                    ok
  9: ovn -- load-balancing - same subnet.            ok
 10: ovn -- load-balancing - same subnet. - IPv6     ok
 11: ovn -- load balancing in gateway router         ok
 12: ovn -- load balancing in gateway router - IPv6  ok
 13: ovn -- multiple gateway routers, load-balancing ok
 14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
 15: ovn -- load balancing in router with gateway router port ok
 16: ovn -- load balancing in router with gateway router port - IPv6 ok

Thanks,
Dumitru
Yi-Hung Wei Feb. 3, 2020, 11:48 p.m. UTC | #5
On Fri, Jan 31, 2020 at 2:07 AM Dumitru Ceara <dceara@redhat.com> wrote:
>
> On 1/29/20 7:58 PM, William Tu wrote:
> > On Fri, Dec 20, 2019 at 01:16:39PM -0800, Ben Pfaff wrote:
> >> On Fri, Dec 20, 2019 at 09:51:08AM -0800, Yi-Hung Wei wrote:
> >>> In connection tracking system, a connection is established if we
> >>> see packets from both directions.  However, in userspace datapath's
> >>> conntrack, if we send a connection setup packet in one direction
> >>> twice, it will make the connection to be in established state.
> >>>
> >>> This patch fixes the aforementioned issue, and adds a system traffic
> >>> test for UDP and TCP traffic to avoid regression.
> >>>
> >>> Fixes: a489b16854b59 ("conntrack: New userspace connection tracker.")
> >>> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
> >>> ---
> >
> > LGTM. I applied this to master, and branch 2.13.
> > Thanks
> > William
> >
>
> Hi William, Yi-Hung,
>
> This patch breaks OVN switch load balancer system tests when running
> with the OVS userspace datapath. I only had a glance at the code and
> didn't dig into why exactly the tests fail yet but it's quite easy to
> reproduce:
>
> $ cd /tmp/
> $ git clone https://github.com/openvswitch/ovs
> $ cd /tmp/ovs
> $ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e
> $ ./boot.sh && ./configure && make -j8
> $ cd /tmp/
> $ git clone https://github.com/ovn-org/ovn
> $ cd /tmp/ovn/
> $ ./boot.sh && ./configure --with-ovs-source=/tmp/ovs
> --with-ovs-build=/tmp/ovs && make -j8
> $ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
> [...]
> system-ovn
>
>   7: ovn -- load-balancing                           FAILED
> (system-ovn.at:1121)
>   8: ovn -- load-balancing - IPv6                    FAILED
> (system-ovn.at:1268)
>   9: ovn -- load-balancing - same subnet.            FAILED
> (system-ovn.at:1389)
>  10: ovn -- load-balancing - same subnet. - IPv6     FAILED
> (system-ovn.at:1498)
>  11: ovn -- load balancing in gateway router         ok
>  12: ovn -- load balancing in gateway router - IPv6  ok
>  13: ovn -- multiple gateway routers, load-balancing ok
>  14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
>  15: ovn -- load balancing in router with gateway router port ok
>  16: ovn -- load balancing in router with gateway router port - IPv6 ok
>
> # Reverting commit a867c010ee9183885ee9d3eb76a0005c075c4d2e
>
> $ cd /tmp/ovs
> $ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e~
> $ make -j8
> $ cd /tmp/ovn
> $ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
> [...]
> system-ovn
>
>   7: ovn -- load-balancing                           ok
>   8: ovn -- load-balancing - IPv6                    ok
>   9: ovn -- load-balancing - same subnet.            ok
>  10: ovn -- load-balancing - same subnet. - IPv6     ok
>  11: ovn -- load balancing in gateway router         ok
>  12: ovn -- load balancing in gateway router - IPv6  ok
>  13: ovn -- multiple gateway routers, load-balancing ok
>  14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
>  15: ovn -- load balancing in router with gateway router port ok
>  16: ovn -- load balancing in router with gateway router port - IPv6 ok
>
> Thanks,
> Dumitru


Hi Dumitru,

Thanks for reporting this issue. I am not familiar with OVN and the
broken system tests, but I will take a look.

-Yi-Hung
Dumitru Ceara Feb. 4, 2020, 8:05 a.m. UTC | #6
On 2/4/20 12:48 AM, Yi-Hung Wei wrote:
> On Fri, Jan 31, 2020 at 2:07 AM Dumitru Ceara <dceara@redhat.com> wrote:
>>
>> On 1/29/20 7:58 PM, William Tu wrote:
>>> On Fri, Dec 20, 2019 at 01:16:39PM -0800, Ben Pfaff wrote:
>>>> On Fri, Dec 20, 2019 at 09:51:08AM -0800, Yi-Hung Wei wrote:
>>>>> In connection tracking system, a connection is established if we
>>>>> see packets from both directions.  However, in userspace datapath's
>>>>> conntrack, if we send a connection setup packet in one direction
>>>>> twice, it will make the connection to be in established state.
>>>>>
>>>>> This patch fixes the aforementioned issue, and adds a system traffic
>>>>> test for UDP and TCP traffic to avoid regression.
>>>>>
>>>>> Fixes: a489b16854b59 ("conntrack: New userspace connection tracker.")
>>>>> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
>>>>> ---
>>>
>>> LGTM. I applied this to master, and branch 2.13.
>>> Thanks
>>> William
>>>
>>
>> Hi William, Yi-Hung,
>>
>> This patch breaks OVN switch load balancer system tests when running
>> with the OVS userspace datapath. I only had a glance at the code and
>> didn't dig into why exactly the tests fail yet but it's quite easy to
>> reproduce:
>>
>> $ cd /tmp/
>> $ git clone https://github.com/openvswitch/ovs
>> $ cd /tmp/ovs
>> $ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e
>> $ ./boot.sh && ./configure && make -j8
>> $ cd /tmp/
>> $ git clone https://github.com/ovn-org/ovn
>> $ cd /tmp/ovn/
>> $ ./boot.sh && ./configure --with-ovs-source=/tmp/ovs
>> --with-ovs-build=/tmp/ovs && make -j8
>> $ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
>> [...]
>> system-ovn
>>
>>   7: ovn -- load-balancing                           FAILED
>> (system-ovn.at:1121)
>>   8: ovn -- load-balancing - IPv6                    FAILED
>> (system-ovn.at:1268)
>>   9: ovn -- load-balancing - same subnet.            FAILED
>> (system-ovn.at:1389)
>>  10: ovn -- load-balancing - same subnet. - IPv6     FAILED
>> (system-ovn.at:1498)
>>  11: ovn -- load balancing in gateway router         ok
>>  12: ovn -- load balancing in gateway router - IPv6  ok
>>  13: ovn -- multiple gateway routers, load-balancing ok
>>  14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
>>  15: ovn -- load balancing in router with gateway router port ok
>>  16: ovn -- load balancing in router with gateway router port - IPv6 ok
>>
>> # Reverting commit a867c010ee9183885ee9d3eb76a0005c075c4d2e
>>
>> $ cd /tmp/ovs
>> $ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e~
>> $ make -j8
>> $ cd /tmp/ovn
>> $ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
>> [...]
>> system-ovn
>>
>>   7: ovn -- load-balancing                           ok
>>   8: ovn -- load-balancing - IPv6                    ok
>>   9: ovn -- load-balancing - same subnet.            ok
>>  10: ovn -- load-balancing - same subnet. - IPv6     ok
>>  11: ovn -- load balancing in gateway router         ok
>>  12: ovn -- load balancing in gateway router - IPv6  ok
>>  13: ovn -- multiple gateway routers, load-balancing ok
>>  14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
>>  15: ovn -- load balancing in router with gateway router port ok
>>  16: ovn -- load balancing in router with gateway router port - IPv6 ok
>>
>> Thanks,
>> Dumitru
> 
> 
> Hi Dumitru,
> 
> Thanks for reporting this issue. I am not familiar with OVN and the
> broken system tests, but I will take a look.
> 
> -Yi-Hung
> 

Hi Yi-Hung,

Please let me know if you need help. I can try to find a simpler way to
reproduce the issue.

Regards,
Dumitru
Roni Bar Yanai Feb. 20, 2020, 12:42 p.m. UTC | #7
Hi Yi-Hung,

From the man page, it looks like the +est is the result of committing action and not related to the TCP state machine itself.
I'm aware that this is not how it works in kernel conntrack, if you want to align both , the description might need an update.

  	new (0x01)
                     A new connection. Set to 1 if this is an uncommitted con‐
                     nection.

              est (0x02)
                     Part of an existing connection. Set to 1  if  this  is  a
                     committed connection.

>-----Original Message-----
>From: dev <ovs-dev-bounces@openvswitch.org> On Behalf Of Dumitru Ceara
>Sent: Tuesday, February 4, 2020 10:06 AM
>To: Yi-Hung Wei <yihung.wei@gmail.com>
>Cc: ovs dev <dev@openvswitch.org>
>Subject: Re: [ovs-dev] [PATCH] conntrack: Fix conntrack new state
>
>On 2/4/20 12:48 AM, Yi-Hung Wei wrote:
>> On Fri, Jan 31, 2020 at 2:07 AM Dumitru Ceara <dceara@redhat.com> wrote:
>>>
>>> On 1/29/20 7:58 PM, William Tu wrote:
>>>> On Fri, Dec 20, 2019 at 01:16:39PM -0800, Ben Pfaff wrote:
>>>>> On Fri, Dec 20, 2019 at 09:51:08AM -0800, Yi-Hung Wei wrote:
>>>>>> In connection tracking system, a connection is established if we
>>>>>> see packets from both directions.  However, in userspace
>>>>>> datapath's conntrack, if we send a connection setup packet in one
>>>>>> direction twice, it will make the connection to be in established state.
>>>>>>
>>>>>> This patch fixes the aforementioned issue, and adds a system
>>>>>> traffic test for UDP and TCP traffic to avoid regression.
>>>>>>
>>>>>> Fixes: a489b16854b59 ("conntrack: New userspace connection
>>>>>> tracker.")
>>>>>> Signed-off-by: Yi-Hung Wei <yihung.wei@gmail.com>
>>>>>> ---
>>>>
>>>> LGTM. I applied this to master, and branch 2.13.
>>>> Thanks
>>>> William
>>>>
>>>
>>> Hi William, Yi-Hung,
>>>
>>> This patch breaks OVN switch load balancer system tests when running
>>> with the OVS userspace datapath. I only had a glance at the code and
>>> didn't dig into why exactly the tests fail yet but it's quite easy to
>>> reproduce:
>>>
>>> $ cd /tmp/
>>> $ git clone https://github.com/openvswitch/ovs
>>> $ cd /tmp/ovs
>>> $ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e
>>> $ ./boot.sh && ./configure && make -j8 $ cd /tmp/ $ git clone
>>> https://github.com/ovn-org/ovn $ cd /tmp/ovn/ $ ./boot.sh &&
>>> ./configure --with-ovs-source=/tmp/ovs --with-ovs-build=/tmp/ovs &&
>>> make -j8 $ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
>>> [...]
>>> system-ovn
>>>
>>>   7: ovn -- load-balancing                           FAILED
>>> (system-ovn.at:1121)
>>>   8: ovn -- load-balancing - IPv6                    FAILED
>>> (system-ovn.at:1268)
>>>   9: ovn -- load-balancing - same subnet.            FAILED
>>> (system-ovn.at:1389)
>>>  10: ovn -- load-balancing - same subnet. - IPv6     FAILED
>>> (system-ovn.at:1498)
>>>  11: ovn -- load balancing in gateway router         ok
>>>  12: ovn -- load balancing in gateway router - IPv6  ok
>>>  13: ovn -- multiple gateway routers, load-balancing ok
>>>  14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
>>>  15: ovn -- load balancing in router with gateway router port ok
>>>  16: ovn -- load balancing in router with gateway router port - IPv6
>>> ok
>>>
>>> # Reverting commit a867c010ee9183885ee9d3eb76a0005c075c4d2e
>>>
>>> $ cd /tmp/ovs
>>> $ git checkout a867c010ee9183885ee9d3eb76a0005c075c4d2e~
>>> $ make -j8
>>> $ cd /tmp/ovn
>>> $ make -j8 check-system-userspace TESTSUITEFLAGS="-k ovnlb"
>>> [...]
>>> system-ovn
>>>
>>>   7: ovn -- load-balancing                           ok
>>>   8: ovn -- load-balancing - IPv6                    ok
>>>   9: ovn -- load-balancing - same subnet.            ok
>>>  10: ovn -- load-balancing - same subnet. - IPv6     ok
>>>  11: ovn -- load balancing in gateway router         ok
>>>  12: ovn -- load balancing in gateway router - IPv6  ok
>>>  13: ovn -- multiple gateway routers, load-balancing ok
>>>  14: ovn -- multiple gateway routers, load-balancing - IPv6 ok
>>>  15: ovn -- load balancing in router with gateway router port ok
>>>  16: ovn -- load balancing in router with gateway router port - IPv6
>>> ok
>>>
>>> Thanks,
>>> Dumitru
>>
>>
>> Hi Dumitru,
>>
>> Thanks for reporting this issue. I am not familiar with OVN and the
>> broken system tests, but I will take a look.
>>
>> -Yi-Hung
>>
>
>Hi Yi-Hung,
>
>Please let me know if you need help. I can try to find a simpler way to reproduce
>the issue.
>
>Regards,
>Dumitru
>
>_______________________________________________
>dev mailing list
>dev@openvswitch.org
>https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Patch
diff mbox series

diff --git a/lib/conntrack-other.c b/lib/conntrack-other.c
index 932f2f4ad9c6..de22ef87cc19 100644
--- a/lib/conntrack-other.c
+++ b/lib/conntrack-other.c
@@ -47,16 +47,18 @@  other_conn_update(struct conntrack *ct, struct conn *conn_,
                   struct dp_packet *pkt OVS_UNUSED, bool reply, long long now)
 {
     struct conn_other *conn = conn_other_cast(conn_);
+    enum ct_update_res ret = CT_UPDATE_VALID;
 
     if (reply && conn->state != OTHERS_BIDIR) {
         conn->state = OTHERS_BIDIR;
     } else if (conn->state == OTHERS_FIRST) {
         conn->state = OTHERS_MULTIPLE;
+        ret = CT_UPDATE_VALID_NEW;
     }
 
     conn_update_expiration(ct, &conn->up, other_timeouts[conn->state], now);
 
-    return CT_UPDATE_VALID;
+    return ret;
 }
 
 static bool
diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index b04e4cd77542..9a8ca3910157 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -124,6 +124,7 @@  enum ct_update_res {
     CT_UPDATE_INVALID,
     CT_UPDATE_VALID,
     CT_UPDATE_NEW,
+    CT_UPDATE_VALID_NEW,
 };
 
 /* Timeouts: all the possible timeout states passed to update_expiration()
diff --git a/lib/conntrack-tcp.c b/lib/conntrack-tcp.c
index 47eb8e20346f..416cb769d22f 100644
--- a/lib/conntrack-tcp.c
+++ b/lib/conntrack-tcp.c
@@ -181,11 +181,16 @@  tcp_conn_update(struct conntrack *ct, struct conn *conn_,
         return CT_UPDATE_INVALID;
     }
 
-    if (((tcp_flags & (TCP_SYN | TCP_ACK)) == TCP_SYN)
-        && dst->state >= CT_DPIF_TCPS_FIN_WAIT_2
-        && src->state >= CT_DPIF_TCPS_FIN_WAIT_2) {
-        src->state = dst->state = CT_DPIF_TCPS_CLOSED;
-        return CT_UPDATE_NEW;
+    if ((tcp_flags & (TCP_SYN | TCP_ACK)) == TCP_SYN) {
+        if (dst->state >= CT_DPIF_TCPS_FIN_WAIT_2
+            && src->state >= CT_DPIF_TCPS_FIN_WAIT_2) {
+            src->state = dst->state = CT_DPIF_TCPS_CLOSED;
+            return CT_UPDATE_NEW;
+        } else if (src->state <= CT_DPIF_TCPS_SYN_SENT) {
+            src->state = CT_DPIF_TCPS_SYN_SENT;
+            conn_update_expiration(ct, &conn->up, CT_TM_TCP_FIRST_PACKET, now);
+            return CT_UPDATE_NEW;
+        }
     }
 
     if (src->wscale & CT_WSCALE_FLAG
diff --git a/lib/conntrack.c b/lib/conntrack.c
index b80080e72bf8..eb3790a9aecb 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -1110,6 +1110,9 @@  conn_update_state(struct conntrack *ct, struct dp_packet *pkt,
             ovs_mutex_unlock(&ct->ct_lock);
             create_new_conn = true;
             break;
+        case CT_UPDATE_VALID_NEW:
+            pkt->md.ct_state |= CS_NEW;
+            break;
         default:
             OVS_NOT_REACHED();
         }
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 0fb7aacfa14e..4a39c929c207 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -2290,6 +2290,47 @@  tcp,orig=(src=10.1.1.1,dst=10.1.1.2,sport=<cleared>,dport=<cleared>),reply=(src=
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
+AT_SETUP([conntrack - new connections])
+CHECK_CONNTRACK()
+OVS_TRAFFIC_VSWITCHD_START()
+
+ADD_NAMESPACES(at_ns0, at_ns1)
+
+ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
+ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
+
+AT_DATA([flows1.txt], [dnl
+table=0, priority=1,action=drop
+table=0, priority=10,arp,action=normal
+table=0, priority=100,tcp,action=ct(table=1)
+table=0, priority=100,udp,action=ct(table=1)
+table=1, priority=100,in_port=1,tcp,ct_state=+trk+new,action=ct(commit)
+table=1, priority=100,in_port=1,udp,ct_state=+trk+new,action=ct(commit)
+table=1, priority=100,in_port=1,ct_state=+trk+est,action=2
+table=1, priority=100,in_port=2,ct_state=+trk+est,action=1
+])
+
+ovs-appctl vlog/set dbg
+
+AT_CHECK([ovs-ofctl --bundle add-flows br0 flows1.txt])
+
+dnl TCP traffic from ns0 to ns1 should fail.
+OVS_START_L7([at_ns1], [http])
+NS_CHECK_EXEC([at_ns0], [wget 10.1.1.2 -t 3 -T 1 --retry-connrefused -v -o wget0.log], [4])
+
+dnl Send UDP packet on port 1 twice.
+AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 "in_port=1 packet=50540000000a50540000000908004500001c000000000011a4cd0a0101010a0101020001000200080000 actions=resubmit(,0)"])
+AT_CHECK([ovs-ofctl -O OpenFlow13 packet-out br0 "in_port=1 packet=50540000000a50540000000908004500001c000000000011a4cd0a0101010a0101020001000200080000 actions=resubmit(,0)"])
+
+dnl There should not be any packet that matches the established ct_state.
+AT_CHECK([ovs-ofctl dump-flows br0 "table=1 in_port=1,ct_state=+trk+est" | ofctl_strip], [0], [dnl
+NXST_FLOW reply:
+ table=1, priority=100,ct_state=+est+trk,in_port=1 actions=output:2
+])
+
+OVS_TRAFFIC_VSWITCHD_STOP
+AT_CLEANUP
+
 AT_SETUP([conntrack - ICMP related])
 AT_SKIP_IF([test $HAVE_NC = no])
 CHECK_CONNTRACK()