Wireshark mailing list archives

Re: Dup ACK #1


From: Martin Visser <martinvisser99 () gmail com>
Date: Wed, 14 Apr 2010 10:19:44 +1000

Vincent,

It is likely to be a congestion recovery mechanism (TCP fast recovery). I
don't see any Window size change. Are only some packets Dup ACKs?

A port-mirror or other capturing issue would show as all packets from one
end being duplicated. Also if you open the IP header you should see unique
IP identifier which would prove they are unique packets generated by the
workstation.

You haven't indicated whether you actually a problem to solve, or whether it
is just something of interest in the capture that you see.


Regards, Martin

MartinVisser99 () gmail com


On Wed, Apr 14, 2010 at 2:52 AM, vincent paul <amoteluro () yahoo com> wrote:

Hi Martin,
How are you?
Please find attached some traces showing the DUP ACK  # 1(immediately from
user's side only).  Could you please educate what is/are potential
problem(s):
1) congestion ???  How can we explain these immediate ACKs from TCP
protocol implementation/requirements?
2) Could it be "mirror port problem"?
But we captured traffic using wireshark on customers' workstations, already
connected to their network.  This meant they did not prepare a port span
connection for us to run test and capture with wireshark.

I greatly appreciate your help and expertise.

Regards,
PV
--- On *Wed, 3/31/10, Martin Visser <martinvisser99 () gmail com>* wrote:


From: Martin Visser <martinvisser99 () gmail com>
Subject: Re: [Wireshark-users] Dup ACK #1
To: "Community support list for Wireshark" <wireshark-users () wireshark org>
Date: Wednesday, March 31, 2010, 6:40 PM

Vincent,

You indicated that you are trying to "understand any problem when a
customer using our application across Internet.". You need to describe more
clearly what the problem you are seeing is for us to be able to help. Is it
unreliable (not connecting/disconnecting) or slower throughput than
expected, or some other error reported by the application or user.

From what you have described it seems like you probably have normal
congestion going on, and TCP is using one of the various mechanisms it has
to recover from it. Without seeing a packet capture (probably you should be
this at client and server end if possible) as well as an understanding of
the network topology (is it LAN/WAN or Internet?) it is pretty hard to
diagnose.

Regards, Martin

MartinVisser99 () gmail com<http://us.mc1114.mail.yahoo.com/mc/compose?to=MartinVisser99 () gmail com>


On Wed, Mar 31, 2010 at 11:15 PM, vincent paul <amoteluro () yahoo 
com<http://us.mc1114.mail.yahoo.com/mc/compose?to=amoteluro () yahoo com>
wrote:

  Hi Martin,

I google around I found one people had the same problem(similar to mine at
server side) with wireshark capture, but there was no resolution.  Please
take a look and give some thought.


http://episteme.arstechnica.com/eve/forums/a/tpc/f/469092836/m/675009277831

regards,
PV


--- On *Wed, 3/31/10, Martin Visser <martinvisser99 () gmail 
com<http://us.mc1114.mail.yahoo.com/mc/compose?to=martinvisser99 () gmail com>
* wrote:


From: Martin Visser <martinvisser99 () gmail com<http://us.mc1114.mail.yahoo.com/mc/compose?to=martinvisser99 () 
gmail com>

Subject: Re: [Wireshark-users] Dup ACK #1
To: "Community support list for Wireshark" <wireshark-users () wireshark 
org<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users () wireshark org>

Date: Wednesday, March 31, 2010, 1:37 AM

  Duplicate ACKs are pretty common when you have congested network. If
the client is expecting more data and doesn't receive it in time 9maybe
250ms) then it will send another ACK in the hope that the data it is
missing/waiting on will be resent.

You haven't indicated what problem you are chasing. If you send a small
sample capture that would be useful.

Regards, Martin

MartinVisser99 () gmail com<http://us.mc1114.mail.yahoo.com/mc/compose?to=MartinVisser99 () gmail com>


On Wed, Mar 31, 2010 at 3:58 PM, vincent paul <amoteluro () yahoo 
com<http://us.mc1114.mail.yahoo.com/mc/compose?to=amoteluro () yahoo com>
wrote:

  Hi All ,

I looked at two traces captured at user's side: one going thru proxy and
one bypassing proxy and observed a lot of Dup ACK #1.  Both traces are
traffic of HTTP download's file from server.  I have the following
observations and could not find any explanation

1)Traffic going thru proxy:  User always sent double ACKs (one ACK(len=0)
and  its Dup ACK #1(len=0) immediately). No Dup ACK problem from server side

2)Traffic bypassing proxy: server, most of the time, sent out double ACK
(ACK(len>0) and its Dup ACK #1 (len=0)) with a time period.  This means:

Server---> user: seq=1000 Ack=210 len= 1460
Server----> user (dup Ack #1) seq=2460, Ack =210 len=0
.
.
.
Normal TCP data transfer from server for a while(kind of frequency) ,
then Server sends out double Acks again.
But there were also some time intervals, the data transfer from server
looked normal without any double Acks from server

In this case, no Dup Ack problem from user's side.

I appreciate your help very much.

regards,
PV





___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark 
org<http://us.mc1114.mail.yahoo.com/mc/compose?to=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<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users-request () wireshark org>
?subject=unsubscribe



-----Inline Attachment Follows-----



___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark 
org<http://us.mc1114.mail.yahoo.com/mc/compose?to=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<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users-request () wireshark org>
?subject=unsubscribe




___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark 
org<http://us.mc1114.mail.yahoo.com/mc/compose?to=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<http://us.mc1114.mail.yahoo.com/mc/compose?to=wireshark-users-request () wireshark org>
?subject=unsubscribe



-----Inline Attachment Follows-----

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark 
org<http://us.mc1114.mail.yahoo.com/mc/compose?to=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<http://us.mc1114.mail.yahoo.com/mc/compose?to=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

___________________________________________________________________________
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: