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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
