From owner-freebsd-net@FreeBSD.ORG Thu Jun 7 20:28:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE9CF106566C; Thu, 7 Jun 2012 20:28:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE448FC18; Thu, 7 Jun 2012 20:28:40 +0000 (UTC) Received: from [209.249.190.124] (port=63932 helo=[10.2.212.229]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1ScjJu-0000ui-A1; Thu, 07 Jun 2012 16:28:38 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: Date: Thu, 7 Jun 2012 16:28:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Navdeep Parhar X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: freebsd-net@freebsd.org Subject: Re: seq# of RST in tcp_dropwithreset 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, 07 Jun 2012 20:28:40 -0000 On Mar 27, 2012, at 18:13 , Navdeep Parhar wrote: > When the kernel decides to respond with a RST to an incoming TCP > segment, it uses its ack# (if valid) as the seq# of the RST. See this > in tcp_dropwithreset: >=20 > if (th->th_flags & TH_ACK) { > tcp_respond(tp, mtod(m, void *), th, m, (tcp_seq)0, > th->th_ack, TH_RST); > } else { > if (th->th_flags & TH_SYN) > tlen++; > tcp_respond(tp, mtod(m, void *), th, m, th->th_seq+tlen, > (tcp_seq)0, TH_RST|TH_ACK); > } >=20 > This can have some unexpected results. I observed this on a link with > a very high delay (B is FreeBSD, A could be anything). >=20 > 1. There is a segment in flight from A to B. The ack# is X (all tx > from B to A is up to date and acknowledged). > 2. socket is closed on B. B sends a FIN with seq# X. > 3. The segment from A arrives and elicits a RST from B. The seq# of > this RST will again be X. A receives the FIN and then the RST with > identical sequence numbers. The situation resolves itself eventually, > when A retransmits and the retransmitted segment ACKs the FIN too and > so the next time around B sends a RST with the "correct" seq# (one > after the FIN). >=20 > If there is a local tcpcb for the connection with state >=3D > ESTABLISHED, wouldn't it be more accurate to use its snd_max as the > seq# of the RST? >=20 Hi Navdeep, Sorry I missed this so many months ago, but jhb@ was kind enough to = point this query out to me. My understanding of correct operation in this case, is = that we=20 do not want to move the sequence number until we have received the ACK = of our FIN, as any other value would indicate to the TCP on A that we have = received their ACK of our FIN, which, in this case, we have not. The fact that there = isn't a better way to indicate the error is a tad annoying, but, and others can correct = me if they think I'm wrong, this is the correct way for the stacks to come to eventual = agreement on the closing of the connection. Best, George