Opened 9 months ago
Closed 9 months ago
#18884 closed bug (fixed)
POSIX sockets: calling recv() on a listen socket should fail as not connected
Reported by: | nielx | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta5 |
Component: | Network & Internet/Stack | Version: | R1/beta4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Background
I was running the unit tests for the netservices2 kit. These tests validate the HTTP code against a HTTP Server. The HTTP server is written in Python, and is spawned as a sub process of the testing library. The tests are repeated twice, once for HTTP, and once as HTTPS. When trying to run the tests currently, the HTTPS tests fail, as the process seems to hang. There is error output from the Python code that shows there is unexpected data from recv()
because the socket should not be connected.
Issue
I _think_ a listen socket can only accept connections, but it cannot be connected itself. Therefore, a recv()
call on such a socket should fail with the ENOTCONN
error.
Reproduction steps
See the attached file. It is a simplified version of the steps our test server and the python code go through.
- Create a new socket
- Listen for connections
- Pass the socket to the subprocess that runs the server. (Not in test case)
- The server will then wrap the socket to enable SSL. (Not in test case)
- As part of the initialization, the SSL library determines if the socket is connected, by first running `getpeername()`.
- If the socket is not connected, it calls `recv()` in non-blocking mode to make sure that there is absolutely no stray data in the buffer, I presume to make sure pre-SSL data is not parsed.
Expected Output
The socket is a listen socket, so it does not have its own connections. Therefore, it is expected that in step 5 (getpeername()
), the system returns ENOTCONN
. Furthermore, in step 6 (recv()
) it should either return ENOTCONN
, or according to the comment in the code, better yet EINVAL
, or actual data if there is anything in the buffer.
Actual Output
When running the test case on Haiku, the actual output for step 5 is as expected (ENOTCONN
). However, in step 6 there is an error EAGAIN
(or B_WOULD_BLOCK
), which is not expected.
Note that when running the test on Linux, recv()
in step 6 returns ENOTCONN
.
Attachments (1)
Change History (3)
by , 9 months ago
comment:2 by , 9 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Merged in hrev57702.
Test case to reproduce the issue