From patchwork Thu Jun 13 10:51:38 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Westphal X-Patchwork-Id: 251035 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id C19212C009E for ; Thu, 13 Jun 2013 20:51:43 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756109Ab3FMKvk (ORCPT ); Thu, 13 Jun 2013 06:51:40 -0400 Received: from Chamillionaire.breakpoint.cc ([80.244.247.6]:39936 "EHLO Chamillionaire.breakpoint.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756027Ab3FMKvk (ORCPT ); Thu, 13 Jun 2013 06:51:40 -0400 Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from ) id 1Un57y-00068m-Sb for netfilter-devel@vger.kernel.org; Thu, 13 Jun 2013 12:51:38 +0200 Date: Thu, 13 Jun 2013 12:51:38 +0200 From: Florian Westphal To: netfilter-devel@vger.kernel.org Subject: Huge timeout with loose=1 pickup tcp connections Message-ID: <20130613105138.GC21252@breakpoint.cc> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Hi. With nf_conntrack_tcp_loose = 1, stray packets will create conntrack with 5 days-timeout. Is this necessary? I ask, because I've got following tcp trace: 192.168.x is initiator/origin, 10.184. is responder/reply, connection is establised by usual 3whs, data was transmitted in both directions) A 55:07 (id 12053, [DF], TCP, len 40) 192.168.x.52792 > 10.184.y.80: F, 426:426(0) ack 9237 win 255 B 55:07 (id 6129, [DF], TCP, len 40) 10.184.y.80 > 192.168.x.52792: ., ack 427 win 123 C 56:08 (id 6130, [DF], TCP, len 40) 10.184.y.80 > 192.168.x.52792: F, 9237:9237(0) ack 427 win 123 D 56:08 (id 12159, [DF], TCP, len 40) 192.168.x.52792 > 10.184.y.80: ., ack 9238 win 255 D is last packet seen for that connection. Notice 61 second pause between B and C. From conntrack POV, we have following state transitions: [NEW] tcp 6 60 SYN_RECV .. [UPDATE] tcp 6 432000 ESTABLISHED .. [UPDATE] tcp 6 120 FIN_WAIT .. (triggered by packet A) [UPDATE] tcp 6 60 CLOSE_WAIT .. (triggered by packet B) [DESTROY] tcp 6 (triggered by 60-second CLOSE_WAIT timeout) [NEW] tcp 6 432034 ESTABLISHED .. [UNREPLIED] (triggered by packet D) Result is that, after a couple of hours, conntrack table starts to fill up with UNREPLIED crud. Follwing changes fix it: - set loose=0 (avoids bogus NEW connection), OR, - set net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=65 (avoids NEW connection, new state transitions are: [UPDATE] tcp 6 60 CLOSE_WAIT .. (triggered by packet B) [UPDATE] tcp 6 30 LAST_ACK .. (triggered by C) [UPDATE] tcp 6 120 TIME_WAIT .. (triggered by D) However, I think conntrack shouldn't insert a just-picked up connection with default ESTABLISHED timeout value. Suggestion: Jozsef, If you aggree I would make a formal submission. Thanks, Florian --- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c index 4d4d8f1..33ca4f3 100644 --- a/net/netfilter/nf_conntrack_proto_tcp.c +++ b/net/netfilter/nf_conntrack_proto_tcp.c @@ -1043,6 +1043,11 @@ static int tcp_packet(struct nf_conn *ct, nf_ct_kill_acct(ct, ctinfo, skb); return NF_ACCEPT; } + /* loose=1 picked up existing connection, avoid large timeout */ + if (old_state == TCP_CONNTRACK_NONE && + new_state == TCP_CONNTRACK_ESTABLISHED && + timeout > timeouts[TCP_CONNTRACK_UNACK]) + timeout = timeouts[TCP_CONNTRACK_UNACK]; } else if (!test_bit(IPS_ASSURED_BIT, &ct->status) && (old_state == TCP_CONNTRACK_SYN_RECV || old_state == TCP_CONNTRACK_ESTABLISHED)