Hi Pablo, Thanks very much for your reply. I will describe the test later. Could you please let me know more clearly in case the TCP_CONNTRACK_UNACK is set if IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED is set? Does it indicate some UNACK packets due to network congestion, but eventually the ACK is sent, so no packet restransmission happens. Actually I did not see any packet restransmission in my wireshark trace. Best regards, Naruto <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Thu, 11 Apr 2019 at 17:21, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Hi, > > Dropping Cc to netdev and netfilter, no need to Cc everyone :-) > > On Wed, Apr 10, 2019 at 05:47:35PM +0700, Naruto Nguyen wrote: > > Hello everyone, > > > > When duplicating tcp conntrack from main name space to another network > > namespace, I see that sometimes timeout value for an established tcp > > connection in another network namespace has been changed from 432000 > > to 300 like below, even it is in ASSURED > > > > 03:05:53.773 > > tcp 6 300 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:05:56.018 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:05:58.267 > > tcp 6 300 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:00.511 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:02.767 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:05.024 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:07.318 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:09.578 > > tcp 6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:11.833 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:14.082 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:16.315 > > tcp 6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:25.314 > > tcp 6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:27.571 > > tcp 6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:29.815 > > tcp 6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752 > > dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752 > > [ASSURED] mark=0 use=1 > > 03:06:32.065 > > > > In nf_conntrack_proto_tcp.c, I see that 2 constants have 5 mins set > > > > [TCP_CONNTRACK_RETRANS] = 5 MINS, > > [TCP_CONNTRACK_UNACK] = 5 MINS, > > > > and the code > > > > if (ct->proto.tcp.retrans >= tn->tcp_max_retrans && > > timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS]) > > timeout = timeouts[TCP_CONNTRACK_RETRANS]; > > else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) & > > IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED && > > timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK]) > > timeout = timeouts[TCP_CONNTRACK_UNACK]; > > else > > timeout = timeouts[new_state]; > > > > but I am not sure this code cause the above issue. For the second > > TCP_CONNTRACK_UNACK, it only happens for [UNREPLIED] instead of > > [ASSURED]. Could you please let me know how the time out value can be > > changed for an established tcp connection and how to prevent this > > change? > > Probably you're seeing retransmission, did you have a look at packet > traces? > > Could you describe you testbed, your kernel, and so on? > > Thanks.
