Unexpected behavior in LAST-ACK state when receiving ACK with incorrect acknowledgment numbers

[s0uthwood]

I found that when the TCP socket is in the LAST-ACK state, smoltcp behaves incorrectly when handling ACK segments whose acknowledgement numbers do not match the expected value:

• If the client sends an ACK larger than the expected acknowledgement number, smoltcp behaves correctly by sending an ACK and then retransmitting the FIN+ACK.
• However, if the client sends an ACK smaller than the expected acknowledgement number, smoltcp immediately replies with a FIN+ACK, instead of first sending an ACK.

This seems to violate the RFC 9293. According to Section 3.10.7.4:

"All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back."

In the LAST-ACK state, only an ACK value that acknowledges the FIN (i.e., ACK equals SND.NXT) is valid. Therefore, in the latter case, it might be expected to discard the segment and respond with an ACK, before retransmitting the FIN+ACK.