Date: Mon, 20 Mar 2017 14:17:59 +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-tMVQzaNW9s@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=217637 --- Comment #48 from slw@zxy.spb.ru --- (In reply to Mike Karels from comment #41) > Yes, if new data are received after the close, there is no way to deliver data anywhere. If we ack it, the peer may just keep sending data, the window may go closed, and the peer could probe it forever. The appropriate response is an RST. And the connection can't do anything further, so CLOSED is the correct state. RFC requried to retransmit data until acked. No matter how to application close socket (do you realy mean this retransmit must be depeneds on apllication reading socket? this is strange and irrational). Yes, ack all received data may be not good. Not sure. May be don't ack it before got ACK to FIN? And only after ACKed FIN generate RST+ACK (RST MUST be w/ ACK, w/o correct ACK RST ignored by Linux and Windows, I am check this before. And accepte such RST for live connection by FreeBSD is bug, violate RFC and security issuse). Generated RST before ACKed FIN don't allow to make sure about "All segments preceding and including FIN will be retransmitted until acknowledged." > It seems to me that this situation is an unavoidable flaw of syn cookies. Please, ignore syn cookies here. See only to "last data chunk not acked, FIN lost". -- 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-tMVQzaNW9s>