On Wed, Oct 19, 2011 at 8:36 PM, Nikolay S. <nowhere@xxxxxxxxxxxxxxxx> wrote: > > В Срд, 19/10/2011 в 12:03 -0700, Erik Schweigert пишет: > > Hi all, > > > > I have noticed an oddity in the timeout values of a TCP Established > > connection. I currently have the > > "nf_conntrack_tcp_timeout_established = 1800". > > > > # cat /proc/net/nf_conntrack | grep EST > > ipv4 2 tcp 6 1385 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2513 dport=1217 packets=71 bytes=10154 > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2513 pac1 > > ----> ipv4 2 tcp 6 1799 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2550 dport=1217 packets=1142 bytes=121874 > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2550 1 > > ipv4 2 tcp 6 1413 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2515 dport=1217 packets=824 bytes=101370 > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2515 p1 > > ipv4 2 tcp 6 263 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2440 dport=1101 packets=41 bytes=6458 > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2440 packe1 > > ipv4 2 tcp 6 1221 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2512 dport=1101 packets=79 bytes=13578 > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2512 pac1 > > # cat /proc/net/nf_conntrack | grep EST > > ipv4 2 tcp 6 1369 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2513 dport=1217 packets=71 bytes=10154 > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2513 pac1 > > ----> ipv4 2 tcp 6 296 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2550 dport=1217 packets=1166 bytes=124610 > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2550 p1 > > ipv4 2 tcp 6 1396 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2515 dport=1217 packets=824 bytes=101370 > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2515 p1 > > ipv4 2 tcp 6 247 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2440 dport=1101 packets=41 bytes=6458 > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2440 packe1 > > ipv4 2 tcp 6 1205 ESTABLISHED src=192.168.10.25 > > dst=192.168.10.134 sport=2512 dport=1101 packets=79 bytes=13578 > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2512 pac1 > > > > You will notice in the two iterations I have marked above, the timeout > > values goes from 1799 to 296 within a 16 second span. Is this a bug > > or something inherent to the connection tracking system that I unaware > > of. > > TCP conntrack allows 5 minutes (300 seconds) for hosts to send the > acknowledge. Once connection has no unacknowledged segments, timeout > will revert to 1800 seconds. Is this also a user settable value? > > > > > I am running kernel 2.6.26.5. My current settings of the tunable > > conntrack features are: > > > > nf_conntrack_tcp_be_liberal = 0 > > nf_conntrack_tcp_loose = 1 > > nf_conntrack_tcp_max_retrans = 3 > > nf_conntrack_tcp_timeout_close = 10 > > nf_conntrack_tcp_timeout_close_wait = 60 > > nf_conntrack_tcp_timeout_established = 1800 > > nf_conntrack_tcp_timeout_fin_wait = 120 > > nf_conntrack_tcp_timeout_last_ack = 30 > > nf_conntrack_tcp_timeout_max_retrans = 300 > > nf_conntrack_tcp_timeout_syn_recv = 60 > > nf_conntrack_tcp_timeout_syn_sent = 120 > > nf_conntrack_tcp_timeout_time_wait = 120 > > > > Any help or suggestions is appreciated, > > Erik > > -- > > To unsubscribe from this list: send the line "unsubscribe netfilter" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- Erik Schweigert Email: ejschweigert@xxxxxxxxx Website: http://www.lainoox.com -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
