On the Topic of "new connections from a client are rejected until the riot node is reset". That might be valid behavior. RIOT allows per default only a single TCB to be allocated at a time(however this can be changed via a define).

Depending on the order of the incoming packets for the shutdown sequence, the RIOT TCB can enter a state (TIME-WAIT), where it has to wait for remaining packets on the air associated the closed connection (default value is two minutes). Until that time passed the TCB is not allowed to be reused.
For further details see: https://tools.ietf.org/html/rfc793#page-39

In case of a linux system, a new TCB would be allocated and used to accept that new connection.
On RIOT this is not an option. Basically you are forced to wait until the TCB can be reused.

Are you sure that the behavior you are observing it not caused by this waiting period?

On the Topic of "new connections from a client are rejected until the riot node is reset". That might be valid behavior.

Yes I'm sure that this part is expected behavior although it isn't from being stuck in TIME-WAIT. The TIME-WAIT state is never actually reached as that can't happen until after gnrc_tcp_close() is called.

The unexpected part is being unable to call gnrc_tcp_close() due to gnrc_tcp_recv() not giving indication that it has entered CLOSE-WAIT.

I think you're right about the early return. I can fix that but I wanted to wait for confirmation that there's really a bug here before going any further. Maybe everything is fine and I'm just using it wrong. I just can't see any other way that I'm supposed to detect the CLOSE-WAIT state and call gnrc_tcp_close().

I'll take a look into the entire issue next weekend (I want to take a look how CLOSE-WAIT is handled in the internal FSM). After that, I can give you more detailed feedback on the issue.

But it certainly looks like you stumbled upon a bug.

Hi benemorius,

After looking at the current implementation I think you found something there.

As you said the problem is that the caller is blocked in the recv()-call until the next data carrying packet arrives. If this packet doesn't arrive you get the error that your requested timeout. So far so good.
In cases where you read anything from the recv buffer and the last packet contained the FIN-Flag, it makes no sense to wait for new Payload because the connection is terminated already.

I would suggest the following semantics for your fix:
The RFC says that even if the TCB is in the CLOSE-WAIT state, a recv-call must allow to read from the recv-buffer. At first I would check if the TCB is in the CLOSE-WAIT state. If so, try to read Data from the receive buffer(_fsm_call_recv() in gnrc_tcp_fsm.c). If it is not empty (return code > 0, it is the number of read bytes) return this code. In case the buffer was empty, return an appropriate return code.

On the return code: Currently either the number of read bytes or an error code is returned, so using zero to indicate that the connection was closed is fine, although please update the documentation in the header file because it is a small change in the semantics.

Additionally please add something to _fsm_call_recv():
As soon as the data was read from the receive buffer, there is a check to the receive buffer can hold new data >= MMS. If so it sends a Packet to the peer announcing the new free window size. Please add a check that this window update is not sent in CLOSE-WAIT State. I think it doesn't make sense to reopen the receive window because the peer announced that it has nothing to send any more. I can't find anything on this in the RFC but I think prevents unnecessary packets from being sent.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

See #12367