Connection Refused Errors

From InterBase

Go Up to Connection Troubleshooting


If the client fails to reach the server host at all, or the gds_db service fails to answer, you might get a “connection refused” error. Below is a checklist that you can use to diagnose the source of this error:

Is there low-level network access between the client and server?

You can quickly test whether the client cannot reach the server because of a physically disconnected network or improper network software configuration, by using the ping command. Usage is:

ping servername

Error messages from ping indicate that there is a network problem. Check that the network is plugged in, that the network wires are not damaged, and that the client and server software is properly configured.

Test connectivity from the client in question to another server; if it succeeds, this could rule out improper network configuration on the client.

Test connectivity from another client to the InterBase server host; if it succeeds, this could rule out improper network configuration on the server.

Can the client resolve the server’s hostname?

InterBase clients must specify the server by name, not by IP address, except in some Linux distributions. Therefore, the client must be able to resolve the server’s hostname. For TCP/IP, this is done either by maintaining a hosts file on the client with the mappings of hostnames to IP addresses, or by the client querying a DNS server or WINS server to resolve this mapping. Make sure the name server has a correct entry for the server host in question.

Is the server behind a firewall?

If the database server is behind a software or hardware firewall, all network traffic could be restricted and the client might not be able to reach the server at all. Some firewalls permit or restrict traffic based on the port to which the client attempts to connect. Because of this, it is not conclusive whether a given service can reach the server. Neither is it an indication of connectivity if the client can resolve the IP address; that merely indicates that the client can reach a name server that resolves the InterBase server hostname.

If the client is separated from the server by a firewall, the client cannot connect.

Are the client and server on different subnets?

NetBEUI cannot route network traffic between subnets. Other protocols can also be configured to restrict traffic between subnets. If the client and server are on a complex network with multiple subnets, ask your network administrator if the network configuration allows you to route network traffic between the client and server in question using a given protocol.

Can you connect to a database locally?

To confirm that the ibserver process is running on the server and able to attach to your database, try a local database connection:

  1. Log in to the console of the database server host, and run an application such as command-line isql.
  2. Attempt to connect to a database without specifying a hostname: list just the path.

The Communications Diagnostic dialog also has a local database attachment test. See DB Connection Tab for details.

Note:
Local connection mode is not available on UNIX servers.

Can you connect to a database loopback?

You can simulate a client/server connection and test the configuration of the server without the additional variable of the client configuration and intervening network by connecting in a loopback mode.

  1. Log in to the console of the database server host and run an application such as command-line isql or InterBase IBConsole isql.
  2. Attempt to connect to the database using a remote connection specification, even though the server named is also the client host.

Whether this test fails or succeeds, it helps to narrow the focus of further diagnostic tests. If it fails, you can infer that the configuration of the server is at fault. If it succeeds, you can infer that the server is not at fault and you can concentrate further tests on the client.

Is the server listening on the InterBase port?

If the ibserver process on the server has not started, there is no answer to attempts to connect to the gds_db service (port 3050).

Start the ibserver process on the server. Use ibmgr -start on UNIX, or the InterBase Manager on Windows. See Server Configuration.

Is the services file configured on client and server?

The services file must have correct entries to indicate the port number associated with the named service gds_db. This configuration must be accessible on the client as well as the server.

gds_db 3050/tcp # InterBase Server

This file is found in the following locations:

Windows server platforms: C:\system32\drivers\etc\services or C:\Windows\system32\drivers\etc\services on new Windows platforms

On Windows non-server platforms: C:\windows\services.

On UNIX: /etc/services.

In a UNIX environment with NIS, the NIS server can be configured to supply the services file to all NIS clients on UNIX workstations.

See Also

Advance To: