buglwIP - A Lightweight TCP/IP stack - Bugs: bug #51505, select and sock->rcvevent

 
 

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

bug #51505: select and sock->rcvevent

Submitted by:  Oleg Tyshev <olegreen>
Submitted on:  Wed 19 Jul 2017 10:18:01 AM UTC  
 
Category: sockets/netconnSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Invalid
Privacy: PublicAssigned to: Joel Cunningham <jcunningham>
Open/Closed: ClosedPlanned Release: None
lwIP version: git head

Wed 19 Jul 2017 05:25:17 PM UTC, comment #2:

No, I don't have running pure lwip stack.
I have tried to review socket layer.

You are right, the code will work without any error.
At first I thought that error can happen wenn chain of pbuf will be inserted into recv mbox,
but with lastdata variable this case processed correctly too.

Joel, please, close this issue.

Oleg Tyshev <olegreen>
Wed 19 Jul 2017 02:08:48 PM UTC, comment #1:

Did you find an issue through testing or was this looking at the code?

The rcvevent is not a byte counter but instead is incremented/decremented for each pbuf stored in the netconn's recvmbox.

> lwip_selscan() code has patch trying to fix this behaviour -
> it is checked not only rcvevent, but lastdata too:
> ((lastdata != NULL) || (sock->rcvevent > 0))


lastdata is used to track a pbuf that was received from the netconn layer but not fully consumed by the caller of recv(). So if the last pbuf from recvmbox is only partially read, rcvevent will be at 0, but lastdata will be non-NULL and select should return the socket as readable.

> recv() to receive 100 bytes called:
> 100 bytes received
> sock->rcvevent is 99,


I think this part is incorrect. Each 1-byte pbuf will be received by the socket layer from the netconn recvmbox via netconn_recv_data(). When that happens, API_EVENT(conn, NETCONN_EVT_RCVMINUS, len); is called for each 1 byte pbuf

Joel Cunningham <jcunningham>
Project MemberIn charge of this item.
Wed 19 Jul 2017 10:18:01 AM UTC, original submission:

select and sock->rcvevent

With receive of each data portion will be

recv_tcp() callback function called.
API_EVENT(conn, NETCONN_EVT_RCVPLUS, len);

API_EVENT(conn, NETCONN_EVT_RCVPLUS, len) is expanded to event_callback()
and hier will be following code executed:
sock->rcvevent++;

It doesn't matter how many data is received:
NETCONN_EVT_RCVPLUS -> sock->rcvevent++
NETCONN_EVT_RCVMINUS -> sock->rcvevent--

The comment in lwip_selscan "/* ... then examine it: */"
say that code should be reworked

lwip_selscan() code has patch trying to fix this behaviour -
it is checked not only rcvevent, but lastdata too:
((lastdata != NULL) || (sock->rcvevent > 0))

Error scenario:
100 times 1-byte packet recieved:
sock->rcvevent is 100,

recv() to receive 100 bytes called:
100 bytes received
sock->rcvevent is 99,

select after that returns 99 times readset active, but socket has no data and recv() returns EWOULDBLOCK
It is not correct.
After recv() sock->rcvevent should be 0

Oleg Tyshev <olegreen>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jcunningham (Posted a comment)
  • -unavailable- added by olegreen (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 19 Jul 2017 06:26:00 PM UTCjcunninghamStatusNone=>Invalid
      Assigned toNone=>jcunningham
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1