From owner-freebsd-net@freebsd.org Mon Mar 20 15:58:57 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 60248D141B2 for ; Mon, 20 Mar 2017 15:58:57 +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 5007512C9 for ; Mon, 20 Mar 2017 15:58:57 +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 v2KFwum9095036 for ; Mon, 20 Mar 2017 15:58:57 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 15:58:57 +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 15:58:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #61 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #60) > Well, the server knows that he has to drop incoming data, since the appli= cation > has closed the socket and there is new data to deliver. I guess we agree = on that. Agree. > The reaction is to let the peer now as soon as possible that something we= nt wrong. > I guess this is what we might no agree upon.=20 > However this is the reason why the server sends a RST without trying to r= etransmit > data he has sent but which has not been acknowledged by the peer. Now server have several task: 1. retransmit his response and (optional) FIN 2. let the peer that something went wrong. I am don't see ideal answer to this. Send RST now may be don't allow to be sure about acknowledged server data. = Not sure. Need some tests: retransmit data, retransmit FIN, send RST+ACK, SEQ=3DFIN.SEQ+1, see reaction from remote: got ACK to data? got ack to FIN? In any cases retransmit is mandatory, by RFC. Some tricks to discard client data may be used here (zero window? silent discard and only SEQ/ACK analize? ACk and discard? send RST+ACK (as you see, RST w/o ACK ignored by client) a= fter client acknowledged server data? --=20 You are receiving this mail because: You are the assignee for the bug.=