netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ESTABLISHED tcp conntrack timeout
@ 2019-04-10 10:47 Naruto Nguyen
  2019-04-11 10:20 ` Pablo Neira Ayuso
  0 siblings, 1 reply; 3+ messages in thread
From: Naruto Nguyen @ 2019-04-10 10:47 UTC (permalink / raw)
  To: netdev, netfilter-devel, netfilter

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?

Thanks,
Brs,
Naruto

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: ESTABLISHED tcp conntrack timeout
  2019-04-10 10:47 ESTABLISHED tcp conntrack timeout Naruto Nguyen
@ 2019-04-11 10:20 ` Pablo Neira Ayuso
  2019-04-16 15:52   ` Naruto Nguyen
  0 siblings, 1 reply; 3+ messages in thread
From: Pablo Neira Ayuso @ 2019-04-11 10:20 UTC (permalink / raw)
  To: Naruto Nguyen; +Cc: netfilter-devel

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: ESTABLISHED tcp conntrack timeout
  2019-04-11 10:20 ` Pablo Neira Ayuso
@ 2019-04-16 15:52   ` Naruto Nguyen
  0 siblings, 0 replies; 3+ messages in thread
From: Naruto Nguyen @ 2019-04-16 15:52 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel

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@netfilter.org> 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.

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-04-16 15:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-10 10:47 ESTABLISHED tcp conntrack timeout Naruto Nguyen
2019-04-11 10:20 ` Pablo Neira Ayuso
2019-04-16 15:52   ` Naruto Nguyen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).