Wireshark-users: Re: [Wireshark-users] Same SEQ number but different ACKs
From: Jack Jackson <jack@xxxxxxxxxxxxxxx>
Date: Sat, 12 Apr 2008 09:02:02 -0700
At 06:44 AM 4/12/2008, Sheahan, John wrote:

I'm troubleshooting a problem with a 443 connection through a Squid proxy server.
The communication actually goes through but we are seeing RSTs at the end of every conversation after the FIN coming from the proxy server.
After looking at the packets, in the middle of the conversation, I am seeing the client send two packets with the same SEQ number with two different ACK values, at that point, I get a FIN for the duplicate SEQ number yet my client continues to send several more packets with the same SEQ (same as before the FIN) with different ACK values.
It is at that point that the proxy server sends a RST but the ACK value is way too high to match any of the previous SEQ numbers sent by my client.
 
I can understand a retransmission but am I correct in my thinking that I should never have a duplicate SEQ number with a different ACK value?

No, it is perfectly reasonable to have two messages with the same SEQ but different ACK.

A message is sent with SEQ x and ACK y.
A message is received with 50 more bytes of data, but it does not ACK the message just sent.
The ACK timer expires, so the first message is resent.  This time it has the new ACK value of y+50.

Retransmission does not have to involve the exact same message.  It is only important that it contain at least some data starting with the first unacknowledged byte, but it might include less or more data than the original.  I would guess that most TCP stacks would use the current ACK value on a retransmission, since doing anything else is inefficient.