[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] tcp_receive() possible ancient bug

From: address@hidden
Subject: Re: [lwip-devel] tcp_receive() possible ancient bug
Date: Wed, 22 Mar 2017 19:48:55 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

Hmm, I've never questioned that part of the stack :-)
It might be wrong or just correct by coincidence (i.e. could be written clearer). In any case, it's worth a bug entry to not get forgotten.


Am 21.03.2017 um 23:20 schrieb Joel Cunningham:
So I was studying the section of tcp_receive() that handles processing an ACK for 
new data.  What I found strange is that there is logic to check the unsent queue 
and update pcb->snd_buf outside from the check of whether the ACK acknowledge 
new data.  I was expecting this logic to be within the conditional that checks 
ackno is between lastack+1 and snd_nxt

} else if (TCP_SEQ_BETWEEN(ackno, pcb->lastack+1, pcb->snd_nxt)) {
   /* We come here when the ACK acknowledges new data. */
} else {
   /* Out of sequence ACK, didn't really ack anything */

/* We go through the ->unsent list to see if any of the segments
     on the list are acknowledged by the ACK. This may seem
     strange since an "unsent" segment shouldn't be acked. The
     rationale is that lwIP puts all outstanding segments on the
     ->unsent list after a retransmission, so these segments may
     in fact have been sent once. */
pcb->snd_buf += recv_acked;
/* End of ACK for new data processing. */

I dug through the history and this organization goes all the way back to the 
original commit in git.  Is this a bug or is there a reason to run through the 
logic outside of the conditional (which checks for an ACK covering new data)?


lwip-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]