buglwIP - A Lightweight TCP/IP stack - Bugs: bug #45109, recv() with flags=MSG_PEEK...

 
 

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

bug #45109: recv() with flags=MSG_PEEK consumes data

Submitter:  Christopher Pow <cpow>
Submitted:  Fri 15 May 2015 01:16:54 PM UTC
Votes: 50
 
Category:  sockets/netconn Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Works For Me
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  git head

Jump to the original submission

Sat 05 Mar 2016 10:23:08 AM UTC, comment #14: 

No response. Works for me. I'll reopen it if we get more input to see if there is really a bug.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 30 Sep 2015 07:17:45 PM UTC, comment #13: 


> We don't have MSG_PEEK defined anywhere else in our source base.


I wouldn't have thought you had. But can you provide any more input on what should be wrong? Whether it was UDP or TCP, or anything else that might help to see what the problem is? All the tests I did showed that MSG_PEEK was working correctly.

Simon Goldschmidt <goldsimon>
Group administrator
Wed 30 Sep 2015 01:32:16 PM UTC, comment #12: 

We don't have MSG_PEEK defined anywhere else in our source base.

Christopher Pow <cpow>
Wed 30 Sep 2015 11:38:00 AM UTC, comment #11: 


> The issue turns out to be the value of MSG_PEEK is different in bits/socket.h vs lwip/sockets.h


Your issue or the OP's problem? Christopher, can you say anything about this?

Simon Goldschmidt <goldsimon>
Group administrator
Tue 29 Sep 2015 06:28:53 PM UTC, comment #10: 

Indeed. MSG_* bit value are system-specific. You have to ensure only lwIP includes are used.

Sylvain Rochet <gradator>
Group Member
Tue 29 Sep 2015 06:06:53 PM UTC, comment #9: 

The issue turns out to be the value of MSG_PEEK is different in bits/socket.h vs lwip/sockets.h.

Mohan Mangalaraj <mohans>
Tue 29 Sep 2015 09:10:46 AM UTC, comment #8: 

Or not… now that I remember I understood the question this way: "Is #45827 fixing my problem ? Do you have the patch for #45827 ?". I only answered the second part.

Sylvain Rochet <gradator>
Group Member
Tue 29 Sep 2015 08:57:56 AM UTC, comment #7: 

Indeed, that was for #45827, sorry :-)

Sylvain Rochet <gradator>
Group Member
Tue 29 Sep 2015 08:51:36 AM UTC, comment #6: 


> I guess it is commit 204bd29e52.


Was that an answer to Mohan's question in bug #45827? Because I failed to understand the question in comment #4 here...

Maybe I should again point out that I have not yet found a bug that MSG_PEEK would consume data.

I will close this bug as invalid if the OP (or anyone else) can't provide more input on what should be wrong.

Simon Goldschmidt <goldsimon>
Group administrator
Tue 29 Sep 2015 08:41:22 AM UTC, comment #5: 

I guess it is commit 204bd29e52.

Sylvain Rochet <gradator>
Group Member
Tue 29 Sep 2015 12:04:56 AM UTC, comment #4: 


> PEEK works for me (keeping the window-update bug aside I introduced in 2010).


Does it work without the patch for windows-update bug? If so, do you have a patch for this issue on lwip 1.4.1? Thanks

Mohan Mangalaraj <mohans>
Thu 10 Sep 2015 07:06:41 PM UTC, comment #3: 

Christopher, do you have any input on this? Any hint on how to trigger the misbehaviour?

Simon Goldschmidt <goldsimon>
Group administrator
Tue 25 Aug 2015 08:25:15 PM UTC, comment #2: 


> Seems like this got broken back in 2008


Seems like I was wrong with that comment. I cannot reproduce the problem: PEEK works for me (keeping the window-update bug aside I introduced in 2010).

Is it TCP or UDP where you found the problem?

Simon Goldschmidt <goldsimon>
Group administrator
Mon 18 May 2015 07:21:02 PM UTC, comment #1: 

Seems like this got broken back in 2008 when fixing bug #25051, which seemed to just drop the fact that PEEK means data should not be marked as received.

--> Seems to be still broken in master

Simon Goldschmidt <goldsimon>
Group administrator
Fri 15 May 2015 01:16:54 PM UTC, original submission:  

I have a user report that suggests the implementation of MSG_PEEK is not quite correct.

The data is being returned [as outlined in the second note in comment #4 of https://savannah.nongnu.org/patch/?5049].

But subsequent calls to recv without MSG_PEEK do not return the same data.

It is as though recv() is consuming the receivable data even if flags=MSG_PEEK.

Christopher Pow <cpow>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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 gradator (Posted a comment)
  • -email is unavailable- added by mohans (Posted a comment)
  • -email is unavailable- added by landersson (Voted in favor of this item)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by cpow (Submitted the item)
  •  

    There are 50 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-05 goldsimon Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2015-08-25 goldsimon StatusConfirmed Works For Me
        Planned Release1.5.0
    2015-08-19 goldsimon Planned Release 1.5.0
    2015-05-27 landersson Carbon-Copy- Added landersson
    2015-05-18 goldsimon StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code