10054: WSAECONNRESET: Connection reset by peer

[Sanjay Kumar Suri]

We have been using SAP R/3 over the WAN. However some of the users are facing following error frequently:

10054: WSAECONNRESET: Connection reset by peer

After getting the error the used gets disconnected and obviously data entered so far gets lost.

We have tried almost everything to resolve the issue but the results are not encouraging.

On chekcing SAP note 413330 we found following inputs (for making changes in the Windows registry):

NOTE BEGIN

1. Establishing a connection

Windows NT/ Windows 2000:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters Via menu 'Edit - Add Value', add 'TcpMaxConnectRetransmissions'.
Data Type: REG_DWORD
Valid Range: 0 - 0xFFFFFFFF
Default: 3

Windows95/ Windows98:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP Via menu 'Edit - Add Value', add 'MaxConnectRetries'.
Data Type: String
Valid Range: 0 - 0xFFFFFFFF
Default: 3

2. Existing connection:

Windows NT/ Windows 2000:
Via menu 'Edit - Add Value', add 'TcpMaxDataRetransmissions'.
Data Type: REG_DWORD
Valid Range: 0 - 0xFFFFFFFF
Default: 5

Windows95/ Windows98:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP Via menu 'Edit - Add Value', add 'MaxDataRetries'.
Data Type: String
Valid Range: 0 - 0xFFFFFFFF
Default: 5

An increase by 1 corresponds roughly to a doubling of the timeout time. You may need to experiment a little with the values, to find the setting most appropriate to your requirements.

NOTE END

How to arrive right value for the registry parameters (in case of existing connection; default = 5)?

Other solutions to this problem are also welcome.

Thanks.

sks

[Deoncia Grayson_1]

Try this link, it gives a more descriptive

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcewinsk/html/cerefwinsockerrorcodes.asp

or this one http://www.southdown.co.uk/db/support/default.taf?_function=show&_article=f0012


10054 WSAECONNRESET 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 (Windows Sockets) 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.

[rick jones]

Connection reset by peer suggests that the peer, not the local client aborted the connection. Since you are asking in a UX forum I'll ass-u-me :) that the peer here is an HP-UX box.

If you sniff the network, looking at the RST segments from the HP-UX system, they will have text after the TCP header that is the ASCII encoding of the reason the RST was sent. Once the reason is known the change shoudl be more easily determined.

Unless the WSA error messages are slightly bogus, and include a local TCP abort, I would not expect changes in the Windows registry to affect much.

As for the general question about picking retransmission limits - basically, you want to allow enough retransmissions to get your "false positive" rate for connection failure sufficiently low. You need to determine what is sufficiently low in connection aborts per N connections. Then take your networks average packet loss rate, and multiply that by itself enough times to get to that rate. The number of times you had to multiply (ie the power) is what you would use - I'd probably add one to it.

[Sanjay Kumar Suri]

Thanks Rick. Yes our database & application server run on HP-UX/Oracle 9i.

Can you give more inputs/"How to do" on the following:

"If you sniff the network, looking at the RST segments from the HP-UX system, they will have text after the TCP header that is the ASCII encoding of the reason the RST was sent. Once the reason is known the change shoudl be more easily determined.

Unless the WSA error messages are slightly bogus, and include a local TCP abort, I would not expect changes in the Windows registry to affect much"

sks

[rick jones]

http://software.hp.com/ - grab the tcpdump from the Internet Express bundle for your OS rev. Run that on the interface in question with a tcpdump filter expression to catch just RST segments. See the tcpdump.1 manpage or whatever docs may be on www.tcpdump.org. From rough memory it will be something of the form:

$ tcpdump -i 'tcp[13] & 7 != 0'

where "tcp[13]" is the 13th byte of the TCP header. I'm probably off on the constants.

Keep in mind that tcpdump may consume a bit of CPU...

There may also be a way to do similar things with the nettl that is already installed on your system. The nettl manpage and/or docs.hp.com would be the place to start there.