From owner-freebsd-net@FreeBSD.ORG Thu Aug 9 01:48:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88B431065670 for ; Thu, 9 Aug 2012 01:48:13 +0000 (UTC) (envelope-from learner.study@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 465928FC0A for ; Thu, 9 Aug 2012 01:48:13 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1793435ggn.13 for ; Wed, 08 Aug 2012 18:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=tHpUhYPKPOY2Fya4dcti+hUh9I28YvZlk5tiyemZo5g=; b=u5gOmc1vZ5HLzPcRoBWtty9zb6S7IVvI147nOpXxZyYvLHNSaDDSbqjMaK0gLVhh2v GznyCuzcA1U65m5IwGboQXEIqJI7VwBeZxCBwut7Uyd3AGOMsR8MtLi2Pe2+ti34KZCk H54HyMJU7nFFfmZDfm2qAAR5hytSy5pcTLB24qLYLUHSWLKY+QzEfjgFej0rMueSWe7/ tG0QQ6g2LabxPRkllu2Y1ycZ9NpFo5GNuqTnXu6fXIelaTKemBA57uIQ2w57cfwl00ri 8FN87oXZwGGmzviPWdeoTRfVQmhsEf3MuK4zX9WP/PqW9dh0+68ja3wtVRHUQYHLKGeU +XTg== Received: by 10.50.196.197 with SMTP id io5mr776467igc.20.1344476892313; Wed, 08 Aug 2012 18:48:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.23.42 with HTTP; Wed, 8 Aug 2012 18:47:51 -0700 (PDT) From: Learner Study Date: Wed, 8 Aug 2012 18:47:51 -0700 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Learner Study Subject: TCP: Out of order RST handling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 01:48:13 -0000 Greetings, I've a question on out of order RSTs handling... Assume a TCP session between node #1 and node #2 and there is some data transfer happening in both directions. Assume there are some pkt drops happening also in the direction of node #1 to node #2. node #1 sends a RST but seq number of RST happens to be out of order. Per the seq/last_ack/rcv_nxt checks in tcp_input.c, depending on if the seqnum is in the window, the RST may be dropped. Assume, due to various checks, RST is dropped. TCP state machine of Node #2 doesn't know about this dropped RST and would keep the session alive. Node #1 sends another RST, which is dropped again inside node #2 due to various OOO checks...and this keeps going on. Such TCP sessions on node #2 stay for ever....node #1 won't reTx any dropped pkts, so I'm not sure of the recovery from this state. Could someone let me know how is node #2 supposed to recover. Due to continuous RST traffic, Keepalive timer gets reset also...so that won't kick-in also... Thank You.