Opened 5 weeks ago

Closed 5 weeks 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.

  1. Create a new socket
  2. Listen for connections
  3. Pass the socket to the subprocess that runs the server. (Not in test case)
  4. The server will then wrap the socket to enable SSL. (Not in test case)
  5. As part of the initialization, the SSL library determines if the socket is connected, by first running `getpeername()`.
  6. 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)

18884.cpp (2.6 KB ) - added by nielx 5 weeks ago.
Test case to reproduce the issue

Download all attachments as: .zip

Change History (3)

by nielx, 5 weeks ago

Attachment: 18884.cpp added

Test case to reproduce the issue

comment:2 by waddlesplash, 5 weeks ago

Milestone: UnscheduledR1/beta5
Resolution: fixed
Status: newclosed

Merged in hrev57702.

Note: See TracTickets for help on using tickets.