TCP connection sends an incorrect seqnum FIN message #96087
Description
Describe the bug
When CJSON data is transmitted via an http connection, the message's seq = 18, ack = 689, and len = 255. The client sends a FIN ACK message with seq = 689 and ack = 273, indicating that the message has been received.
However, the server which uses the zephyr system replied with a FIN | ACK message of seq = 528 and ack = 690.
Through debugging, it was found that in the TCP_ESTABLISHED state in the function tcp_in(struct tcp *conn, struct net_pkt *pkt), if the message received from the client contains the FIN flag like above, the if (FL(&fl, &, FIN, th_seq(th) == conn->ack)) branch in line 3148 will be run.
At this point (net_tcp_seq_cmp(th_ack(th), conn->seq) > 0) == TRUE, and len_acked is calculated. Then a FIN | ACK message is sent out via tcp_out(), which will change the seqnum = conn->seq + conn->unacked_len and result in above situation. Because now the conn->seq is added len_acked in line 3165, which is 273. And the conn->unacked_len is not executed conn->unacked_len -= len_acked.
Therefore, in line 3163, perhaps a processing is needed for conn->send_data_total and conn->unacked_len like in line 3249:
conn->send_data_total -= len_acked
if (conn->unacked_len < len_acked) {
conn->unacked_len = 0;
} else {
conn->unacked_len -= len_acked;
}
Regression
- This is a regression.
Steps to reproduce
Reproduce by making a tcp connection as a server.
If there is no reproduction, please inform me in time, because I implemented only updating the tcp protocol stack from the old version through the tcp.c log. So there might be an error, and your handling of conn->unacked_len is elsewhere, not in the tcp.c log
Relevant log output
Impact
Annoyance – Minor irritation; no significant impact on usability or functionality.
Environment
Linux
Additional Context
No response