https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217637
--- Comment #48 from s...@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. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
