From owner-freebsd-net@freebsd.org Mon Mar 20 14:17:59 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83D05D138AE for ; Mon, 20 Mar 2017 14:17:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73AB512DC for ; Mon, 20 Mar 2017 14:17:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v2KEHwKO049269 for ; Mon, 20 Mar 2017 14:17:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Date: Mon, 20 Mar 2017 14:17:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: slw@zxy.spb.ru X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 14:17:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #48 from slw@zxy.spb.ru --- (In reply to Mike Karels from comment #41) > Yes, if new data are received after the close, there is no way to deliver= data anywhere. If we ack it, the peer may just keep sending data, the win= dow may go closed, and the peer could probe it forever. The appropriate res= ponse is an RST. And the connection can't do anything further, so CLOSED is= the correct state. RFC requried to retransmit data until acked. No matter how to application c= lose socket (do you realy mean this retransmit must be depeneds on apllication reading socket? this is strange and irrational). Yes, ack all received data= may be not good. Not sure. May be don't ack it before got ACK to FIN? And only after ACKed FIN generate RST+ACK (RST MUST be w/ ACK, w/o correct ACK RST ignored by Linux and Windows, I am check this before. And accepte such RST = for live connection by FreeBSD is bug, violate RFC and security issuse). Generated RST before ACKed FIN don't allow to make sure about "All segments preceding and including FIN will be retransmitted until acknowledged." > It seems to me that this situation is an unavoidable flaw of syn cookies. Please, ignore syn cookies here. See only to "last data chunk not acked, FIN lost". --=20 You are receiving this mail because: You are the assignee for the bug.=