RE: [lwip-devel] tcp_receive(): Wrong tot_len when trsee immingfirst edge

[Edward Kerekes]

Thanks Leon and hello to you TCP guys!

I believe there are excellent "goal oriented" comments right above the 
code fragment that I quoted.  In fact without those comments, I would 
not have known where to begin:

  /* Trimming the first edge is done by pushing the payload
     pointer in the pbuf downwards. This is somewhat tricky since
     we do not want to discard the full contents of the pbuf up to
     the new starting point of the data since we have to keep the
     TCP header which is present in the first pbuf in the chain.

     What is done is really quite a nasty hack: the first pbuf in
     the pbuf chain is pointed to by inseg.p. Since we need to be
     able to deallocate the whole pbuf, we cannot change this
     inseg.p pointer to point to any of the later pbufs in the
     chain. Instead, we point the ->payload pointer in the first
     pbuf to data in one of the later pbufs. We also set the
     inseg.data pointer to point to the right place. This way, the
     ->p pointer will still point to the first pbuf, but the
     ->p->payload pointer will point to data in another pbuf.

     After we are done with adjusting the pbuf pointers we must
     adjust the ->data pointer in the seg and the segment
     length.*/

After re-reading the comment, and looking at the next few lines of 
code, I'm not sure my fix really covers everything...  If someone that
understands the TCP logic could look at the "inseg.dataptr" also:

  } else {
    pbuf_header(inseg.p, -off);
  }
  inseg.dataptr = inseg.p->payload;       *  <------ ????????? */
  inseg.len -= pcb->rcv_nxt - seqno;                    
  inseg.tcphdr->seqno = seqno = pcb->rcv_nxt;
      }
      else{

I don't see inseg.dataptr being used, but if it is that would be an 
issue also.

So, my fix might not handle everything...  I was assuming that one
must traverse the pbuf chain ignoring "payload" pointers of the pbufs
with "len==0".  That is exactly what "netbuf_copy_partial()" does.  
So it appears to fix the problem for my case... 

By the way:
It was fairly easy for me to get this code to execute.  I had a host device
sending a stream of many 6 and 8 byte commands to my lwIP device.
If I stopped my device a few seconds after the connection was established 
(soon after the stream was started),  then waited about 40 seconds and 
did a "go", the "trimming" code would be executed about 50% of the time...

Ed Kerekes