Thanks Darrell.
So glad to make the requirement clear by this discussion, expecting to see the
latest patch.
发件人: Darrell Ball
发送时间: 2019年6月6日 1:12
收件人: 姜立东
抄送: d...@openvswitch.org; 王志克
主题: Re: [ovs-dev] [PATCH] conntrack: add tcp_in_liberal option in userspace
conntrack
On Wed, Jun 5,
comments inline.
发件人: Darrell Ball
发送时间: 2019年6月5日 13:31
收件人: 姜立东
抄送: d...@openvswitch.org; 王志克
主题: Re: [ovs-dev] [PATCH] conntrack: add tcp_in_liberal option in userspace
conntrack
On Tue, Jun 4, 2019 at 7:13 PM 姜立东
mailto:jianglido...@jd.com>> wrote:
Please check comments inline.
BR,
Please check comments inline.
BR, Lidong
发件人: Darrell Ball
发送时间: 2019年6月4日 23:33
收件人: 姜立东
抄送: d...@openvswitch.org; 王志克
主题: Re: [ovs-dev] [PATCH] conntrack: add tcp_in_liberal option in userspace
conntrack
On Mon, Jun 3, 2019 at 7:59 PM 姜立东
mailto:jianglido...@jd.com>> wrote:
Hi Darrell,
Hi Darrell,
The “tighter checking” on TCP_RST in kernel, do you mean processes under
“TCP_CONNTRACK_CLOSE” case?
There is only one situation(when th->seq is less than peer td_maxack, as
mentioned) may leads to explicitly –NF_ACCEPT, kernel implementation just lets
most TCP_RST packets pass
Hi Darrell,
By checking latest patch, we notice it has inconsistent behavior on TCP_RST
packet with
kernel tcp_liberal option.
In kernel, TCP_RST packet is only checked for TCP_CONNTRACK_CLOSE state, TCP_RST
packet is dropped if its seq is less than peer acked.
In other cases, TCP_RST packets
Hi Darrell,
Thanks for prompt action.
I think there are 2 main differences in your change,
1. Replace Open_vswitch.other_config by dpctl CLI command.
2. One more case to check tcp_liberal as below.
@@ -333,10 +335,12 @@ tcp_conn_update(struct conntrack *ct, struct conn *conn_,
} else if
