On 06/06/2018 07:45 AM, goldsi...@gmx.de wrote:
On 06.06.2018 11:42, R. Diez wrote:
[..]
The trouble is, this changes the connection state (pcb->state) from
ESTABLISHED to FIN_WAIT_1, which then turns quickly into FIN_WAIT_2.
Afterwards, TCP keep-alive does not work anymore, because of this logic
in tcp_slowtmr():
/* Check if KEEPALIVE should be sent */
if (ip_get_option(pcb, SOF_KEEPALIVE) &&
((pcb->state == ESTABLISHED) ||
(pcb->state == CLOSE_WAIT))) {
If I then pull the server's Ethernet cable while the connection is
transferring data, the connection never times out on the client.
I am no TCP/IP expert. Is there an error in my reasoning regarding
half-closed connections? Can TCP keep-alive packets, whatever they are,
still be sent and/or received on half-closed TCP connections?
Half-opened connections should be usable like you did it, yes. I'm not
sure about keepalives though.
Technically, keepalives are just empty ACKs, so that should work.
However, I'm not sure wether tcp keepalive is meant to work on
half-open connections.
In order to move from ESTABLISHED to FIN_WAIT_1 and ultimately
FIN_WAIT_2, your application would have had to shutdown the TX pathway
(either a call to shutdown() or close()). In this scenario, TCP can no
longer send data packets, so you couldn't detect a half-open connection
by sending data. Since the connection is in a receive only state, either
a FIN_WAIT_2 timeout or TCP keepalives with no data could be used.
I believe keepalives are used in this case, I found some evidence with a
quick google. A more exhaustive study of other stacks would be a good
to confirm this behavior.
https://stackoverflow.com/questions/18110239/does-tcp-endpoint-that-has-sent-a-fin-still-send-keepalive
https://social.msdn.microsoft.com/Forums/en-US/d20e5e67-d23c-42a5-95c5-ba80f4263546/keepalive-packets-continue-being-sent-after-client-closes-server-socket-is-closewait-client
Here's some findings on a FIN_WAIT_2 timeout:
https://serverfault.com/questions/738300/why-are-connections-in-fin-wait2-state-not-closed-by-the-linux-kernel
https://www.akronohio.gov/manual/misc/fin_wait_2.html
I don't believe a FIN_WAIT_2 timeout is implemented in LwIP. I'm also
thinking this issue may not be that common since tcp_alloc would reap
the half-open connection eventually to prevent pcb exhaustion
Joel
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
