From owner-freebsd-net@freebsd.org Mon Mar 20 16:47:29 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 78ACAD13157 for ; Mon, 20 Mar 2017 16:47:29 +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 688B584C for ; Mon, 20 Mar 2017 16:47:29 +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 v2KGlSOe020850 for ; Mon, 20 Mar 2017 16:47:29 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 16:47:29 +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: tuexen@freebsd.org 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 16:47:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #64 from Michael Tuexen --- (In reply to slw from comment #63) > Accepted RST can cause silent, immediatly closing connection by client. > No acknowledged will be sent to server (in case of serevr responce will be > delivered to client) and server will be retransmit response until also go= t RST. No. The server sends a RST and move the connection to CLOSED. The connectio= n is terminated immediately from the server perspective. > In case of responce not delivered to client responce will be lost and no = chance > to deleivered. > Sending RST is ok in case RST accepted and processed after client sent ACK > so server FIN (FIN, not server data). Need test this on real clients > (Linux, windows, android and iOS). No. This is an ungraceful termination. No need to wait for anything. All pe= ers should handle the RST. > Server can do graceful termination of this TCP connection and no reason to > don't do this (application do gracefull close and only rare combination > of packet loss case this behaviour). No. Incoming user data is lost on the server side. I think the server should notify the peer as soon as possible. Please note that the RST is only sent if the server has to drop user data. If that is not the case, a graceful shutdown will be performed. --=20 You are receiving this mail because: You are the assignee for the bug.=