Can TCP seq number increment after sending a FIN?

Question

I have an embedded device connecting to a server (on AWS Application ELB if that matters). Both the server and the client are instructed to close the connection after one request. I noticed that the client took a long time to close the connection even after receiving back the HTTP response from the server. I know it uses a low-powered network with high latency but I still wanted to check if there was something else going on, so I took a tcp dump from both sides.

The screenshot shows the trace from client side. Concentrating at the connection close sequence:

• At packet 13 the client sends an empty FIN packet. There is high network latency so it doesn't get immediately the response back but a retransmission instead (packet 14).
• The client sends another FIN (packet 15) with incremented seq (!!!).
• It happens again at packet 17 with further incremented seq (!!!).

If I understand correctly the TCP state machine this is not a valid behavior. If packet 15 and 17 were retransmissions, they should have been sent with the same exact numbers. In fact, the server never acknowledges the incremented seq numbers.

If necessary I can provide also a screenshot of the dump from server side, but it just shows the same packets in a different order, there is no packet loss.

Note: packet 16 shows relative seq num = 1 but the absolute raw value is correct and the same as packet 14.

Answer 1

As far as I can tell, this is normal behavior. Yes, seq numbers do increment after initiating a FIN.

See the following question for details: https://networkengineering.stackexchange.com/a/47132

And here is the original RFC in case the above link ever breaks in the future: https://www.rfc-editor.org/rfc/rfc793#section-3.5

Answer 2

As @user3629081 indicated, Sequence Number value increases after every FIN (and also after every SYN) - excluding the cases of TCP retransmissions. This results directly from the definitions of these control flags in https://datatracker.ietf.org/doc/html/rfc793#page-79 (GLOSSARY):

FIN

A control bit (finis) occupying one sequence number, which indicates that the sender will send no more data or control occupying sequence space.

SYN

A control bit in the incoming segment, occupying one sequence number, used at the initiation of a connection, to indicate where the sequence numbering will start.

Your case (as well as normal connection termination, as described in https://www.rfc-editor.org/rfc/rfc793#section-3.5) is a direct consequence of the definitions quoted above. Namely, TCP segments 15, 17 are not TCP retransmissions (since 15 is just a another TCP.FIN segment and 17 is TCP.DUP-ACK) and therefore after these frames the Sequence Number is being increased. On the other hand, TCP segment 14 is a TCP retransmission (of 11), and therefore it has the same Sequence Number as 11.