WSAENOTCONN (0X00002749) – Socket Not Connected Fix

You're staring at WSAENOTCONN 0x00002749, and it's frustrating.

I've seen this error more times than I can count. The socket you're trying to use isn't actually connected. You're trying to send or receive data on a connection that's already been closed, or never got established in the first place.

The Fix

Ninety percent of the time, the fix is stupidly simple: reconnect the socket before sending or receiving data. In code, that means calling connect() again, or checking the socket state with getsockopt() before any send/recv call.

If you're using a command-line tool like ftp or curl, the fix is usually a new connection attempt. For example, in Windows FTP:

ftp> open <server> 21

If it's a custom application (yours or third-party), look for where the socket is created and connected. The culprit here is almost always an asynchronous operation – you fire off a send on a socket that was never connected, or the remote end closed the connection and your code didn't handle the disconnect.

Quick check: Use netstat

Open a command prompt as admin and run:

netstat -ano | findstr <your_process_pid>

Look at the state column. If the socket shows CLOSE_WAIT or TIME_WAIT, it's not connected. That's your problem.

Why This Happens

The low-level Winsock error code for WSAENOTCONN is 10057. It means the socket descriptor is valid (you created it with socket()), but it never completed a connection, or the connection dropped. The operating system is saying: “I have no remote endpoint to send this data to.”

Here are the three most common triggers I've seen in 14 years of enterprise IT:

1. Server closes connection unexpectedly – Your code isn't checking for a graceful shutdown. The server sends a FIN packet, your recv returns 0, but you keep sending anyway.
2. Firewall or proxy kills idle connections – A stateful firewall like a Palo Alto or a corporate proxy can drop an idle TCP connection after 5-10 minutes. Your app thinks it's still good. It's not.
3. Asynchronous socket mess – You're using overlapped I/O or WSAAsyncSelect and the connect event hasn't fired yet. You try to send before the connection completes.

Real-world example: A legacy FTP client batch script that ran every night. It would connect, wait 3 minutes processing files, then try to send the next file. The server's idle timeout was 2 minutes. Every night at 2:03 AM, WSAENOTCONN. The fix? A keepalive packet every 30 seconds using the SO_KEEPALIVE socket option.

To enable keepalive in code:

int keepalive = 1;
setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (char*)&keepalive, sizeof(keepalive));

Less Common Variations

Sometimes WSAENOTCONN shows up in unexpected places:

• During SSL handshake – The underlying socket drops before the SSL/TLS handshake completes. Check if the certificate negotiation times out. Increase the handshake timeout.
• With WSAEventSelect – You register for FD_CONNECT, but the event fires after you've already tried to send. Ensure you wait for the event before any send operation.
• In multi-threaded apps – One thread closes the socket while another is trying to send. Bad design. Use a mutex or ref counting on the socket.

If you're using .NET (C#), this can appear as a SocketException with error code 10057. The fix is the same: check socket.Connected property before calling Send(). But be warned – Connected isn't reliable for detecting a remote close. Better to catch the exception and handle it.

In Wireshark, filter with tcp.flags.reset == 1 to see if the remote side sent an RST packet. That's a smoking gun.

Prevention

Don't bother with increasing TCP timeouts – that's a band-aid. The real solution is to make your socket code robust:

• Always check return values from send() and recv(). If recv returns 0 or SOCKET_ERROR, close the socket and don't reuse it.
• Implement a heartbeat or keepalive mechanism. For critical connections, send a small “are you there?” packet every 30 seconds.
• Use error handling that catches WSAENOTCONN specifically and triggers a reconnect loop. Exponential backoff – don't hammer the server with reconnect attempts.
• Test with artificial network conditions. Use tools like Clumsy (Windows) or tc (Linux) to simulate packet drops and timeouts. You'll catch this bug in staging instead of production.

One last thing: if you're using a third-party library, check its documentation. Some libraries (like old versions of libcurl on Windows) have known bugs where they don't properly re-establish connections after a timeout. Upgrading the library fixed it for me twice.