buglwIP - A Lightweight TCP/IP stack - Bugs: bug #25821, lwip_recvfrom failed to reset...

 
 

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

bug #25821: lwip_recvfrom failed to reset sock->rcvevent, communication lost sync totally

Submitted by:  Chen <xchen>
Submitted on:  Wed 11 Mar 2009 01:15:48 PM UTC  
 
Category:  TCP Severity:  3 - Normal
Item Group:  None Status:  Duplicate
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  1.3.0

( Jump to the original submission)

Tue 09 Jan 2018 02:46:18 PM UTC, comment #11:

Read http://www.nongnu.org/lwip/2_0_x/upgrading.html

Dirk Ziegelmeier <dziegel>
Project Administrator
Tue 09 Jan 2018 02:43:26 PM UTC, comment #10:

Hi,
I have upgraded lwIP 1.4.0 to lwIP 2.0.3. After upgrade, I have tested it, but it is giving the error like, netif is not up, old style port? I am not getting what the issue is? Can you please help me to resolve this.

Sahil Bandar <sahilbandar>
Sat 06 Jan 2018 02:30:45 PM UTC, comment #9:

Thank you Simon. I'll upgrade it to lwip2.0.1. If I face any issue in that I'll let you know. Actually I am facing a problem while I am getting response using HTTP/Secure(HTTPS) request. Instead of that if I use HTTP, It works fine. When I traversed source of the lwip, I got the error returning from netconn_recv(). It was similar bug like, kieren mansley explained in thread bug #23559: lwip_recvfrom problem with tcp, Wed 11 Mar 2009 08:05:55 PM IST, comment #9.

Sahil Bandar <sahilbandar>
Fri 05 Jan 2018 08:15:27 PM UTC, comment #8:

In that case, please upgrade to a more recent version, ideally git master for testing. The code base of 1.4.1 is nearly 7 years old, there have been numerous changes and bug fixes since then.

Simon Goldschmidt <goldsimon>
Project Administrator
Fri 05 Jan 2018 07:55:37 AM UTC, comment #7:

Simon,
I am not able to figure out the version of the lwip stack from the source, but in change log, it was mentioned as [CVS Head] and after that STABLE[1.4.0].

Sahil Bandar <sahilbandar>
Fri 05 Jan 2018 07:03:12 AM UTC, comment #6:

Sahil,
This bug is nearly 8 years old. The code has change much since then. It would be important for you to tell which version of lwIP you are using!

Simon Goldschmidt <goldsimon>
Project Administrator
Fri 05 Jan 2018 06:47:14 AM UTC, comment #5:

I am facing the issue while retrieving response which is greater than 4KB. In lwip_recvfrom the netconn_recv is returning the error. Please help me regarding this.

Sahil Bandar <sahilbandar>
Thu 03 Sep 2009 07:16:09 PM UTC, comment #4:

This is to confirm Kieran's accessment. His patch listed in bug 23240 fixed the problem

Chen <xchen>
Mon 30 Mar 2009 11:54:32 AM UTC, comment #3:

I think this is a duplicate of BUG23240. https://savannah.nongnu.org/bugs/?23240

Kieran Mansley <kieranm>
Project Member
Thu 19 Mar 2009 04:02:12 PM UTC, comment #2:

I have just noticed a similar thing. lwip_select() says that there is something to read on a non-blocking socket, but when I do read data, the lwip_recvfrom call blocks while reading from the mbox, waiting for the mutex (I used the windows port for now). And that causes my program to deadlock...

I traced this back and it always happens on heavy traffic conditions (e.g. opening many connections and transferring data over them), when the mbox is full (breakpoint on return ERR_MEM in recv_tcp() in api_msg.c). RCVPLUS events are received by the sockets layer, but there is no data (mbox is empty, but the receive event counter isn't, and lwip_recvfrom performs a blocking read from an empty buffer).

For now, I moved
SYS_ARCH_INC(conn->recv_avail, len);
and
API_EVENT(conn, NETCONN_EVT_RCVPLUS, len);
to just before the return ERR_OK, and the deadlock disappears. But is this correct?

I haven't tested this for UDP, but there seems to be something similar going on there (at the end of recv_udp).

Wim Dumon <wdumon>
Wed 11 Mar 2009 02:23:54 PM UTC, comment #1:

This is very strange behaviour. From looking at the code the only way I can see this happening is if (1) there is a bug in sys_arch_mbox_fetch() that is merging the received buffers together; or (2) the netconn->callback field gets cleared half-way through the connection. I can't see how (2) would happen, so that leaves us with (1) as the most likely.

There is another bug active in this area, and it could have the symptom you describe where rcvevent ends up non-zero when there is no data available:

https://savannah.nongnu.org/bugs/?23240

The way to check if this is the same problem is to see if the sys_mbox_trypost() call in recv_tcp() fails before you see the rcvevent count go wrong.

Kieran Mansley <kieranm>
Project Member
Wed 11 Mar 2009 01:15:48 PM UTC, original submission:

In TCP connection, if many small packets are sent to lwIP, lwip_recvfrom will fail to reset sock->rcvevent to zero after retrieving all the data:

Each incoming TCP packet should raise one rcvevent, and lwip_recvfrom picks up the packet and subtract rcvevent.

If many short packets are sent to lwIP, such as the capture file (extra_recvevent.cap), packets #27--48 are small packets from PC

rcvevent will go up to 16 in my test.

lwip_recvfrom continue to pick up one packet and subtract event count by one for a few times

Then, lwip_recvfrom picks up ALL the remaining packets and sends them back to the main, but it failed to bring sock->rcvevent back to zero

As the result, the next call to lwip_recvfrom will see a non-zero sock->rcvevent but no data to pick up!

lwIP totally lost sync at this point.

Chen <xchen>

 

Attached Files
file #17645:  extra_recvevent.cap added by xchen (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dziegel (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by sahilbandar (Posted a comment)
  • -email is unavailable- added by wdumon (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by xchen (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-03-30 kieranm StatusNone => Duplicate
        Open/ClosedOpen => Closed
    2009-03-11 xchen Attached File- => Added extra_recvevent.cap, #17645

    Back to the top


    Powered by Savane 3.4