Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Backport v3.5-branch] net: tcp: Send RST reply for unexpected TCP packets #64321

Merged
merged 5 commits into from
Oct 31, 2023

Conversation

zephyrbot
Copy link
Collaborator

@zephyrbot zephyrbot commented Oct 24, 2023

Backport 822a82d~5..822a82d from #64029.

Fixes #63966

Add a helper function which allows to send a RST packet in response to
an unexpected TCP packet, w/o associated connection or net context.

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit a28215d)
Send RST as a reply for unexpected TCP packets in the following
scenarios:
1) Unexpected ACK value received during handshake (connection still open
   on the peer side),
2) Unexpected data packet on a listening port (accepted connection
   closed),
3) SYN received on a closed port.

This allows the other end to detect that the connection is no longer
valid (for example due to reboot) and release the resources.

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit 95d9543)
Add tests which verify that Zephyr's TCP stack replies with RST packet
as expected.

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit 2b601b3)
Add Kconfig option to control TCP RST behavior on connection attempts on
unbound ports. If enabled, TCP stack will reply with RST packet (enabled
by default).

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit 4ea3d24)
The test delegates putting the server socket into listening (i. e.
calling listen() on the socket) to a separate thread, which did have a
chance to run before client attempted to establish TCP connection.

This was not visible before, as we did not reply with RST to a
connection attempt on a closed port, so the connection was eventually
establish after SYN retransmission. But as we do reject such a
connection now with RST, the connection attempt failed. Therefore, a
small delay was added after spawning the server thread, to give it a
chance to configure the server socket.

Additionally, lower the CONFIG_NET_TCP_TIME_WAIT_DELAY value so that TCP
contexts are released earlier, and add a respective delay in the test
teardown function. Not doing so also triggered unneeded SYN
retransmissions, as there were no enough TCP context to accept the
incoming connection, before freeing the resources allocated for the
previous one.

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit 822a82d)
@jhedberg jhedberg merged commit 7ff9164 into v3.5-branch Oct 31, 2023
25 checks passed
@nashif nashif deleted the backport-64029-to-v3.5-branch branch February 13, 2024 14:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Networking area: Serialization area: Thrift Thrift RPC Backport Backport PR and backport failure issues
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants