From owner-freebsd-net@freebsd.org Thu Mar 16 12:04:13 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 2D949D0EA92 for ; Thu, 16 Mar 2017 12:04:13 +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 1D7F113B4 for ; Thu, 16 Mar 2017 12:04:13 +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 v2GC4Cxd041873 for ; Thu, 16 Mar 2017 12:04:12 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: Thu, 16 Mar 2017 12:04:13 +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: Thu, 16 Mar 2017 12:04:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #14 from Michael Tuexen --- (In reply to Alexandre martins from comment #13) > I want to remind you that the original client is a smartphone. The first = time that > I saw the problem, I made a tcpdump on the wireless box, not on the > smartphone itself. OK. That explains why the client has not processed TCP segments which were reported as received. They are just dropped between the wireless box and the smartph= one. > The server response may have been delayed into the wifi process (poor sig= nal ?) > and takes time to reach the phone (but has already been captured into the= pcap). > The phone may have done a re-transmit because it thinks that the http req= uest > was lost. I guess this is exactly why the client was retransmitting the complete HTTP request. Please note that the retransmission looks like the third message (an ACK) of the three way handshake. It only contains in addition some data and has the PSH= bit set. Therefore it looks like such a handshake message and the server accepts it = and establishes the TCP connection (again).=20 >I just managed that to reproduce it through the scapy script on the ubuntu= with >a iptables configuration that drops the TCP reset. The packetdrill script allows you to reproduce the double accept behaviour on a FreeBSD head system. I used that to figure out why it happens. --=20 You are receiving this mail because: You are the assignee for the bug.=