On Fri, Apr 04, 2008 at 03:49:03PM -0400, Weninger, Mark wrote:
>
> A screen capture is shown below. Anyone have any ideas? All help will be
> appreciated.
Please don't send screen images to the list, they are very big in size and
are less flexible to troubleshoot than a (small) capturefile showing the
same packets.
As for your screenshot, it looks like you have relative sequence numbers
enabled in the TCP protocol settings. You also created the capture file
in the middle of the tcp session, as there is no three way handshake
visible. Therefor Wireshark starts counting the sequence and acknowledgement
numbering with the first packet seen (seq=0, ack=0 in frame 1).
The real sequence numbers however almost never start at 0, they start
at a random 32 bit value. So actually, the number 4294964496 that you
see is not a high value, it's 2^32 - 2800. This means that host
10.210.214.209 tries to send a chunk of data with length 1294 at relative
position 0 and host 163.194.161.210 acknowledges that it has only received
data up to relative position -2800, thereby asking host 10.210.214.209
to resend data from relative position -2800. But host 10.210.214.209
repeats sending the 1294 bytes from relative position 0 instead of
fulfilling host 163.194.161.210's request to send the 2800 bytes before
that chunk.
It is not entirely clear to me what you mean by the phrase
"When the host application is bounced". If the host application is killed
for some reason, all of it's tcp sockets should close and not be reused
for this communication. A new three way handshake should occur between
the client and the host.
I hope this helps, if not, please send a tracefile showing the full
tcp session, including the three way handshake.
Cheers,
Sake