Perforce Public Knowledge Base - "WSAECONNRESET" Error Description
× PRODUCTS SOLUTIONS CUSTOMERS LEARN SUPPORT
Downloads Company Partners Careers Contact Free Trials
Menu Search
Perforce
Reset Search
 

 

Article

"WSAECONNRESET" Error Description

« Go Back

Information

 
Problem

What is a WSAECONNRESET error?
Why do I receive write: socket: Connection reset by peer

Solution

WSECONNRESET


When there is a forced-close of a networking socket, Windows issues a "WSAECONNRESET" error. Regular occurrences of the error indicate possible network problems.

This error is also seen as

write: socket: Connection reset by peer

In the same way, the remote server has sent a RST packet, which indicates an immediate dropping of the connection, rather than the usual TCP/IP handshake. 

This error should not be confused with WSAECONNREFUSED where a port is blocked or a hostname is not set, nor WSAECONNABORT which is a more serious, harder-to-debug error caused by a connection which was halted by the local operating system after network packets were lost or a suitable acknowledgement signal (ACK) was not received.

An explanation from Microsoft's KB:

Connection reset by peer

An existing connection was forcibly closed by the remote host. This normally results if the peer application on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close (see setsockopt for more information on the SO_LINGER option on the remote socket). This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress. Operations that were in progress fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.

An explanation from RealVNC:

Connection reset by peer

"Connection reset be peer" generally suggests a network issue (not related to the VNC application itself), this could be due to either misconfigured or faulty network hardware.

"Connection reset by peer" specifically means that, as far as the application reporting the error is concerned, the other endpoint sent a TCP reset packet. Sometimes, both endpoints report this error, in which case something in the middle has sent reset packets to both ends. It's not possible for the endpoints to get any more information than this. That unfortunately means the VNC Viewer cannot tell what has caused the error.

An explanation from StackOverflow:

What does “connection reset by peer” mean?

"Connection reset by peer" is the TCP/IP equivalent of slamming the phone back on the hook. It's more polite than merely not replying, leaving one hanging. But it's not the FIN-ACK expected of the truly polite TCP/IP converseur.


Example

It is easy to reproduce this error.  Start a "p4 sync" then interrupt it with a ctrl-c then examine the Perforce log.  For example:

        2017/08/02 16:05:19 pid 30490 bruno@testclient 10.20.0.242 [p4/2016.2/LINUX26X86_64/1468155] 'user-sync -f ...'
Parallel transmission cancelled: net.parallel.max must be set > 0.
Perforce server info:
        2017/08/02 16:05:19 pid 30490 compute end .004s 2+2us 0+80io 0+0net 3396k 0pf
Perforce server info:
        Server network estimates: files added/updated/deleted=0/369/91, bytes added/updated=0/822985392
Perforce server info:
        2017/08/02 16:05:36 pid 30490 completed 16.3s 128+332us 4672+112io 0+0net 3844k 42pf
Perforce server info:
        2017/08/02 16:05:19 pid 30490 bruno@testclient 10.20.0.242 [p4/2016.2/LINUX26X86_64/1468155] 'user-sync -f ...'
--- rpc msgs/size in+out 123+135229/0mb+533mb himarks 186692/186692 snd/rcv 13.4s/.000s
--- rpc send receive errors, duplexing F/R 1/0
--- clients/Randall_Perl(R)
---   total lock wait+held read/write 0ms+16307ms/0ms+0ms

Perforce server error:
        Date 2017/08/02 16:05:36:
        Pid 30490
        Connection from 10.20.0.242:52436 broken.
        TCP send failed.
        write: socket: Connection reset by peer

Also note that F/R ending with a zero is a sign of ctrl-c interrupting the sync.
 

Troubleshooting

The WSAECONNRESET error is a networking error passed to Perforce from the operating system, so checking the network outside of Perforce will help diagnose the issue:

  1. Run a ping command using larger packet sizes.

    This would be "ping -l" on Windows or "ping -s" on Unix.  Typical networks will handle a packet size of 1350.

    For example, the following command should always succeed when run from Windows:

    ping -l 1350 {ip address or domain name}

    But larger packet sizes may also be tried to determine if the network is near its limits:

    ping -l 56 {ip address or domain name}
    ping -l 120 {ip address or domain name}
    ping -l 248 {ip address or domain name}
    ping -l 504 {ip address or domain name}
    ping -l 1016 {ip address or domain name}
    ping -l 2040 {ip address or domain name}
    ping -l 4088 {ip address or domain name}
    ping -l 8184 {ip address or domain name}
    ping -l 16376 {ip address or domain name}
    ping -l 32760 {ip address or domain name}

    Note: The "-l" flag is written as hyphen lowercase-L.

  2. Check to see if this error is seen when running ftp

    Use the ftp, scp, or a network drive to retrieve large files and a large number of files from the same server.  If you are using a proxy server, also ftp large files and a large number of files from the proxy server.  If a file transfer generates networking errors outside of Perforce then you can expect the networking errors to be seen within Perforce as well.

  3. Adjust the MTU of all devices

    The Maximum Transmission Unit (MTU) should be set to 1492 or as high as possible on all networking equipment and network interfaces.  See "Common Windows Server Network Errors" in the Perforce knowledge base for more details.

    Also check the Perforce log to see if WSAECONNRESET errors come from particular machines or from particular IP address subnets.  This combined with the tracert command can help isolate routers and/or machines that may need the MTU adjusted.

  4. Use Shared Networking in virtual machines

    Try shared networking (NAT) if you are using a virtual machine instead of using the host machine's physical Ethernet directly.
     

Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255