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