[lwip-devel] [bug #32417] TCP_OVERSIZE seems to have problems with (fast-)retransmission

[Simon Goldschmidt]

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

                 Summary: TCP_OVERSIZE seems to have problems with
(fast-)retransmission
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Do 10 Feb 2011 20:15:45 GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Crash Error
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: CVS Head

    _______________________________________________________

Details:

observed by MK on lwip-devel (09.02.2011):

I am triggering the following assertion from tcp_out.c : 437

#if TCP_OVERSIZE
#if TCP_OVERSIZE_DBGCHECK
   /* check that pcb->unsent_oversize matches last_unsent->unsent_oversize
*/
   LWIP_ASSERT("unsent_oversize mismatch (pcb vs. last_unsent)",
               pcb->unsent_oversize == last_unsent->oversize_left);
#endif /* TCP_OVERSIZE_DBGCHECK */


As far as I can tell, here is what happens before the above gets triggered
- I have one directional flow from sender to receiver
- sender tcp has sent a lot of data (happens on a spurious event)
causing the receiving tcp ' s window to be at full / near full
- there is a network loss. sender tcp goes into fast recovery
- it stays in fast recovery state for a while (keeps getting dupacks)
- finally it gets the next ack and exits fast recovery. All this
happens before tcp timer has a time to fire
- Then a subsequent attempt (not sure if it is the very next attempt
or a few attempts down the line) by application to send more data
triggers the above.

>From what I see, the fast retransmit will do some segment reordering
and put the unacked segment into the unsent queue. While it is doing
this, it is not changing pcb->unsent_oversize. This somehow seems
related to the assertion. But I do not really get that code, it may
not be the problem at all.





    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/