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, 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.
Winsock Errors are Microsoft Windows Sockets errors, not DameWare errors, and even though a Winsock 10054 error can be caused by many different things,
"network" errors are the typical cause of this "Forcible Disconnect" or "Lost Connection" error.
Googling this specific error will result in thousands
of hits (http://www.google.com/search?hl=en&q=winsock+10054),
and even more can be obtained by searching this way (http://www.google.com/search?hl=en&q=WSAECONNRESET).
The term "network" errors is not limited to hardware, but also includes everything
between point A to point B - bad or faulty hardware,
bad or faulty drivers, even
application errors on the remote machine. This error can be duplicated by
unplugging the Ethernet cable, or if either end of the
TCP socket has gone down for any reason.
Please consider the following additional information:
- What Operating System and service pack level is installed on the local and remote machines?
- Are tests being performed such as "penetration testing," "vulnerability" or "threat assessment"
or any other type of scanning/testing on these machines or on the network?
- Is there a specific interval of time in which the connection remains before being
disconnected? Is this a consistent amount of time, or random?
- Is the remote machine being left at the Logon Desktop or Lock Screen, or on a users desktop (logged in)?
- Is there a screen saver defined on the remote machine?
- Is there any type of Security or AV software on these machines or on the network (i.e. Cisco Security Agent, Symantec AV, Symantec Endpoint Protection (SEM),
CA eTrust, Pest Patrol, etc.)? This software could be hooking into (or scanning) all activity on the network or on these machines, which could possibly
cause an additional load. This additional load could also be causing timeouts to occur or this software could be killing the TCP socket in totality.
- Are there any type of activity timeouts enabled within the DMRC software or DMRC
Client Agent Service? In the DMRC Application, select the Host Entry, click on Settings
(blue wrench), then select the Inactivity Options Tab and make sure "Enable Disconnect on Inactivity" is not enabled. For the DMRC Client Agent
Service on the remote machine,
right-click on the DMRC SysTray icon and select Settings.
Select the General Tab and make sure "Absolute Timeout" is set to 0 (Zero), which equals no timeout.
- Is the Mirror Driver being used for this connection (i.e. is the "Use MRC Mirror
Driver" checkbox enabled on the Remote Connect dialog before clicking on Connect)?
If so, try the following steps because version 5.x of the software does not automatically install the DameWare Mirror Driver on the remote machine. It is automatically installed in version 6.x of the software:
- Select the Host Entry, click on the Settings button (blue wrench), then select the Mirror Driver Tab and enable the "Force 8-bit display" option.
This will reduce the color-depth over the DMRC connection to 8-bit color, which will drastically reduce the amount of data being sent over the wire.
Due to the tremendous amount of data the Mirror Driver is capable of sending, this actually may be too efficient for this specific type of connection and it is possible some hardware (or driver) component is not capable of handling this additional load.
- If #1 does not help, try toggling the "Use MRC Mirror Driver" off before clicking
on the Connect button to see if the connection remains
without any type of Winsock 10054 error.
- Is a VPN connection being used? DameWare software should work fine over any type of VPN implementation (hardware or software). It may be helpful
to check the MTU settings because the MTU settings for the VPN connection may be larger than what is defined on the local or remote network, which
could be causing a lot of dropped packets.
Also, it is recommended that the VPN configuration with regard to the fragmentation of packets be reviewed.
The following is one DameWare user's comments concerning MTU settings:
"I did a little hunting around on the web and found a post regarding the MTU settings on routers.
I eventually reduced it to 500 (originally at 1500) and Dameware (and RDP) connect fine now."
Therefore, using the following test may prove to be helpful:
Ping <ip-address> -f -l #bytes
Start #bytes about 1500, then decrease incrementally. Check the response times, and note if the Operating System displays a message stating that it needs to fragment the packets. The more fragmentation present, the higher the possibility for packet loss (depending on the VPN and network configuration).
- When reconnecting to the same machine, is a message displayed stating that
the DMRC Client Agent Service is installed but not running on the remote machine, and asked to start it? If so, this is a good indication that something on the remote
machine is causing the DMRC Client Agent Service to crash on the remote machine,
which would certainly cause a Winsock 10054 error to occur (similar to unplugging the Ethernet cable from the wall).
If an old version of the software is being used, try upgrading to
the newest (current)
version and updating the DMRC Client Agent Service on the remote machine.
An issue was discovered in version 126.96.36.199, where reconnecting to a remote machine with the "Enable Remote Clipboard" feature enabled could possibly terminate the
connection with a Winsock 10054
error. This was resolved in the subsequent release of the software.
If these suggestions and action steps do not resolve the issue, please check for any DWMRCS entries in the Application Event Log on the remote machine and send the entire text (not screen shots) from these entries to email@example.com for examination.
Please also check for any "Service Control Manager" entries for the DMRC Client
Agent Service (i.e. DWRCS.EXE, or DWRCST.EXE) which could explain this behavior.