Hi Zach,
I have seen a TCP stack get confused about TCP Sequence numbers,
cruising along fine for hours (long-lived connections) and then
suddenly incrementing TCP ACK not by a few hundred bytes, as one
would expect by the size of the TCP payload in the previous frame,
but by ~1.2GB, in the example I'm reviewing. The two sides of the
TCP connection would get stuck for hours on this one frame, with the
server (buggy TCP stack) eventually terminating the connection.
This went on for at least a year or so ... gradually increasing in
frequency from once every week or two to multiple times per day.
We ended up calling the manufacturer of the TCP stack. Turns out
they had identified and fixed this bug a just few weeks earlier; we
installed the patch, and TCP went back to performing reliable
arithmetic.
So there's one scenario which would result in the behavior you're
seeing -- I expect that there are many others.
hth,
--sk
On 3/20/2012 7:44 AM, Zachary J. Ziemba wrote:
Hi,
Can anyone offer a potential scenario that
would explain why the highlighted packets are occurring in a
stream that they do not appear to correspond to? I’m new to
analyzing network traffic and can’t understand why the
sequence number would transition in such a way mid-connection.
Wireshark lists these packets as Previous Segment
Lost/Retransmission but they appear to be unrelated to the
connection.
Thanks in advance,
Zach
|
