buglwIP - A Lightweight TCP/IP stack - Bugs: bug #23559, lwip_recvfrom problem with tcp

 
 

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

bug #23559: lwip_recvfrom problem with tcp

Submitted by:  Cui hengbin <phant>
Submitted on:  Fri 13 Jun 2008 12:29:34 AM UTC  
 
Category:  sockets/netconn Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

( Jump to the original submission)

Fri 01 May 2009 12:35:50 PM UTC, comment #13: 

Let's resolved this as fixed and re-open if the bug persists.  I think it's well understood so would be surprised if your fix had failed.

Kieran Mansley <kieranm>
Project Member
Sun 26 Apr 2009 11:24:50 AM UTC, comment #12: 

Forgot to update the status: "ready for test", not "in progress"

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 21 Apr 2009 07:04:32 PM UTC, comment #11: 

Anyone had time for testing?

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 15 Apr 2009 09:14:28 PM UTC, comment #10: 

Well spotted, Kieran! I've checked in a modification in that loop: whenever we would exit it with -1 or 0, check if we have received data before and return that. The error code will be created again on the next call to the function.

I hope that solves it, and I'd really appreciate it if you (Cui and Koen) could test if it solves your problems.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 11 Mar 2009 02:35:55 PM UTC, comment #9: 

I think I understand this now.  The problem is as follows:

lwip_recvfrom() has a do {} while; loop.  On entry to this function there is some data in sock->lastdata.  The first time round the loop the data in sock->lastdata is used and copied to the application buffer.  It's got more space in the buffer so it has another go around the loop, but this time sock->lastdata is empty, so it tries to get more data from the layer below by calling netconn_recv().  This returns an error because the other end has closed the connection, and so we return an error.  By returning an error we don't inform the application that we have just delivered some data into its buffer (the first iteration of the loop).

The correct behaviour would I think be to drop out of the loop when we get an error from netconn_recv if we've already copied some data, and finish processing the data we've delivered in the normal way.  This would then assume that the error will be reported to the application next time they call lwip_recvfrom.

Kieran Mansley <kieranm>
Project Member
Sun 01 Mar 2009 10:57:20 AM UTC, comment #8: 

Reopening this so we don't forget about it :-)

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 25 Feb 2009 09:04:19 AM UTC, comment #7: 

Koen, can you provide a trace based on Simon's example below ?

Frédéric Bernon <fbernon>
Project Member
Wed 25 Feb 2009 07:05:46 AM UTC, comment #6: 

Hey Frédéric, we are using the latest release (1.3.0).

The problem happens when the remote peer sends data and immediately after that closes its connection.

Koen Deforche <kdeforche>
Tue 24 Feb 2009 07:50:33 PM UTC, comment #5: 

Can you confirm us which lwIP release you use? I'm not sure, but lost of data at the end of tcp connection was a problem in lwIP 1.2.0, but was fixed in 1.3.0.

Frédéric Bernon <fbernon>
Project Member
Tue 24 Feb 2009 04:47:07 PM UTC, comment #4: 

I have to second this bug and bug-fix. Without this bug-fix we regularly experience data loss at the end of a TCP connection.

If you want, we can provide more information, but I basically agree with the logic of the original submission and had independently fixed the code in the same way as the original submitter (which by itself does not guarantee that it is correct, of course :-) ).

Koen Deforche <kdeforche>
Tue 10 Feb 2009 09:01:33 PM UTC, comment #3: 

Cui, since you did not go into detail on Frédéric's questions and I think Frédéric is right here, I'm closing this as invalid.

Please feel free to correct me.

Here's how I see it with your example:
- 7000 bytes are received
- sock->lastdata points to that netbuf
- 4096 bytes are copied to user memory, sock->lastoffset=4096

- next call to recvfrom
- sock->lastdata is != NULL
- 2904 bytes are copied to user memory,
- sock->lastdata is set to NULL, sock->lastoffset is set to 0

Can't see a problem here.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 14 Jul 2008 11:18:13 PM UTC, comment #2: 

If netconn_recv receive a 7000 bytes ,but lwip_recvfrom user buffer only 4096,In this case when second time socket->lastdata!= NULL ,but has no data when fetching a netbuf with netconn_recv,
it should return the last data(2904) to user.

FYI

Cui hengbin <phant>
Sun 13 Jul 2008 01:39:17 PM UTC, comment #1: 

I'm not sure to understand:

if "socket->lastdata!= NULL", this part of the code (the "if (!buf)..." ) is not called. It is only call when "socket->lastdata==NULL": in this case, we have to fetch a netbuf with netconn_recv. If this last call returns NULL, it could be :

- due to a RCVTIMEO, or
- due to an error.

But in this case, but perhaps I'm wrong, it's not right to return "off" (since no data is returned).

Frédéric Bernon <fbernon>
Project Member
Fri 13 Jun 2008 12:29:34 AM UTC, original submission:  

Hi All:

       when I use lwip_recv with TCP, found lost data sometime.
In lwip_recvfrom's function ,I found problem as follow:

when socket->lastdata!= NULL and has no data in tcp ,it will copy the last data but found no buf from tcp ,it set errno and return 0,so the last data can't receive by appilcation.I think it should return off.

if (!buf) {
        /* We should really do some error checking here. */
        LWIP_DEBUGF(SOCKETS_DEBUG, ("lwip_recvfrom(%d): buf == NULL!\n", s));
        sock_set_errno(sock, (((sock->conn->pcb.ip!=NULL) && (sock->conn->err==ERR_OK))?ETIMEDOUT:err_to_errno(sock->conn->err)));
        return off;//0; changed
      }

FYI.

Cui hengbin <phant>

 

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 kieranm (Posted a comment)
  • -email is unavailable- added by kdeforche (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by phant (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-05-01 kieranm StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2009-04-26 goldsimon StatusIn Progress => Ready For Test
    2009-04-15 goldsimon StatusNone => In Progress
        Assigned toNone => goldsimon
    2009-04-03 kieranm Planned Release => 1.3.1
    2009-03-11 kieranm StatusNeed Info => None
    2009-03-01 goldsimon StatusInvalid => Need Info
        Open/ClosedClosed => Open
    2009-02-10 goldsimon StatusNone => Invalid
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5