I got this off a website:
WSAEHOSTUNREACH (10065) No route to host.
Berkeley description: A socket operation was attempted to an unreachable host.
WinSock description: Same as Berkeley. Unlike Berkeley, however, WinSock v1.1 doesn't ascribe this error to any functions. In it's place, WinSock uses the error WSAENETUNREACH, exclusively.
TCP/IP scenario: In BSD-compatible implementations, the local network system generates this error if there isn't a default route configured. Typically, though, WinSock generates WSAENETUNREACH when it receives a "host unreachable" ICMP message from a router instead of WSAEHOSTUNREACH. The ICMP message means that the router can't forward the IP datagram, possibly because it didn't get a response to the ARP request (which might mean the destination host is down).
User suggestions: see WSAENETUNREACH for details
=================
Features FAQ About Forum Known issues Register Home Download
Download now! "Thanks for the super program
and i am using it very often."
- Patrick, Holland
PM is featured on:
Rated 3 stars on Tucows.com
Rated 5/5 on FileTransit.com!
Rated 5/6 on Nonags.com
Editor's Favourite
Featured
Featured
Featured
Editor's Favourite
How you can support Peer Monitor
--------------------------------------------------------------------------------
Update 2005-06-22
Apologies to all who could not access the site in the last few days. My crappy webhosting company decided to just remove the files from the PM folder without telling me, and then took 5 days to restore them. Pricks. Sorry for the trouble.
I need to move to a new hosting company. If you'd like to make a contribution to help with the cost of this new server, please click the PayPal icon in the top right. Thanks. Daniel.
Winsock error codes
0 (WSABASEERR) No Error
10004 (WSAEINTR) Interrupted system call
10009 (WSAEBADF) Bad file number
10013 (WSAEACCES) Permission denied
10014 (WSAEFAULT) Bad address
10022 (WSAEINVAL) Invalid argument
10024 (WSAEMFILE) Too many open files
10035 (WSAEWOULDBLOCK) Operation would block
10036 (WSAEINPROGRESS) Operation now in progress
10037(WSAEALREADY) Operation already in progress
10038 (WSAENOTSOCK) Socket operation on non-socket
10039 (WSAEDESTADDRREQ) Destination address required
10040 (WSAEMSGSIZE) Message too long
10041 (WSAEPROTOTYPE) Protocol wrong type for socket
10042 (WSAENOPROTOOPT) Bad protocol option
10043 (WSAEPROTONOSUPPORT) Protocol not supported
10044 (WSAESOCKTNOSUPPORT) Socket type not supported
10045 (WSAEOPNOTSUPP) Operation not supported on socket
10046 (WSAEPFNOSUPPORT) Protocol family not supported
10047 (WSAEAFNOSUPPORT) Address family not supported by protocol family
10048 (WSAEADDRINUSE) Address already in use
10049 (WSAEADDRNOTAVAIL) Can't assign requested address
10050 (WSAENETDOWN) Network is down
10051 (WSAENETUNREACH) Network is unreachable
10052 (WSAENETRESET) Net dropped connection or reset
10053 (WSAECONNABORTED) Software caused connection abort
10054 (WSAECONNRESET) Connection reset by peer
10055 (WSAENOBUFS) No buffer space available
10056 (WSAEISCONN) Socket is already connected
10057 (WSAENOTCONN) Socket is not connected
10058 (WSAESHUTDOWN) Can't send after socket shutdown
10059 (WSAETOOMANYREFS) Too many references, can't splice
10060 (WSAETIMEDOUT) Connection timed out
10061 (WSAECONNREFUSED) Connection refused
10062 (WSAELOOP) Too many levels of symbolic links
10063 (WSAENAMETOOLONG) File name too long
10064 (WSAEHOSTDOWN) Host is down
10065 (WSAEHOSTUNREACH) No Route to Host
10066 (WSAENOTEMPTY) Directory not empty
10067 (WSAEPROCLIM) Too many processes
10068 (WSAEUSERS) Too many users
10069 (WSAEDQUOT) Disc Quota Exceeded
10070 (WSAESTALE) Stale NFS file handle
10091 (WSASYSNOTREADY) Network SubSystem is unavailable
10092 (WSAVERNOTSUPPORTED) WINSOCK DLL Version out of range
10093 (WSANOTINITIALISED) Successful WSASTARTUP not yet performed
10071 (WSAEREMOTE) Too many levels of remote in path
11001 (WSAHOST_NOT_FOUND) Host not found
11002 (WSATRY_AGAIN) Non-Authoritative Host not found
11003 (WSANO_RECOVERY) Non-Recoverable errors: FORMERR, REFUSED, NOTIMP
11004 (WSANO_DATA or WSANO_ADDRESS) Valid name, no data record of requested type
--------------------------------------------------------------------------------
Error Description List
WSABASEERR (10000) No error
Berkeley Description: no equivalent.
WinSock description: No error.
Detailed description: There's at least one WinSock implementation that will occasionally fail a function and report this as the error value, even though the function succeeded. You should simply ignore this error when it occurs.
--------------------------------------------------------------------------------
WSAEACCES (10013) Permission denied.
Berkeley description: An attempt was made to access a file in a way forbidden by its file access permissions.
Microsoft C description: Permission denied. The file's permission setting does not allow the specified access. This error signifies that an attempt was made to access a file (or, in some cases, a directory) in a way that is incompatible with the file's attributes. For example, the error can occur when an attempt is made to read from a file that is not open, to open an existing read-only file for writing, or to open a directory instead of a file. Under MS-DOS versions 3.0 and later, EACCES may also indicate a locking or sharing violation. The error can also occur in an attempt to rename a file or directory or to remove an existing directory.
WinSock description: Same as Berkeley.
Detailed description:
The requested address is a broadcast address, but the appropriate
flag was not set (i.e. you didn't call setsockopt(SO_BROADCAST)).
--------------------------------------------------------------------------------
WSAEADDRINUSE (10048) Address already in use.
Berkeley description: Only one usage of each address is normally permitted.
WinSock description: Same as Berkeley. The "address" they refer to, typically refers to the local "socket name", which is made up of the 3-tuple: protocol, port-number and IP address.
--------------------------------------------------------------------------------
WSAEADDRNOTAVAIL (10049) Cannot assign requested address.
Berkeley description: Normally results from an attempt to create a socket with an address not on this machine.
WinSock description: Partly the same as Berkeley. The "address" it refers to is the remote socket name (protocol, port and address). This error occurs when the sin_port value is zero in a sockaddr_in structure for or.
In Berkeley, this error also occurs when you are trying to name the local socket (assign local address and port number) with bind(), but Windows Sockets doesn't ascribe this error to bind(), for some unknown reason.
--------------------------------------------------------------------------------
WSAEAFNOSUPPORT (10047) Address family not supported by protocol family.
Berkeley description: An address incompatible with the requested protocol was used. For example, you shouldn't necessarily expect to be able to use NS addresses with ARPA Internet protocols.
WinSock description: Same as Berkeley, and then some. The error occurs with the function, which takes the socket type (protocol) and address family as input parameters.
It also occurs with functions that take a socket handle and a sockaddr structure as input parameters. A socket already has a type (a protocol), and each sockaddr structure has an address family field to define its format. A function fails with WSAEAFNOSUPPORT if the address family referenced in sockaddr is not compatible with the referenced socket's protocol.
This error apparently also takes the place of WSAEPFNOSUPPORT (which means "protocol family not supported"), since that error is not listed for in the v1.1 WinSock specification.
See also: WSAEPROTOTYPE
--------------------------------------------------------------------------------
WSAEALREADY (10037) Operation already in progress.
Berkeley description: An operation was attempted on a non-blocking object that already had an operation in progress.
WinSock description: Unlike Berkeley Sockets, in WinSock WSAEALREADY means that the asynchronous operation you attempted to cancel has already been canceled. However, there's little distinction between WSAEALREADY and WSAEINVAL since a WinSock DLL cannot tell the difference between an asynchronous operation that has been cancelled and one that was never valid.
--------------------------------------------------------------------------------
WSAEBADF (10009) Bad file descriptor.
Berkeley description: A file descriptor argument was out of range, referred to no open file, or a read (write) request was made to a file that was only open for writing (reading).
Microsoft C description: Bad file number. The specified file handle is not a valid file-handle value or does not refer to an open file; or an attempt was made to write to a file or device opened for read-only access (or vice versa).
WinSock description: No equivalent in WinSock. However, because a BSD socket is equivalent to a file handle, some Windows Sockets platforms provide some file handle and socket equivalency. In this case, the WSAEBADF error might mean the same as a WSAENOTSOCK error.
See also: WSAENOTSOCK
--------------------------------------------------------------------------------
WSAECONNABORTED (10053) Software caused connection abort.
Berkeley description: A connection abort was caused internal to your host machine. The software caused a connection abort because there is no space on the socket's queue and the socket cannot receive further connections.
WinSock description: Partly the same as Berkeley. The error can occur when the local network system aborts a connection. This would occur if WinSock aborts an established connection after data retransmission fails (receiver never acknowledges data sent on a datastream socket).
TCP/IP scenario: A connection will timeout if the local system doesn't receive an (ACK)nowledgement for data sent. It would also timeout if a (FIN)ish TCP packet is not ACK'd (and even if the FIN is ACK'd, it will eventually timeout if a FIN is not returned).
User suggestions: There are a number of things to check, that might help to identify why the failure occurred. Basically, you want to identify where the problem occurred.
Ping the remote host you were connected to. If it doesn't respond, it might be off-line or there may be a network problem along the way. If it does respond, then this problem might have been a transient one (so you can reconnect now), or the server application you were connected to might have terminated (so you might not be able to connect again).
Ping a local host to verify that your local network is still functioning (if on a serial connection, see next step)
Ping your local router address. If you're on a serial connection, your local router is the IP address of the host you initially logged onto with SLIP or PPP.
Ping a host on the same subnet as the host you were connected to (if you know one). This will verify that the destination network is functioning.
Try a "traceroute" to the host you were connected to. This won't reveal too much unless you know the router addresses at the remote end, but it might help to identify if the problem is somewhere along the way.
See also: WSAECONNRESET, WSAENETRESET, WSAETIMEDOUT
--------------------------------------------------------------------------------
WSAECONNREFUSED (10061) Connection refused.
Berkeley description: No connection could be made because the target machine actively refused it. This usually results from trying to connect to a service that is inactive on the foreign host.
WinSock description: Same as Berkeley
TCP/IP scenario: In TCP terms (datastream sockets), it means an attempt to connect (by sending a TCP SYN packet) caused the destination host to respond to the host by returning a reset (a TCP RST packet). If an application sends a UDP packet to a host/port that does not have a datagram socket "listening," the network system may respond by sending back an ICMP Port Unreachable packet
User suggestions: Either you went to the wrong host, or the server application you're trying to contact isn't executing. Check the destination address you are using. If you used a hostname, did it resolve to the correct address? If the hostname resolution uses a local hosttable, it's possible you resolved to an old obsolete address. It's also possible that the local services file has an incorrect port number (although it's unlikely).
You can verify that the remote system is rejecting your connection attempt by checking the network statistics locally. Check that your network system (WinSock implementation) has a utility that shows network statistics. You could use this to verify that you're receiving TCP resets or ICMP Port Unreachable packets each time you attempt to connect.
Developer suggestions: If you have a network analyzer available, you can quickly check if the destination port number and host address are what you expect. On the server end, you could use a network system utility similar to BSD's "netstat -a" command to check that your server is running, and listening on the right port number.
This is one of the most frequent errors and one of the best to encounter, since it's one of the least ambiguous. There are only a few possible causes for this error:
you tried to connect to the wrong port. This is a common problem. You need to call to translate a constant value to network byte order before assigning it to the sin_port field in the sockaddr structure.
you tried to connect to the wrong destination host address
the server application isn't running on the destination host
the server application isn't listening on the right port. The server application might need to call to translate the port to network byte order in the sockaddr structure.
--------------------------------------------------------------------------------
WSAECONNRESET (10054) Connection reset by peer.
Berkeley description: A connection was forcibly closed by a peer. This normally results from a loss of the connection on the remote socket due to a timeout or a reboot.
WinSock description: Same as Berkeley. On a datastream socket, the connection was reset. This reset could be generated locally by the network system when it detects a connection failure, or it might be received from the remote host (in TCP terms, the remote host sent a RST packet). This error is also possible on a datagram socket; for instance, this error could result if your application sends a UDP datagram to a host, which rejects it by responding with an ICMP Port Unreachable.
User suggestions: Some network systems have commands to report statistics. In this case, it might be possible to check the count of TCP RST packets received, or ICMP Port Unreachable packets. See other suggestions under WSAECONNABORTED.
See also: WSAECONNABORTED, WSAENETRESET, WSAETIMEDOUT
--------------------------------------------------------------------------------
WSAEDESTADDRREQ (10039) Destination address required.
Berkeley description: A required address was omitted from an operation on a socket.
WinSock description: Same as Berkeley. The explanation is simple and obvious: in order to connect to or send to a destination address, you need to provide the destination address. This error occurs if the sin_addr is INADDR_ANY (i.e. a long zero) in the sockaddr_in structure passed to. Note: Although and FD_CONNECT also have this error listed, the documentation specifically states that WSAEADDRNOTAVAIL is appropriate if INADDR_ANY is passed as a destination address.
User suggestions: Did you enter a destination hostname? If so, then the application might have had a problem resolving the name (see suggestions at WSATRY_AGAIN for more information).
--------------------------------------------------------------------------------
WSAEDQUOT (10069) Disc quota exceeded.
Berkeley description: A write to an ordinary file, the creation of a directory or symbolic link, or the creation of a directory entry failed because the user's quota of disk blocks was exhausted, or the allocation of an inode for a newly created file failed because the user's quota of inodes was exhausted.
WinSock description: No equivalent. This has no network-relevant analog (although the "inode" reference could refer to a network file system entry).
--------------------------------------------------------------------------------
WSAEFAULT (10014) Bad address.
Berkeley description: The system detected an invalid address in attempting to use an argument of a call.
WinSock description: Same as Berkeley, and then some. Specifically, v1.1 WinSock spec notes that this error occurs if the length of the buffer is too small. For instance, if the length of a struct sockaddr is not equivalent to the sizeof(struct sockaddr). However, it also occurs when an application passes an invalid pointer value.
Developer suggestions: Always check the return value from a memory allocation to be sure it succeeded. Always be sure to allocate enough space.
--------------------------------------------------------------------------------
WSAEHOSTDOWN (10064) Host is down.
Berkeley description: A socket operation failed because the destination host was down. A socket operation encountered a dead host. Networking activity on the local host has not been initiated.
WinSock description: No equivalent. The only time a WinSock might use this error--at least with a TCP/IP implementation of WinSock--it fails a function with other errors (for example, WSAETIMEDOUT).
See also: WSAECONNABORTED, WSAECONNRESET, WSAENETRESET, WSAETIMEDOUT
--------------------------------------------------------------------------------
WSAEHOSTUNREACH (10065) No route to host.
Berkeley description: A socket operation was attempted to an unreachable host.
WinSock description: Same as Berkeley. Unlike Berkeley, however, WinSock v1.1 doesn't ascribe this error to any functions. In it's place, WinSock uses the error WSAENETUNREACH, exclusively.
TCP/IP scenario: In BSD-compatible implementations, the local network system generates this error if there isn't a default route configured. Typically, though, WinSock generates WSAENETUNREACH when it receives a "host unreachable" ICMP message from a router instead of WSAEHOSTUNREACH. The ICMP message means that the router can't forward the IP datagram, possibly because it didn't get a response to the ARP request (which might mean the destination host is down).
User suggestions: see WSAENETUNREACH for details
See also: WSAENETUNREACH
--------------------------------------------------------------------------------
WSAEINPROGRESS (10036) Operation now in progress.
Berkeley description: An operation that takes a long time to complete (such as a) was attempted on a non-blocking socket. (see ioctl()).
WinSock description: The Windows Sockets definition of this error is very different from Berkeley. WinSock only allows a single blocking operation to be outstanding per task (or thread), and if you make any other function call (whether or not it references that or any other socket) the function fails with the WSAEINPROGRESS error. It means that there is a blocking operation outstanding.
It is also possible that WinSock might return this error after an application calls a second time on a non-blocking socket while the connection is pending (i.e. after the first failed with WSAEWOULDBLOCK). This is what occurs in Berkeley Sockets.
--------------------------------------------------------------------------------
WSAEINTR (10004) Interrupted function call.
Berkeley description: An asynchronous signal (such as SIGINTor SIGQUIT) was caught by the process during the execution of an interruptible function. If the signal handler performs a normal return, the interrupted function call will seem to have returned the error condition.
WinSock description: NOT same as Berkeley, but analogous. In WinSock it means a blocking operation was interrupted by a call to.
Developer suggestions: You need to be prepared to handle this error on any functions that reference blocking sockets, or any calls to blocking functions, if you allow the user to cancel a blocking call. Whether to handle it as a fatal error or non-fatal error depends on the application and the context, so it's entirely up to you to decide.
--------------------------------------------------------------------------------
WSAEINVAL (10022) Invalid argument.
Berkeley description: Some invalid argument was supplied (for example, specifying an invalid level to the setsockopt() function).
Microsoft C description: Invalid argument. An invalid value was given for one of the arguments to a function. For example, the value given for the origin when positioning a file pointer (by means of a call to fseek) is before the beginning of the file.
WinSock description: Similar to Berkeley & Microsoft C, the generic meaning is that an application passed invalid input parameter in a function call. The error refers to content as well as value (e.g. it may occur when a pointer to a structures is invalid or when a value in structure field is invalid). In some instances, it also refers to the current state of the socket input parameter.
Detailed descriptions (relevant to socket states):
accept(): listen() was not invoked prior to
bind(): socket already bound to an address
getsockname(): socket not bound with
listen(): socket not bound with or already connected.
recv() & recvfrom(): socket not bound (for Dgram) or not yet connected (for Stream), or the requested length is zero (whether a length >32K
is acceptable as a non-negative value is unclear, so don't use them).
send() & sendto(): socket not bound (for Dgram) or not yet connected (for Stream)
The v1.1 specification also has a detailed description for the connect() function which says: "socket not already bound to an address." This text is a typo which makes no sense. Ignore it. The standard meaning for WSAEINVAL applies to connect() (invalid argument).
--------------------------------------------------------------------------------
WSAEISCONN (10056) Socket is already connected.
Berkeley description: A connect request was made on an already connected socket; or, a or sendmsg() request on a connected socket specified a destination when already connected.
WinSock description: Same as Berkeley, except WinSock doesn't support the sendmsg() function, and some WinSock implementations are not so strict as to require an application with a datagram socket to "disconnect"--by calling with a AF_INET NULL destination address: INADDR_ANY (0.0.0.0), and port 0--before redirecting datagrams with or. On a datastream socket, some applications use this error with a non-blocking socket calling connect() to detect when a connection attempt has completed, although this is not recommended since some WinSocks fail with WSAEINVAL on subsequent calls.
--------------------------------------------------------------------------------
WSAELOOP (10062) Too many levels of symbolic links.
Berkeley description: A pathname lookup involved more than 8 symbolic links. Too many links were encountered in translating a pathname.
WinSock description: No equivalent
--------------------------------------------------------------------------------
WSAEMFILE (10024) Too many open files.
Berkeley description: Too many open files. No process may have more than a system-defined number of file descriptors open at a time.
Microsoft C description: Too many open files. No more file handles are available, so no more files can be opened.
WinSock description: Similar to Berkeley & Microsoft C, but in reference to sockets rather than file handles (although the descriptions in the v1.1 specification say "no more file descriptors available"). Generically, the error means the network system has run out of socket handles.
User suggestions: It may indicate that there are too many WinSock applications running simultaneously, but this is unlikely since most network systems have many socket handles available. It could also occur if an application opens and closes sockets often, but doesn't properly close the sockets (so it leaves them open, as "orphans"). To recover the orphaned sockets, you can try closing the application and restarting it to recover the open sockets; you may have to end all WinSock applications (to force an unload of the WinSock DLL).
--------------------------------------------------------------------------------
WSAEMSGSIZE (10040) Message too long.
Berkeley description: A message sent on a socket was larger than the internal message buffer or some other network limit.
WinSock description: Similar to Berkeley.
Detailed description:
recv() and recvfrom(): if the datagram you read is larger than the buffer you supplied, then WinSock truncates the datagram (i.e. copies what it can into your buffer) and fails the function.
send() and sendto(): you cannot send a datagram as large as you've requested. Note that the v1.1 WinSock specification does not explicitly state that this error occurs if the value you request is larger than the WSAData.iMaxUdpDg returned from. Since the buffering requirements for sending are less than for receiving datagrams, it's conceivable that you can send a datagram larger than you can receive.
--------------------------------------------------------------------------------
WSAENAMETOOLONG (10063) File name too long.
Berkeley description: A component of a path name exceeded 255 (MAXNAMELEN) characters, or an entire path name exceeded 1023 (MAXPATHLEN-1) characters.
WinSock description: No equivalent.
--------------------------------------------------------------------------------
WSAENETDOWN (10050) Network is down.
Berkeley description: A socket operation encountered a dead network.
WinSock description: Same as Berkeley. As you can see from the comprehensive list of WinSock functions, this error is the catch-all. When it occurs, it could indicate a serious failure of your network system (i.e. the protocol stack that the WinSock DLL runs over).
User suggestions: Check your WinSock, protocol stack, network driver and network interface card configuration. Note that this error occurs rarely since a WinSock implementation cannot reliably detect hardware problems.
--------------------------------------------------------------------------------
WSAENETRESET (10052) Network dropped connection on reset.
Berkeley description: The host you were connected to crashed and rebooted.
WinSock description: Same as Berkeley.
Detailed description:
setsockopt(): WinSock generates this error if you try to set SO_KEEPALIVE on a connection that's already timed out.
User suggestions: see WSAECONNABORTED for details.
See also: WSAECONNABORTED, WSAECONNRESET, WSAETIMEDOUT
--------------------------------------------------------------------------------
WSAENETUNREACH (10051) Network is unreachable.
Berkeley description: A socket operation was attempted to an unreachable network.
WinSock description: Almost same as Berkeley. For WinSock, this error is equivalent to Berkeley's EHOSTUNREACH error, the catch-all error for unreachable hosts. "You can't get there from here."
TCP/IP scenario: The local network system could generate this error if there isn't a default route configured. Typically, though, WinSock generates this error when it receives a "host unreachable" ICMP message from a router. The ICMP message means that a router can't forward the IP datagram, possibly because it didn't get a response to the ARP request (which might mean the destination host is down). Note: this error may also result if you are trying to send a multicast packet and the default gateway does not support multicast (check your interface configuration).
User suggestions: Try to ping the destination host, to see if you get the same results (chances are, you will). Check the destination address itself; is it the one you wanted to go to? Check whether you have a router configured in your network system (your WinSock implementation). Do a traceroute to try to determine where the failure occurs along the route between your host and the destination host.
See also: WSAEHOSTUNREACH
======
»
www.danielclarke.com/pee ··· TUNREACH 
