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.
|
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.
|
Wed 30 Sep 2015 01:32:16 PM UTC, comment #12:
We don't have MSG_PEEK defined anywhere else in our source base.
|
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?
|
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.
|
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.
|
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.
|
Tue 29 Sep 2015 08:57:56 AM UTC, comment #7:
Indeed, that was for #45827, sorry :-)
|
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.
|
Tue 29 Sep 2015 08:41:22 AM UTC, comment #5:
I guess it is commit 204bd29e52.
|
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
|
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?
|
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?
|
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
|
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.
|