TCP stack doesn't handle data received in FIN_WAIT_1

[jimparis]

The TCP stack doesn't appear to handle data received in FIN_WAIT_1. What I'm seeing is this, whenever HTTPS connection closes:

It looks like what happens is the client (192.x) and the server (75.x) are both trying to close the connection at the same time. I'm guessing, from the client's point of view, things happen in a slightly different order:

• client sends packet 374 (FIN+ACK, ack=3229)
• client enters FIN_WAIT_1
• client receives packet 372 (23 bytes of data. The bug is that this length is ignored).
• client receives packet 373 (FIN+ACK, seq=3252) but is still expecting seq=3229, so it never answers
• server retransmits until everyone gives up

This seems to fix the problem:

diff --git a/subsys/net/ip/tcp2.c b/subsys/net/ip/tcp2.c
index c6cf60c9a8fe..b8029f8e510b 100644
--- a/subsys/net/ip/tcp2.c
+++ b/subsys/net/ip/tcp2.c
@@ -1777,6 +1777,9 @@ next_state:
                do_close = true;
                break;
        case TCP_FIN_WAIT_1:
+               /* Acknowledge but drop any data */
+               conn_ack(conn, + len);
+
                if (th && FL(&fl, ==, (FIN | ACK), th_seq(th) == conn->ack)) {
                        tcp_send_timer_cancel(conn);
                        conn_ack(conn, + 1);

With that, the packet capture looks great:

[jukkar]

Your fix looks good, can you send a PR for it?

[jukkar]

@jimparis I submitted your patch proposal in order to get this merged to 2.6, please +1 it if ok.