Troubleshooting socket errors

TCP/IP socket errors have the following mnemonics:

• Connect:errno:error
• Recv:errno:error

where error is the text for the socket error: Connection reset by peer (10054 or 54) or Connection refused (10061 or 61).

To view socket errors, use Vortex API logging or %SSC_GETEMSG. On UNIX systems, see /usr/include/errno.h. On Windows systems, you can find these errors in winsock.h or winsock2.h, which are typically distributed with Microsoft’s Platform Software Development Kit (SDK). For details on Microsoft error codes, see Microsoft documentation.

Connection reset by peer (10054 or 54)

The “Connection reset by peer” socket error, which is 10054 (WSAECONNRESET) on Windows and generally 54 (ECONNRESET) on UNIX and OpenVMS, indicates that a connection to the server has been closed. This could be caused by a fatal error on the server, the server stopping, a network problem, or even a connection problem.

1.

If the error has the form “connect:errorno:error”, use vtxping (or synxfpng with the -x option) to test your ability to connect to the server. Otherwise, skip to step 2. The vtxping and synxfpng utilities print reports to the screen. This information can be used by your network administrator to resolve TCP/IP network socket communication problems.

• If you can connect, then the network, the server, and the Synergy/DE OpenNet Server service (SynSQL) are working. Continue with step 2.
• If you can’t connect, make sure that the server is running, that the SynSQL service is running on the server, and that vtxping or synxfpng is using the correct port.

For more information see vtxping utility and synxfpng utility.

2.

Check and correct the following, which may solve the problem if it is caused by network timing issues:

• If you’re using network licensing, make sure License Manager is configured as a network server.
• Make sure the server was rebooted after the Connectivity Series components were installed.
• Check the system-level PATH on the server. It should include the connect directory.
• Use vtxnetd or vtxnet2 logging and check the resulting tcm_pid.log file. Then check the event log on Windows, syslog on UNIX, or the operator console on OpenVMS. (For information on vtxnetd and vtxnet2 logging, see vtxnetd and vtxnet2 programs.)
• Make sure the file(s) for the database driver you are using are in the connect directory on the server. On Windows, there are two files: an .exe and a .dll (e.g., vtx0_11.exe and vtx0_11.dll for Oracle). On UNIX, this is an .so file (e.g., vtx0.so). On OpenVMS, this is an .exe file (e.g., vtx0.exe).
• Make sure there is no more than one vtxnet2 process running on the server. If there’s more than one, use vtxkill to kill the processes; then restart the service.

3.

If you’re on Windows or UNIX, run the dltest utility to make sure Connectivity Series DLLs or shared libraries are loading properly.

4.

Make sure the connect string in the client application is referencing a valid driver and database.

5.

If you get this socket error again, use vtxnetd or vtxnet2 logging and check the event log on Windows, syslog on UNIX, or the operator console on OpenVMS.

For additional troubleshooting steps for prior versions of Connectivity Series, see the Synergex KnowledgeBase article 1607.

Connection refused (10061 or 61)

The “Connection refused” socket error, which is 10061 (WSAECONNREFUSED) on Windows and is generally 61 (ECONNREFUSED) on UNIX and OpenVMS, indicates that the SQL Connection program can’t make a connection to the SQL OpenNet server. The SQL OpenNet server may not be running, it may not use the port that’s specified for the client (see Port settings), or the host specified in the connect string may be incorrect.

1.

Use vtxping (or synxfpng with the -x option) to test your ability to connect to the server. (For more information see vtxping utility and synxfpng utility.)

The vtxping and synxfpng utilities print reports to the screen. This information can be used by your network administrator to resolve TCP/IP network socket communication problems.

• If you can connect, then the network, the server, and the Synergy/DE OpenNet Server service (SynSQL) are working. Continue with step 2.
• If you can’t connect, make sure that the server is running, that the SynSQL service is running on the server, and that vtxping or synxfpng is using the correct port.

2.

Make sure the port number specified in the connect string matches the port number used by the SQL OpenNet server. For more information, see Configuring Connectivity Series and Port settings.