Wireshark mailing list archives

Re: question about TCP flow behavior


From: "Boonie" <newsboonie () gmail com>
Date: Fri, 16 Apr 2010 12:33:24 +0200

Think of it as: I'm ready to receive [the value in the ACK].

Dave

  ----- Original Message ----- 
  From: Boaz Galil 
  To: Community support list for Wireshark 
  Sent: Friday, April 16, 2010 11:55 AM
  Subject: Re: [Wireshark-users] question about TCP flow behavior


  Hi,

  Thanks for the prompt reply. I wasn’t aware that in the calculation of the  “ACK value”  the data is being taken into 
consideration (calculation) as well.  I thought that the ACK will be on the seq number that we have just received 
regardless of the payload/data of that packet.

  Thanks,




  On Fri, Apr 16, 2010 at 12:27 PM, Tal Bar-Or <tbaror () gmail com> wrote:

    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 () gmail com> 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 () wireshark org>
      Archives:    http://www.wireshark.org/lists/wireshark-users
      Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
                  mailto:wireshark-users-request () wireshark org?subject=unsubscribe




    -- 
    Tal Bar-or


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




  -- 
  Boaz.



------------------------------------------------------------------------------


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

Current thread: