Re: [lwip-users] Duplicate acks

[Kieran Mansley]

On Tue, 2 Mar 2004, Atte Kojo wrote:

> I noticed that every time my lwip gets a packet it sends two ACK pakcets
> for it (I'm using version 0.7.1). After some inspection I noticed that
> an incoming packet is acknowledged in two different places: first in
> tcp_receive() and then later in tcp_recved(). When looking at
> tcp_recved() I noticed something that looked somewhat suspicioius to me:
>
>   if (!(pcb->flags & TF_ACK_DELAY) &&
>       !(pcb->flags & TF_ACK_NOW)) {
>     tcp_ack(pcb);
>   }
>
> So if there's no ACK flag, the packet is acknowledged. Is this correct
> or am I missing something here?

The second ACK probably differs from the first in that it will contain a
larger advertised window.  It can do this as you've called tcp_recved and
so processed some data and so it is safe to increase the window.

So, what happens is (or should be) something like this:

1) packet delivered, ACK queued for dispatch with next outgoing packet

2) no outgoing packet is sent

3) TCP's slow timer times out, notices there is a delayed ACK waiting, and
sends it.  This is the first ACK you see.

4) The received packet is processed by your application, which calls
tcp_recved.  This increases the available window, so sends a window
update ACK.  (ie. The acknowledged seqno is the same as the previous one,
but it has a larger advertised receive window).


The reason for the check against TF_ACK_DELAY and TF_ACK_NOW, is that if
an ACK is already pending then we do not need to send a special one to
inflate the window.  If none is pending then we do.

The reason for the window inflation ACK at all, is that the other side
might be waiting for space before it sends any more data, and if we don't
tell it that there is more space, the whole connection could stall.

If steps 3) and 4) happened in the other order only one ACK would be sent,
so the root cause of the symptom (if I'm right!) is that you're slow to
process the received data.

If there is data flowing in the opposite direction (so no step 2) you
shouldn't see separate ACK packets, as they should piggyback on the data
stream.

If any of that sounds like it's not what's going on, let us know and I'll
think again!

Kieran