tcp: drop data received after a FIN has been processed

[tuexen]

Summary

RFC 9293 describes the handling of data in the CLOSE-WAIT, CLOSING, LAST-ACK, and TIME-WAIT states:
This should not occur since a FIN has been received from the remote side. Ignore the segment text.
Therefore, implement this handling.

[gbe]

Should BBR not also be affected by this change?

[tuexen]

In D44746#1019854, @gbe wrote:

Should BBR not also be affected by this change?

Possibly. But BBR is not kept in sync, it is more deprecated...

[gbe]

In D44746#1019858, @tuexen wrote:

In D44746#1019854, @gbe wrote:

Should BBR not also be affected by this change?

Possibly. But BBR is not kept in sync, it is more deprecated...

As the author the manual pages for both tcp_rack(4) and tcp_bbr(4), should I update the bbr man page and add a deprecation notice somehow?

Since 14.1-RELEASE is approaching, it would be good to have updated documentation, or a complete removal of BBR in place.

[tuexen]

In D44746#1019926, @gbe wrote:

In D44746#1019858, @tuexen wrote:

In D44746#1019854, @gbe wrote:

Should BBR not also be affected by this change?

Possibly. But BBR is not kept in sync, it is more deprecated...

As the author the manual pages for both tcp_rack(4) and tcp_bbr(4), should I update the bbr man page and add a deprecation notice somehow?

Since 14.1-RELEASE is approaching, it would be good to have updated documentation, or a complete removal of BBR in place.

Let me bring this up on the next transport call. We had a plan, but that was interrupted by code changes in the tree.
I the mean time I can double check if BBR also needs a fix for this issue or not. If a fix is needed, I'll include it.

[tuexen]

Same fix for the BBR stack.

[tuexen]

In D44746#1019858, @tuexen wrote:

In D44746#1019854, @gbe wrote:

Should BBR not also be affected by this change?

Possibly. But BBR is not kept in sync, it is more deprecated...

I added the corresponding fix to the BBR stack.

[rrs]

Why are you removing the data after close checks in BBR and Rack. This is not related to getting a FIN (where you may
still be open). The point of that is so that if we have closed after dumping data into the SB, and then the peer sends in
a request (not realizing we have closed yet) to NOT send a RST until after all the data is through. This was useful for
NF since often times Nginx will close() a connection after filling the N requests and finishing dumping data into the sb.
It say has 1Meg in the buffer when it does close().

The peer is unaware of this and then sends in another request.. which without the change causes a RST which is
undesired.

So what does this side of things have to do with receiving a FIN?

[rscheff]

Base stack change looks good.

[tuexen]

Committed in c9cd686bd4a0.