From owner-freebsd-net@freebsd.org Sun Mar 19 18:03:30 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 E92AAD13354 for ; Sun, 19 Mar 2017 18:03:30 +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 C0A6CECB for ; Sun, 19 Mar 2017 18:03:30 +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 v2JI3UWf067780 for ; Sun, 19 Mar 2017 18:03:30 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: Sun, 19 Mar 2017 18:03:30 +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: Sun, 19 Mar 2017 18:03:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #34 from slw@zxy.spb.ru --- (In reply to Michael Tuexen from comment #33) Right, FIN_WAIT_1. > Then the state is FIN-WAIT-1. Then it receives the second part of the req= uest. Since the socket is closed, it responds with a RST segment and moves = the connection to CLOSED. I am don't understund this. CLOSING must be only after got FIN. FIN don't received, data in buffer don't ack, what reasson to CLOSING transition and lost data? I mean resend response and FIN again. "If a socket structure is associated with the file structure, soclose is called, f_data is cleared, and any posted error is returned.=20 soclose Function This function aborts any connections that are pending on the socket (i.e., = that have not yet been accepted by a process), waits for data to be transmitted to the foreign sys= tem, and releases the data structures that are no longer needed. soclose is shown in Figure 15.39." "In general, TCP must still process incoming data, so it calls tcpacked to handle incoming acknowledgements, tcpdata to process data in the segment, and tcpswindow to adjust its sending window size. Once= the input has been processed, tcpfin1 checks to see if it should make a state transition. If the TCBF_RDONE bit is set, a FIN has arrived and so has all = data in the sequence up to the FIN. If the TCPF_FIN bit is cleared, an ACK has arrived for the outgoing FIN. Tcpfin1 uses these two bits to determine whet= her to make a transition to the CLOSING, FINWAIT2, or TIMEWAIT states" --=20 You are receiving this mail because: You are the assignee for the bug.=