RE: [lwip-users] RE: lwIP TCP Dup Ack problem

[Ramanathan Ramadass]

Not necessarily. If I am reading the code right, the condition in
"tcp_output()" is;

if(pcb->flags & TF_ACK_NOW &&
        (seg == NULL ||
   ....)

Where "seg" is the "pcb->unsent" queue. Because the data is flowing one
way (from client to lwIP) "pcb->unsent" will be NULL and will result in a
Dup ACK. I think this is a bug.

Regards
Ram

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Kieran Mansley
Sent: Friday, August 03, 2007 12:51 AM
To: Mailing list for lwIP users
Subject: RE: [lwip-users] RE: lwIP TCP Dup Ack problem

On Thu, 2007-08-02 at 13:49 -0700, Ramanathan Ramadass wrote:
> I think I figured out why the Dup ACK is happening but a soln. has to be
> well tested. Here is the explanation;
> 
> "tcp_recved()" is called on receipt of a packet (in TCP_EVENT_RECV)
which
> sets the TF_DELAY_ACK flag on the pcb through "tcp_ack()". When the tcp
> fast timer fires and since TF_DELAY_ACK is set, "tcp_output()" is called
> through "tcp_ack_now()". This then sends an empty ACK if the TF_ACK_NOW
> flag is set AND either there is no data to send or the window does not
> allow it (there is an helpful comment in tcp_output() explaining this).
> This results in the Dup ACK.

Hmm, I wondered about that, but it should result in the second ACK
having a different advertised window in it (i.e. it would be a window
update rather than a duplicate ACK) which if I remember rightly the
trace you sent didn't show.

Kieran



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users