Bug 167712
| Summary: | Missing CANT_STR_ASSOC notification with SCTP stream socket. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Jere Leppanen <jere.leppanen> |
| Component: | kernel | Assignee: | Neil Horman <nhorman> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | davem, jbaron, pcfe |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-11-01 20:56:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Also tested in RHEL4 U2beta and kernel-2.6.13-git6+lksctp-tools-1.0.3-1 with identical results. This doesn't appear to be a bug to me. Opening a socket as SOCK_STREAM, indicates to the kernel that this is a connection oriented protocol, and as SUS defines that unconnected sockets which are opened to connection oriented protocols must return -1 as an error code and set errno to ENOTCONN: http://www.opengroup.org/onlinepubs/000095399/toc.htm I realize that the sctp protocol defines a event notification that should be queued to the socket for the user to read, but the POSIX specification really needs to take precedence here. If you need to see these notifications, the connection should be opened as a SEQPACKET type socket. |
Description of problem: An SCTP SOCK_STREAM socket does not deliver an SCTP_CANT_STR_ASSOC notification when a non-blocking connect() fails. Instead, recvmsg() returns -1 with errno = ENOTCONN. With SCTP SOCK_SEQPACKET sockets SCTP_CANT_STR_ASSOC is correctly delivered. Version-Release number of selected component (if applicable): kernel-2.6.9-5.EL How reproducible: Every time. Steps to Reproduce: In step 5, connect to an IP that either does not respond, or responds with an SCTP ABORT. 1. socket(PF_INET, SOCK_STREAM, 0x84 /* IPPROTO_??? */) = 3 2. bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr ("0.0.0.0")}, 16) = 0 3. setsockopt(3, 0x84 /* IPPROTO_SCTP */, 11 /* SCTP_EVENTS */, "\1\1\1 \1\1\1\1\1", 8) = 0 4. fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 5. connect(3, {sa_family=AF_INET, sin_port=htons(10000), sin_addr=inet_addr ("131.228.201.36")}, 16) = -1 EINPROGRESS (Operation now in progress) 6. select(4, [0 3], NULL, NULL, {2147483647, 0}) = 1 (in [3], left {8589934, 588000}) 7. recvmsg(3, 0xbfa86000, MSG_NOSIGNAL) = -1 ENOTCONN (Transport endpoint is not connected) Actual results: All SCTP events are subscribed in step 3. In steps 4 and 5 we do a non-blocking connect. In step 6, we wait in select() for all of the INITs to expire. In step 7, recvmsg() returns -1 with errno = ENOTCONN. Expected results: In step 7, recvmsg() should return an SCTP_CANT_STR_ASSOC notification. Additional info: This is RFC draft non-compliance. The required behaviour is defined in "Sockets API Extensions for Stream Control Transmission Protocol" (draft-ietf-tsvwg- sctpsocket-10.txt). The obvious workaround is to treat recvmsg()=-1 with errno=ENOTCONN as if an SCTP_CANT_STR_ASSOC notification had been received.