From owner-freebsd-net@FreeBSD.ORG Wed Jan 8 03:07:21 2014 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 01060F1E for ; Wed, 8 Jan 2014 03:07:21 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A85C212DC for ; Wed, 8 Jan 2014 03:07:20 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id f64so215602yha.31 for ; Tue, 07 Jan 2014 19:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=haqp6VtkfZduah72f51B1gBg7kWjAPwqlXYKdpdcGPI=; b=e8Ydgc3GQh3jYCEBuFDljaV7TKTTkGPWY1rsrRYDQUY05CQZFo74Y/sLLtC9wr3qHB rRvclxC/zH/yR+bK6IJn2vLJPpwaNlmAwx1FHyA1xiHgQpxLYcnmEuav4RLp/LusoNte q+xeb0K/7ns0CK4r/RFr2vJwRH+8/3cw9TR5g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=haqp6VtkfZduah72f51B1gBg7kWjAPwqlXYKdpdcGPI=; b=Ee6G2iAtNgA2WNDfip0GvnPF3jq965lEqIiLsWqG1ULgLumUpQQvEN9p78i3T7HXA8 8v/h+Ov01jKFuG38aMQEwT8Ny707np+7hxqP07zObgSBvBRhh0RUuhJ87OxVhxAAFr4v X9vOnYgzKlh2uvtY8z1uWvR8mbw80tSlkObsCdIus0z88JRe2nQgxyotE3Nl+lxnkcGX R5PpXAWemnkPuJmThlcv+7dh362YflCwo1InuLmb0RApfPyJDZDVjveYBdkahEhnCUtT GqHR3pC4+VMyWF+sfrVhti0YvU1qh8SGCUT7tir8Y0g1ZhI/57M2+BcwYnkP0kPWppmz BBwg== X-Gm-Message-State: ALoCoQndyfmORZAOudbYzi0pqBqPpDltkznQlWhR8lhJyhkvoJ49WWq9rd4wG9H8PQ87skelWQIE X-Received: by 10.236.151.41 with SMTP id a29mr84338026yhk.39.1389150439833; Tue, 07 Jan 2014 19:07:19 -0800 (PST) Received: from hackintosh.wemm.org ([2601:9:e80:770:69a1:2b30:eab6:4149]) by mx.google.com with ESMTPSA id d7sm26833177yhd.24.2014.01.07.19.07.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 19:07:16 -0800 (PST) Message-ID: <52CCC0DF.1020007@wemm.org> Date: Tue, 07 Jan 2014 19:07:11 -0800 From: Peter Wemm Organization: World Domination in progress. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mike Tancsa , freebsd-net@freebsd.org, eadler@freebsd.org, rrs@freebsd.org Subject: Re: TCP question: Is this simultaneous close handling broken? References: <52CB3AE9.3030107@wemm.org> <52CC5F2E.5030201@wemm.org> <52CC8246.7080609@wemm.org> <52CC903C.5090706@sentex.net> In-Reply-To: <52CC903C.5090706@sentex.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 03:07:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/7/14, 3:39 PM, Mike Tancsa wrote: > On 1/7/2014 5:40 PM, Peter Wemm wrote: >=20 >> The packet may be dropped without processing the FIN flag. >=20 >> MFC after: never >=20 > Hi, > Are there any potential side effects to this fix ? The original > author said they were not going to MFC due to possible regressions. I > know you probably see more FreeBSD traffic then most at Y!, and so are > very sensitive to this, but thought I would ask for clarification. >=20 > ---Mike Actually, I'm very troubled by that entire chunk of code. This is the actual fix: ------------------------------------------------------------------------ r239672 | rrs | 2012-08-25 02:26:37 -0700 (Sat, 25 Aug 2012) | 12 lines This small change takes care of a race condition that can occur when both sides close at the same time. If that occurs, without this fix the connection enters FIN1 on both sides and they will forever send FIN|ACK at each other until the connection times out. This is because we stopped processing the FIN|ACK and thus did not advance the sequence and so never ACK'd each others FIN. This fix adjusts it so we *do* process the FIN properly and the race goes away ;-) MFC after: 1 month ------------------------------------------------------------------------ It was MFC'ed all the way to stable/6 in Feb 2013. r258821 from the PR does not handle the case where a fin arrives while we= are in a retransmit state ourselves due to packet loss and interferes wit= h the retransmits. r258821 needs to be backed out. I'm not convinced that r239672 is complete, or even entirely correct. For completeness I'm concerned about the by the if (tp->t_flags & TF_SACK_PERMIT) .. goto drop; scenario. Shouldn't the TH_FIN checks be moved so that it looks more like this? @@ -2534,16 +2535,6 @@ } tp->snd_nxt =3D th->th_ack; tp->snd_cwnd =3D tp->t_maxseg; - if ((thflags & TH_FIN) && - (TCPS_HAVERCVDFIN(tp->t_state) =3D=3D 0)) { - /* - * If its a fin we need to process - * it to avoid a race where both - * sides enter FIN-WAIT and send FIN|ACK - * at the same time. - */ - break; - } (void) tcp_output(tp); KASSERT(tp->snd_limited <=3D 2, ("%s: tp->snd_limited too big", @@ -2553,7 +2544,11 @@ (tp->t_dupacks - tp->snd_limited); if (SEQ_GT(onxt, tp->snd_nxt)) tp->snd_nxt =3D onxt; - goto drop; + if ((thflags & TH_FIN) && + (TCPS_HAVERCVDFIN(tp->t_state) =3D=3D 0)) + break; /* respond to incoming FIN */ + else + goto drop; } else if (V_tcp_do_rfc3042) { cc_ack_received(tp, th, CC_DUPACK); u_long oldcwnd =3D tp->snd_cwnd; ie: respond to it as we normally would, but check to see if it's a new FI= N state before discarding it? NetBSD handle this differently. They seem to check to see if it's a genuinely redundant/duplicate segment earlier and leverage it here. It seems like our handling of this is all wrong. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6F= JV UTF-8: for when a ' just won\342\200\231t do. --lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLMwOMACgkQFRKuUnJ3cX9fbACgh2tebjkpETkbd4MAIZCjSFng wOEAn3x8QeIsEoI7W29UXd67FtC/0u3D =kzOO -----END PGP SIGNATURE----- --lnlDPe6q6u8Qe90FEFXPpNMAbTlf7Tclu--