Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] question about TCP flow behavior

From: Yao Kuang Lai <yaokuang.lai@xxxxxxxxxxxx>
Date: Fri, 16 Apr 2010 07:10:13 -0400

Sent from my HTC Tilt™ 2, a Windows® phone from AT&T

________________________________
From: Tal Bar-Or <tbaror@xxxxxxxxx>
Sent: Friday, April 16, 2010 4:31 AM
To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-users] question about TCP flow behavior

Hi Boaz,

For My opinion that's mean that's HOST B sends data while HOST A receive it and the ACK is calculated (incremented) with the amount of data payload size.
btw i would disable relative seq for TCP  only if iwould do capture from both side to compare seq ACK.

Regards
Tal,

On Fri, Apr 16, 2010 at 12:12 PM, Boaz Galil <boaz20@xxxxxxxxx<mailto:boaz20@xxxxxxxxx>> wrote:
Dear Experts,

I am trying to review a TCP flow using wire shark (I have removed the “relative seq for TCP”).
My questions are this:
During the TCP flow I see the following:
Server A sends Server B [PSH,ACK] seq=1058555096 ACK=2917173962
Server B sends Server A [ACK] seq=2917173962 ACK=1058555108
Server A sends Server B [PSH,ACK] seq=1058555108, ACK=2917173962
Server B sends Server A [ACK] seq=2917173962 ACK=1058556516
And so on, so Server B always sends ACK on a sequence with higher number…
Does anyone know what the explanation of this behavior is? Is this a normal TCP flow behavior?

Please don’t hesitate to contact me if you have any questions or comments.
Thanks in advance,

Boaz Galil


--
Boaz.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx<mailto:wireshark-users@xxxxxxxxxxxxx>>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx<mailto:wireshark-users-request@xxxxxxxxxxxxx>?subject=unsubscribe



--
Tal Bar-or