From owner-freebsd-net@FreeBSD.ORG Fri Nov 15 16:03:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B450D79 for ; Fri, 15 Nov 2013 16:03:31 +0000 (UTC) Received: from st11p05mm-asmtp001.mac.com (st11p05mm-asmtp004.mac.com [17.172.108.249]) by mx1.freebsd.org (Postfix) with ESMTP id 156842325 for ; Fri, 15 Nov 2013 16:03:30 +0000 (UTC) Received: from [17.168.177.121] (unknown [17.168.177.121]) by st11p05mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MWB0018NB9MB500@st11p05mm-asmtp001.mac.com> for freebsd-net@freebsd.org; Fri, 15 Nov 2013 16:03:24 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.14,0.0.0000 definitions=2013-11-15_02:2013-11-15,2013-11-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1311150095 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Question regarding RST packet and the tcp stack From: Charles Swiger In-reply-to: Date: Fri, 15 Nov 2013 08:03:22 -0800 Content-transfer-encoding: quoted-printable Message-id: References: To: Andrew Schmidt X-Mailer: Apple Mail (2.1822) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 16:03:31 -0000 Hi-- On Nov 15, 2013, at 7:22 AM, Andrew Schmidt = wrote: > Apologies in advance, but can you confirm that a "CLOSE" means either = a FIN or RST? "CLOSE" corresponds to when one side calls close(2) in userland. The = TCP stack will send any remaining unsent bytes and then a FIN, moving = the connection from ESTAB to FIN-WAIT-1; the other side of the = connection which receives a FIN moves to CLOSE-WAIT. (See state diagram = around page 22.) > I've read this section over and over, and I still don't fully = understand where it confirms those bytes should be readable (I'm sure = you are correct, but I just need to be able to explain this to someone = else, and right now I'm not 100% clear) Well, read other parts of the RFC.... > For instance this part: >=20 >> A TCP will reliably deliver all >> buffers SENT before the connection was CLOSED so a user who expects = no >> data in return need only wait to hear the connection was CLOSED >> successfully to know that all his data was received at the = destination >> TCP. >=20 > Seems to be talking about the side that is closing the connection = (which in my example is the remote side). Which side wants to close first doesn't have a bearing on data being = sent from the other side. > I'm more interesting in the receiving / host side which hasn't closed = any part of it's connection and receives those 3 separate packets (PSH, = PSH+ FIN, RST) PSH flag isn't relevant to the connection lifecycle. Receiving a FIN = means the other side is done and has no more data to send. Receiving a = RST is not normal, but there are lots of buggy network stacks (or sysctl = tuning for busy webservers) which drop the TCB sooner than 2*MSL aka ~4 = minutes timeout rather than waiting. Regards, --=20 -Chuck