If I understand this correctly, then the
client could send the same SEQ number if delayed acknowledgment kicks in
(either every other segment to timer based).
In other words, the client has nothing to
send out but the server is sending the client segments. TCP provides for
delayed acknowledgements so that the client would send out an ACK even if it
had no data to send (which would account for the client’s SEQ value not
increasing).
If I misunderstood the problem, then
please let me know.
-Barry
From:
wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Sheahan, John
Sent: Saturday, April 12, 2008
9:44 AM
To: wireshark-users@xxxxxxxxxxxxx
Subject: [Wireshark-users] Same
SEQ number but different ACKs
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?
