[lwip-devel] [bug #28106] duplicate acknowledge for fast retransmit could have not null length

[Oleg Tyshev]

URL:
  <http://savannah.nongnu.org/bugs/?28106>

                 Summary: duplicate acknowledge for fast retransmit could
have not null length
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: olegreen
            Submitted on: Fri 27 Nov 2009 02:47:31 PM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

Last post I have done was for bug with status fixed,
title was not completely correct too.
So I submit new bug.

In new implementation of fast retransmit we have following rules:
/* (From Stevens TCP/IP Illustrated Vol II, p970.) Its only a
 * duplicate ack if:
 * 1) It doesn't ACK new data 
 * 2) length of received packet is zero (i.e. no payload) 
 * 3) the advertised window hasn't changed 
 * 4) There is outstanding unacknowledged data (retransmission timer
running)
 * 5) The ACK is == biggest ACK sequence number so far seen (snd_una)
 */

We check clause 2
"length of received packet is zero (i.e. no payload)"

It means that we should ourself generate zero length ACK for each new segment
in out of sequence queue.
But now we call tcp_ack_now(pcb).
If unsent queue has something, we send non zero length ACK packet.

Actually in RFCs I didn't found mentioning about zero length ACK,
only Stevens.





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?28106>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/