I have been asked to diagnose an issue with a client that is complaining of dropped packets or delays along the network. I've come across some weird behavior and would like some clarification regarding the expect behavior for TCP RST. I have pasted the RAW Sequence and ACK numbers below (ACK is in BOLD). As seen from the four-tuple these are all from different tcp conversations. The Sequence numbers are difference, as one would expect, but the ACK number is the exact same within the entire capture period. These are also from different Source IP addresses. For further context, these RST's are coming after the Client and Server have both sent a [FIN, ACK] in both directions. After which, the [RST] comes into play and then the client sends a number of [TCP Retransmissions]. I personally have never come across this before. Typically I see 0 for the ACK number. My question is, If the RST Flag is the only FLAG set, is it normal behavior to have the same ACK number across multiple streams?
Sequence Number Next Sequence Number Acknowledgment Number Identification Info
260418613 260418613 4294967196 0x034b (843) 443 > 50686 [RST] Seq=260418613 Win=0 Len=0
3644346981 3644346981 4294967196 0xc3ca (50122) 443 > 38598 [RST] Seq=3644346981 Win=0 Len=0
3944270739 3944270739 4294967196 0xd3dc (54236) 443 > 35794 [RST] Seq=3944270739 Win=0 Len=0
3824746242 3824746242 4294967196 0x529e (21150) 443 > 35798 [RST] Seq=3824746242 Win=0 Len=0
1892430094 1892430094 4294967196 0x4615 (17941) 443 > 35814 [RST] Seq=1892430094 Win=0 Len=0
1269827104 1269827104 4294967196 0x9d3e (40254) 443 > 50730 [RST] Seq=1269827104 Win=0 Len=0
8804867 8804867 4294967196 0xd821 (55329) 443 > 35834 [RST] Seq=8804867 Win=0 Len=0
1820382848 1820382848 4294967196 0x0201 (513) 443 > 50746 [RST] Seq=1820382848 Win=0 Len=0