ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] Selective ACK ON / OFF does not have any impact ?

From: Vikki Taxdal <vtaxdal@xxxxxxxxx>
Date: Wed, 4 May 2011 00:05:33 -0400
Hi Andi,

You asked

On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@xxxxxxxxx> wrote:
> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission,
> but why no.195 does not do a TCP retransmission of 114229
> (which is the next seq.) but go to 137589 (no 195)instead ?

Frame 195 doesn't retransmit 114229 because 114229 was not lost; it
arrived in frame 124.

The TCP analysis flags are confusing when you first read them.
Wireshark tells us at frame 124 that "TCP Previous segment was lost",
but the previous segment is not 114229 but 112769 (111309 + 1460, from
frame 123).

If you display "ip.src == 10.10.1.58" and put tcp.seq and tcp.len in
your columns you'll see that
the client starts complaining about lost segments at frame 127,
continuing up to193.

And then when you display "ip.src == 125.252.232.170" you can see that
the server sends the lost packets all at once (frames 194-216).

Vikki





=======================================================
On Thu, Apr 28, 2011 at 4:52 PM, Andi Wijaya <stev2711@xxxxxxxxx> wrote:
> Hi Guys,
> I've uploaded the trace file in cloudshark for your reference.
> My interest is what happen on packet no 193-196.
> http://cloudshark.org/captures/bfc1d3359db2

=======================================================
On Thu, Apr 28, 2011 at 4:19 AM, Andi Wijaya <stev2711@xxxxxxxxx> wrote:
> Hi Guys,
> This is my first post, and it's so nice to be able to join this community so please excuse me if I make any mistake.
> I'm doing a capture with SACK ON and with SACK OFF, my understanding is with SACK OFF, the server will have to retransmit the packet from the point of
> packet lost. However what I see is the server does not retransmit the packet at all and just continuing with the rest of the data (please see the TCP
> Trace screenshot attached). While for SACK ON, everything went well as the theory.
>
> SACK OFF: (I removed some column for easier viewing)
> No  Source           Destination      Seq.#   Nxt.Seq.  Ack.#   Info
> 193 10.10.1.58       125.252.232.170    2286            112769  [TCP Dup ACK 125#34] 1069 > 80 [ACK] Seq=2286 Ack=112769 Win=32768 Len=0
> 194 125.252.232.170  10.10.1.58       112769  114229      2286  [TCP Retransmission] [TCP segment of a reassembled PDU]
> 195 10.10.1.58       125.252.232.170    2286            137589  1069 > 80 [ACK] Seq=2286 Ack=137589 Win=32768 Len=0
> 196 125.252.232.170  10.10.1.58       137589  139049   2286 [TCP Retransmission] Continuation or non-HTTP traffic
> 197 10.10.1.58      125.252.232.170 2286 144889 1069 > 80 [ACK] Seq=2286 Ack=144889 Win=32768 Len=0
>
> My question is, packet no.193 is the Dup ACK and no.194 is the TCP retransmission, but why no.195 does not do a TCP retransmission of 114229
> (which is the next seq.) but go to 137589 (no 195)instead ?  Am I missing something here ?  Thanks/