Skip to content

Wait for TCP close handshake to complete before destroying socket (#2112)#2113

Merged
ten9876 merged 1 commit into
mainfrom
aetherclaude/issue-2112
Apr 30, 2026
Merged

Wait for TCP close handshake to complete before destroying socket (#2112)#2113
ten9876 merged 1 commit into
mainfrom
aetherclaude/issue-2112

Conversation

@aethersdr-agent

Copy link
Copy Markdown
Contributor

Summary

Fixes #2112

What was changed

Wait for TCP close handshake to complete before destroying socket (#2112)

Files modified

  • src/core/RadioConnection.cpp
 src/core/RadioConnection.cpp | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Generated by AetherClaude (automated agent for AetherSDR)

)

After disconnectFromHost() sends a TCP FIN, wait up to 2 seconds for
the radio to acknowledge the close. Without this, the socket can be
destroyed while still in FIN_WAIT, causing the OS to send a RST. The
radio interprets the RST as a crash and keeps the session active,
refusing new connections until rebooted.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

@aethersdr-agent aethersdr-agent Bot left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good -- small, focused fix that matches the stated scope.

What it does: After calling disconnectFromHost(), the socket may not have completed the TCP FIN/ACK handshake before the object is destroyed. Adding waitForDisconnected(2000) gives the kernel time to finish the close sequence cleanly instead of sending a RST to the radio.

Review notes:

  • The state re-check (if m_socket->state() != UnconnectedState) before waitForDisconnected is correct -- avoids blocking when the transition already happened synchronously.
  • The 2-second timeout is reasonable and consistent with the existing waitForBytesWritten(500) pattern in gracefulDisconnect().
  • Only touches RadioConnection.cpp -- no scope creep.
  • No null pointer risks: the outer if already guards m_socket.

One thing to be aware of (not blocking): waitForDisconnected() blocks the calling thread. This is fine in the destructor and gracefulDisconnect() paths (which already block with waitForBytesWritten). If disconnectFromRadio() is ever called from a hot UI path in the future, the 2s ceiling could cause a visible hitch -- but that's not how it's used today.

Thanks for the fix, @aethersdr-agent!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Issue #1996 and PR #1997 did not resolve bug - stale sessions are still occurring.

1 participant