connect_timeout returns `Ok(())` on macOS but socket is not connected
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 870
- Forks
- 305
- PR merge metrics
- No merged PRs in 30d
Description
I am observing a case on macOS where connect_timeout returns Ok(()) but the socket is not actually connected: peer_addr() (getpeername) immediately returns ENOTCONN.
Minimal reproducer:
use socket2::{Domain, Protocol, SockAddr, Socket, Type};
use std::{net::SocketAddr, time::Duration};
fn main() {
let remote_addr = "[<remote-ipv6>]:443"
.parse::<SocketAddr>()
.unwrap();
let socket = Socket::new(Domain::IPV6, Type::STREAM, Some(Protocol::TCP)).unwrap();
socket
.connect_timeout(&SockAddr::from(remote_addr), Duration::from_secs(10))
.unwrap();
println!("connect_timeout returned Ok(())");
println!("peer_addr: {:?}", socket.peer_addr());
}
Output on the affected machine:
Socket connected
Err(Os { code: 57, kind: NotConnected, message: "Socket is not connected" })
Environment
- macOS
15.7.3(aarch64) socket2 0.6.3- IPv6 TCP socket connecting to a remote server
- The machine has a global IPv6 address and a default IPv6 route via the physical interface
- A VPN is active that captures IPv4 traffic (via a utun interface) but does not carry IPv6
In that particular environment, decomposing Socket::connect_timeout step by step the issue is in the fast path (https://github.com/rust-lang/socket2/blob/master/src/socket.rs#L217). The non-blocking connect() call returns Ok(0) instead of Err(EINPROGRESS):
set_nonblocking(true)
connect() → Ok(()) ← should be Err(EINPROGRESS) for a remote TCP address
set_nonblocking(false)
// connect_timeout returns Ok(()) here, poll_connect is never called
This happens consistently (10/10 attempts) on this machine when the VPN is active.
The same network configuration on Linux works correctly: connect() returns EINPROGRESS in both cases (with or without VPN)
There's something I am missing about how connect_timeout should be used?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at src/socket.rs around the fast path near line 217 and reproduce the IPv6 TCP case on macOS with the reported VPN setup. Check how nonblocking connect() results are handled when it returns Ok(()) instead of EINPROGRESS, and compare the behavior with the existing Linux path. Done means connect_timeout does not report success while peer_addr() still returns ENOTCONN.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100