[lwip-devel] 1.4.0.rc2 issue/questions

[MK]

Hi all,

I am a new lwip user and have started using 1.4.0.rc2 (havent used
previous releases). I want to report one possible issue and two
questions

My settings are TCP_OVERSIZE=TCP_MSS and I am using raw api

------------------------------------------------------
(A)
------------------------------------------------------
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.

------------
(B)
-------------
 What is lwip's behavior for resegmenting tcp data? Initially, when
application gives it new data, it will get segmented and sent. Will
these segment boundaries always be preserved on subsequent retransmits
etc or will there be some resegmentation?

------------
(C)
------------
For tcp_seg, is the dataptr in it pointing to the beginning of the tcp
data or to the beginning of the options at the end of the tcp header?
I think there is a discrepancy - For TCP_WRITE_FLAG_COPY in tcp_write,
it gets set via tcp_create_segment and is set to the beginning of the
options, for other cases, it is set similarly, but later adjusted to
point to the beginning of the data - line 593 -

   /* Fix dataptr for the nocopy case */
   if ((apiflags & TCP_WRITE_FLAG_COPY) == 0) {
     seg->dataptr = (u8_t*)arg + pos;
   }




Thanks for your help :)