[lwip-users] Issue in handling out of sequence segments?

[Kesten, Joerg]

Hi all,

I think there is an issue in tcp_receive when there is out of sequence data 
pending.

What I see happening is this: 
* an OOS  segment is received and stored, an ACK for the last in-sequence data 
received is send (ok)
* data is resend by the peer. This new data segment contains all data, i.e. it 
overlaps with the stored oos segment.
* this is detected and lwip tries to trim the new data to fit before the stored 
oos data (line 1059 in tcp_in.c (version 1.110). IMHO here something goes 
wrong, resulting in an off-by one error -> pcb->ooseq->tcphdr->seqno  is 
smaller than pcb->rcv_nxt afterwards (always by one).
* when checking if the OOS data are now in sequence (line 1114 of the same 
file), this check obviously fails (as pcb->ooseq->tcphdr->seqno is smaller and 
not equal to rcv_nxt)
* now the OOS data sits there forever, blocking pbufs and eventually stalling 
the whole stack as soon as we run out of those.

The two data segments in question are the last ones send on this connection 
(ftp sever closing the connection after an idle timeout), I am using lwip 1.3.0 
(slightly modified, but I did not mess around in the core functions)


If I modify the code by just adding a "-1" to line 1064:
inseg.len = (u16_t)(pcb->ooseq->tcphdr->seqno - seqno) -1;

everything seems to work ok, but I am very hesitant to make this change without 
really understanding the code and possibly implications of this.

Does anyone with further insight have some suggestion how this should be 
handled and/or if this really is a bug or just some misinterpretation by me?

I'd be happy to provide further data if required!
Thanks!
- Jörg