Date: Mon, 24 Jul 2017 22:09:05 +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-qOEw2oQIBG@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 Richard Russo <freebsd@ruka.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd@ruka.org --- Comment #87 from Richard Russo <freebsd@ruka.org> --- Created attachment 184680 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D184680&action= =3Dedit patch to not send acks in this case We've recently started hitting this at WhatsApp as well. I've applied the syncookie patches from CURRENT to 10.3 manually, and it successfully preven= ts this from happening as long as the syncache hasn't overflowed recently or b= een disabled. Unfortunately, if the syncache does overflow, when this case does happen, o= nce the connection is re-opened, the connection states on each peer are out of sync, and each peer will respond to a packet with unreasonable seq/ack data= by sending an empty ack with the current seq/ack; the other peer will find this unreasonable and the resulting packet storms were causing availability problems. I've attached a patch we've been running on a few machines. With this, when= the connections do get into this state, we don't contribute to the packet storm; instead, the connection will end up eventually closing without sending very many packets. I have some complete connection pcaps available (from before patching), and= can share them (after masking IPs and tcp payloads) if they'll be useful. From = the traces I've seen, we're getting many retransmits from the peer (or a middlebox), and also the peer ends the connection soon after opening, by sending a FIN. Our host acks the FIN and also closes with a FIN. After the peer's ack of our FIN, we receive a new ACK that's a retransmit of the orig= inal ACK, and reopen the connection at the connection original SEQ/ACK, while the peer is in TIME_WAIT at the final SEQ/ACK. In the traces I was able to capt= ure, the peers were mobile devices across the world and on high latency links. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217637-2472-qOEw2oQIBG>