-
Notifications
You must be signed in to change notification settings - Fork 2.1k
gnrc_tcp: return immediatly on gnrc_tcp_recv if a connection is closing #12367
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
gnrc_tcp: return immediatly on gnrc_tcp_recv if a connection is closing #12367
Conversation
Can you give both your commit and the PR a bit more human readable summary? ;-) |
Better now? |
I have changed the test index number to 6 because I think #12369 will be merged before this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes seem valid to me, however: the tests should go into a separate commit and there is a change that seems unrelated in here, which also should go into its own commit.
Needs rebase. You may squash (and separate) while doing so. |
4f2823c
to
dfef54f
Compare
Rebased to current master. To stabilize the tests I had to increase the timeout of the second script. |
@miri64 - Ping due to force push. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks ok, documentation is provided.
Tested on both native
and samr21-xpro
. The test runs a bit flaky on samr21-xpro
(04 is sometimes failing and sometimes also 05), but that is also the case on master
and so far I did not see the newly introduced test suite 6 fail. ACK
dfef54f
to
2c961d3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please fix the commit message to something more human-readable ;-)
2c961d3
to
1eb2969
Compare
Done |
@miri64 - Ping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, nothing changed since I last looked at this PR.
@brummer-simon did you run the tests on non-native boards as well? I'm having issues making them pass on other boards than |
Hi @fjmolinas, The tests run on boards as well via ethos. However some boards are faster than others there might be cases where the Timeout specified in the test scripts is to short. Would you do me a favor and increase the timeout for the failing tests? If this works, would you create a PR? Cheers Simon |
Thanks, I'm not sure what happened, I had a lot of issue making it work, but eventually it did with the default timeout. Thanks! |
This PR fixes the stale Issue mentioned in this PR #10899. I think the original Author abandoned his PR, but the Issue remains till today. To summarize the Issue the behaviour of gnrc_tcp_recv() was not fully in line with the TCP RFC.
Specified Behaviour:
gnrc_tcp_recv() must return immediately if a packet with the FIN Bit set, was received from the peer indicating that want to close a connection. As a response a call to gnrc_tcp_recv() return all queued data up to this point immediately, a given timeout must be ignored because there will be no new data to receive.
Actual Behaviour without this PR:
gnrc_recv() will block even if a packet with the FIN Bit set, was received, if a timeout was given.
Additionally the user of gnrc_tcp has no means to figure out that the peer wants to close the connection.
A more detailed discussion on the Issue can be found in the original PR #10899.