From owner-freebsd-net@freebsd.org Wed Mar 15 19:36:23 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 B6274D0EEAE for ; Wed, 15 Mar 2017 19:36:23 +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 8C4CEF0D for ; Wed, 15 Mar 2017 19:36:23 +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 v2FJaMgr051521 for ; Wed, 15 Mar 2017 19:36:23 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: Wed, 15 Mar 2017 19:36:23 +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: Wed, 15 Mar 2017 19:36:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #12 from Michael Tuexen --- I did some testing and can explain some of the aspects of the traces, especially the ones on the FreeBSD side. The client establishes the TCP connection and send the first fragment of the HTTP request. The server receives this, sends a response which acknowledges= the first fragment and closes the socket. This results in sending the FIN-ACK. = This is covered in Frame 3 to Frame 8 of the server.pcap file. This looks OK. Now the server receives the second fragment of the HTTP request and responds correctly with a RST segment. This gets dropped by some middlebox and is not received by the client. This is Frame 9 and 10. The client does not have processed the response from the server. I have no = idea why. This response also ACKs the first fragment of the HTTP request. Since = it was not processed, the client retransmits the complete HTTP request in Frame 11. When the server gets this TCP ACK segment, it finds a listening socket and verifies that the segment is a valid SYN-cookie. Therefore it establishes a= new connection, moves it into ESTABLISHED and processes the data. It sends an e= rror message and closes the socket which results in the sending of the FIN-ACK segment. This explains Frame 12 and Frame 13. The peer processes these two segments and sends corresponding ACK-segments = in Frame 14 and 15. I guess the client also closes the socket which results in= the sending of the FIN-ACK in Frame 16. The server ACKs it in Frame 17. However, this ACK is not processed by the client, therefore the client retransmits its FIN-ACK, which the server ACK again. This is Frame 18 an 19. Since the ACK from the server is never processed, this pattern repeats until the client finally gives up. What I do not understand: Why does the client not process the packets it doesn't process. The client.pcap shows that they are received. The sequence numbers look OK to me. However, the client side is not FreeBSD. So at least the above explains the FreeBSD behaviour. --=20 You are receiving this mail because: You are the assignee for the bug.=