(10053) - Software caused connection abort.
The above error is generally no cause for concern as it results from users cancelling an operation, such as a
in the middle of a p4 sync
. Depending on the timing of the cancel you see either a WSAECONNABORTED or WSAECONNRESET error. You would expect to see these errors in any log.
Note: A cancellation of p4 obliterate
in this manner can potentially corrupt the Perforce database. When faced with database corruption, searching the logs for WSAECONNABORTED might reveal a bad obliterate.WSAECONNREFUSED
(10061) - Connection refused.
This error usually results from trying to connect to a service that is inactive on the foreign host -- that is, one with no server application running. You can also get this message if attempting to connect to a firewalled machine with no provisions for Perforce.WSAETIMEDOUT
(10060) - Connection timed out.
A connection attempt failed because the connected party did not properly respond after a period of time, or the established connection failed because the connected host has failed to respond. The error can also occur when trying to connect to a server protected by a firewall that uses "tar pits".
Connect to server failed; check $P4PORT.
TCP connect to public.perfoce.com:1666 failed.
Check to make sure that the server is running.
netstat -a gives a list of all processes listening on network ports. Look for lines that contain "LISTEN" and "1666" (or whatever port you have Perforce running on.) If you do not see such a line, the server is not running.
Verify that the server accepts local connections using the localhost address from the server machine, such as:
p4 -p 127.0.0.1:1666 info
If you cannot connect check and make sure P4PORT
is set to "1666" for the server. This ensures the server is listening on all interfaces. Setting P4PORT to 'localhost:1666' will set it to only allow connections from the local machine. Make sure that it is set properly with 'p4 set -S Perforce P4PORT
' and if it's not, set it:
p4 set -S Perforce P4PORT=1666
On Linux/Mac/Unix, instead of using 'p4 set', you can either set the environment variable $P4PORT or use the '-p' flag to p4d:
p4d -r $P4ROOT -p 1666 [other flags]
Verify network connectivity by pinging the server from the client. If you cannot ping the server, then either ICMP is being blocked or there is a network issue outside of Perforce.
Verify that the server port is reachable by "telnet <server> <port>". This can give you a descriptive error or confirm a connection. Note that on Windows servers the telnet utility might not be available by default; if it is not available, you can install it from your Programs and Features control panel item. In the sidebar there is a Turn Windows Features On or Off, select it and then check Telnet Client in the list. Click OK.
If you still cannot connect, then verify the TCP/IP properties settings for any port filters/firewalls. If there is a firewall, make sure that incoming connections to port 1666 are permitted, and that all existing outbound connections are permitted (the latter is usually standard). On Windows machines, go to Control Panel -> Windows Firewall, click on Advanced Settings, and then click on Inbound Rules on the sidebar. Make sure p4d is enabled.
Check to make sure that DNS is resolving the IP address correctly. Pinging by DNS name is quick verification. "nslookup <hostname>" or "dig <hostname>" can also work.
Run the Perforce command using the IP address instead of DNS name.
If IP address works, suspect DNS resolution problems or an incorrectly spelled hostname.
If IP address does not work, suspect a problem with either host table entries or routing or other network problems. The commands "route" and "arp -a" can be helpful in this regard.
If problem is intermittent, suspect hardware, interface configuration, or congestion problems. Tools such as fping and wireshark are useful for uncovering these sorts of errors.
If the connection is through a VPN or ssh tunnel, an improper MTU value might be the culprit. You must account for the additional header information (typically 8 bytes) added by the VPN encryption process. At a minimum this means that the standard MTU default size needs be reduced to 1492 or smaller. The network MTU setting (Maximum Transmission Unit) can be modified in the Windows registry.
Check to see whether or not your intranet or local network is using Jumbo frames. Jumbo frames are ethernet frames that exceed the normal maximum MTU in order to provide support for high-performance applications. A jumbo frame can have an MTU over 1500, with 9k being an oft-used value. Jumbo frames will automatically fail when used across hardware that doesn't support them, such as VPNs and many firewalls. Disabling Jumbo frames is usually the only option available in this case.
Ping the main server machine with increasing numbers of packets to help acquire more information about your MTU.
ping -l 56 perforce_server
ping -l 120 perforce_server
ping -l 248 perforce_server
ping -l 504 perforce_server
ping -l 1016 perforce_server
ping -l 2040 perforce_server
ping -l 4088 perforce_server
ping -l 8184 perforce_server
ping -l 16376 perforce_server
ping -l 32760 perforce_server
When the ping starts to fail will indicate what the ceiling is for the maximum size of the data packet. Set the MTU on your machine to the previous setting using the instructions in the article Changing the MTU
. For example, if the ping fails on '16376' but succeeds on '8184', then the cap is somewhere between those numbers. You can narrow it down, or just use '8184' as the MTU.
Check for inordinate delays with the traceroute command "tracert <perforce_server>". On linux, it is called "traceroute".
See Windows Sockets Error Codes for additional information.