Date: Wed, 15 Mar 2017 19:36:23 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 217637] One TCP connection accepted TWO times Message-ID: <bug-217637-2472-TnjBAftmo0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217637-2472@https.bugs.freebsd.org/bugzilla/> References: <bug-217637-2472@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217637 --- Comment #12 from Michael Tuexen <tuexen@freebsd.org> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217637-2472-TnjBAftmo0>