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.
|
Sun 26 Apr 2009 11:24:50 AM UTC, comment #12:
Forgot to update the status: "ready for test", not "in progress"
|
Tue 21 Apr 2009 07:04:32 PM UTC, comment #11:
Anyone had time for testing?
|
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.
|
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.
|
Sun 01 Mar 2009 10:57:20 AM UTC, comment #8:
Reopening this so we don't forget about it :-)
|
Wed 25 Feb 2009 09:04:19 AM UTC, comment #7:
Koen, can you provide a trace based on Simon's example below ?
|
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.
|
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.
|
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 :-) ).
|
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.
|
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
|
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).
|
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.
|