buglwIP - A Lightweight TCP/IP stack - Bugs: bug #56397, Assert "tcp_receive: ooseq...


You are not allowed to post comments on this tracker with your current authentication level.

bug #56397: Assert "tcp_receive: ooseq tcplen > rcv_wnd"

Submitter:  David GIRAULT <dgirault>
Submitted:  Mon 27 May 2019 04:01:08 PM UTC
Category:  TCP Severity:  3 - Normal
Item Group:  Crash Error Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
lwIP version:  git head

( Jump to the original submission )

Fri 01 Oct 2021 06:24:56 PM UTC, comment #8: 

That commit did not fix this bug. To be completely honest, I don't know any more why it references this bug. As to backporting it, this is one of the commits I don't feel certain enough about to add it to a stable/bugfix only release.

Simon Goldschmidt <goldsimon>
Project Administrator
Tue 28 Sep 2021 06:19:15 AM UTC, comment #7: 

commit adbc5b5f716d "tcp: tighten up checks for received SYN" mentions this bug, but this bug is still open. Is commit adbc5b5f716d required for v2.1.3?

Axel Lin <axellin>
Project Member
Tue 24 Sep 2019 01:33:48 PM UTC, comment #6: 

See something strange in out-of-sequence segment handling.

Since TCP_OOSEQ_MAX_BYTES & TCP_OOSEQ_MAX_PBUFS are 0 (unlimited) by default, it seems we can store unlimited count of OOS segments in ooseq queue. Right?

This can result in more bytes stored in pcb->ooseq that the rcv_wnd can handle, isn't it?

When the next expected segment is finally received, the following loop should break if current ooseq segment processed have size > rcv_wnd :

while (pcb->ooseq != NULL &&
       pcb->ooseq->tcphdr->seqno == pcb->rcv_nxt)

Does I miss something?

David GIRAULT <dgirault>
Tue 24 Sep 2019 01:12:03 PM UTC, comment #5: 

Hi Simon,

Just got one of our customer got this bug with our new version with more logs. But, because of a typo in added log, I don't get the value for the rcv_wnd. :-/

The only value I got is TCP_TCPLEN(cseg) which is 1460.

Default rcv_wnd is 17520 (12*MSS) at session start. This is during a HTTPS download (using an ALTCP_TLS socket) where records can be up to 16384 bytes (+5 +24).

I'll come back here when I'll get rcv_wnd value...

David GIRAULT <dgirault>
Wed 05 Jun 2019 01:07:58 PM UTC, comment #4: 

That would be great, as I cannot reproduce this either.

BTW: are you using window scaling here? Maybe it has something do to with that...

Simon Goldschmidt <goldsimon>
Project Administrator
Wed 05 Jun 2019 10:13:07 AM UTC, comment #3: 

Sorry, this bug was only in 3 of our customers and I can't reproduce it myself at work.

I may instrument code before the assert to have usefull values in our saved traces sent after reboot but need to wait for the crash occurs again with this new version deployed to impacted customers.

David GIRAULT <dgirault>
Tue 04 Jun 2019 07:07:02 PM UTC, comment #2: 

Hmm, can you reproduce this? If so, could you just add more output? e.g. the values of rcv_wnd and TCP_TCPLEN(cseg). Maybe it's an off-by-one (due to SYN/FIN) or some kind of overflow?

Simon Goldschmidt <goldsimon>
Project Administrator
Tue 28 May 2019 12:08:37 PM UTC, comment #1: 

May be related to bug #29080, fixed by cf0b8319.

This commit should prevent having TCP_TCPLEN(cseg) > pcb->rcv_wnd isn't it?

David GIRAULT <dgirault>
Mon 27 May 2019 04:01:08 PM UTC, original submission:  

I'm just got the following LWIP_ASSERT() at tcp_in.c:1582 (current master: b3a93941).

The related code is the same than in STABLE-2_1_x branch.

        /* We now check if we have segments on the ->ooseq queue that
           are now in sequence. */
        while (pcb->ooseq != NULL &&
               pcb->ooseq->tcphdr->seqno == pcb->rcv_nxt) {

          struct tcp_seg *cseg = pcb->ooseq;
          seqno = pcb->ooseq->tcphdr->seqno;

          pcb->rcv_nxt += TCP_TCPLEN(cseg);
          LWIP_ASSERT("tcp_receive: ooseq tcplen > rcv_wnd\n",
                      pcb->rcv_wnd >= TCP_TCPLEN(cseg));
          pcb->rcv_wnd -= TCP_TCPLEN(cseg);

I cannot do capture since this bug had appeared once in-field to one of our customers.

David GIRAULT <dgirault>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by axellin (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by dgirault (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.




    No changes have been made to this item

    Back to the top

    Powered by Savane 3.9