netfilter: conntrack: lower timeout to RETRANS seconds if window is 0
Subsystems (2)
Florian Westphal
maintainerPATCH 1/1 netfilter: conntrack: lower timeout to RETRANS seconds if window is 0
When zero window is announced we can get into a situation where connection stays around forever:
1. One side announces zero window.
2. Other side closes.
In this case, no FIN is sent (stuck in send queue).
Unless other side opens the window up again conntrack stays in ESTABLISHED state for a very long time.
Lets alleviate this by lowering the timeout to RETRANS (5 minutes), the other end should be sending zero window probes to keep the connection established as long as a socket still exists.
--- net/netfilter/nf_conntrack_proto_tcp.c | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/nf_conntrack_proto_tcp.c +3 -0
@@ -1039,6 +1039,9 @@ static int tcp_packet(struct nf_conn *ct, IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED && timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK]) timeout = timeouts[TCP_CONNTRACK_UNACK ]; + else if (ct->proto.tcp.last_win == 0 && + timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS]) + timeout = timeouts[TCP_CONNTRACK_RETRANS ]; else timeout = timeouts[new_state];spin_unlock_bh (&ct->lock);
Signature · 1 line
2.13.6
Quoted 11 lines · Florian Westphal
When zero window is announced we can get into a situation where connection stays around forever:
1. One side announces zero window.
2. Other side closes.In this case, no FIN is sent (stuck in send queue).
Unless other side opens the window up again conntrack stays in ESTABLISHED state for a very long time.
Quoted 6 lines
Lets alleviate this by lowering the timeout to RETRANS (5 minutes), the other end should be sending zero window probes to keep the connection established as long as a socket still exists.
Cc Jozsef Kadlecsik <[email protected]>Signed-off-by Florian Westphal <[email protected]>
Thanks, Florian!
Jozsef
Quoted 26 lines
--- net/netfilter/nf_conntrack_proto_tcp.c | 3 +++ 1 file changed, 3 insertions(+)net/netfilter/nf_conntrack_proto_tcp.c +3
-0@@ -1039,6 +1039,9 @@ static int tcp_packet(struct nf_conn *ct, IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED && timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK]) timeout = timeouts[TCP_CONNTRACK_UNACK ]; + else if (ct->proto.tcp.last_win == 0 && + timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS]) + timeout = timeouts[TCP_CONNTRACK_RETRANS ]; else timeout = timeouts[new_state];spin_unlock_bh (&ct->lock);Signature · 6 lines
2.13.6 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
-
E-mail : [email protected], [email protected] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
Quoted 6 lines · Florian Westphal
When zero window is announced we can get into a situation where connection stays around forever:
1. One side announces zero window.
2. Other side closes.
Quoted 8 lines
In this case, no FIN is sent (stuck in send queue).
Unless other side opens the window up again conntrack stays in ESTABLISHED state for a very long time.
Lets alleviate this by lowering the timeout to RETRANS (5 minutes), the other end should be sending zero window probes to keep the connection established as long as a socket still exists.
Applied, thanks!