Page MenuHomeFreeBSD

tcp: drop data received after a FIN has been processed
ClosedPublic

Authored by tuexen on Apr 10 2024, 10:30 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, May 27, 2:12 AM
Unknown Object (File)
Sun, May 19, 6:00 AM
Unknown Object (File)
Apr 26 2024, 4:29 PM
Unknown Object (File)
Apr 26 2024, 5:03 AM
Unknown Object (File)
Apr 26 2024, 2:40 AM
Unknown Object (File)
Apr 18 2024, 10:05 PM
Unknown Object (File)
Apr 18 2024, 12:56 AM
Unknown Object (File)
Apr 15 2024, 3:23 PM

Details

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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Should BBR not also be affected by this change?

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...

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.

In D44746#1019926, @gbe 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.

Same fix for the BBR stack.

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 requested changes to this revision.Apr 18 2024, 2:14 PM

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?

This revision now requires changes to proceed.Apr 18 2024, 2:14 PM
This revision is now accepted and ready to land.Apr 18 2024, 3:10 PM

Base stack change looks good.