Warning: Netcat's software creator has not updated the software since 2006. Therefore, Rackspace Technology makes no warranty that the quality of Netcat will meet your expectations.
If your network service is malfunctioning but you know the service is listening to a network port, you can verify the program connection to troubleshoot the problem.
Use the Netcat command,
nc, to access the service. If you are running a Red Hat®-based distribution and you don't have
nc installed, type the following command on the command line:
$ sudo yum install nc`
For a Debian®-based distribution, type the following command on the command line:
$ sudo apt-get install Netcat`
Run a simple test to verify that the port accepts connections.
nc on the command line followed by the
-vz option with your IP address and port:
$ nc -vz IP_address port
The IP address should be the one on which the service receives connections.
The following examples show the possible output messages:
$ nc -vz 203.0.113.96 21 Connection to 203.0.113.96 21 port [tcp/ftp] succeeded!
$ nc -vz 203.0.113.96 80 nc: connect to 203.0.113.96 port 80 (tcp) failed: Connection refused
$ nc -vz 203.0.113.96 80 nc: connect to 203.0.113.96 port 80 (tcp) failed: Connection timed out
The service isn't running, or a firewall is rejecting the connection. Verify the process status by running
ps on the command line. See Checking running services on Linux for more options.
Note: If your service is running, your firewall might reject the connection. Read the connection timed out section for instructions on firewall troubleshooting.
A connection timed out response indicates that your connection is not working, which could mean your firewall is blocking the port. Test the connection status by adding a rule that accepts connections on the required port.
The following example inserts a rule on line 1 of the input chain that accepts all TCP connections on port
80 (HTTP). Use this rule when testing a web server such as Apache®.
$ sudo /sbin/iptables -I INPUT 1 -p tcp --dport http -j ACCEPT
IP tables instantly reflects any changes made. Repeat the test with
nc to see if there is any change in the response.
If you want to remove the rule you have added, you can use the
-D option combined with the position of the rule in the chain. The previous example added a rule at line 1, the top of the chain. The following example shows how to remove it.
$ sudo /sbin/iptables -D INPUT 1
You can check your current firewall configuration at any time by running the following command on the command line:
$ sudo /sbin/iptables -L -v
If the initial connection succeeds, Netcat can connect to the service. Look at the connection in more detail.
First, use the
-vt option to see if the service can respond to basic network queries:
$ nc -vt IP Address Port
If you can send commands to the service-daemon and receive responses, that indicates that the program is accessible, and your issue might be due to the client's connection configuration.
After you connect, test the service to get a response. You can test the service by sending a
GET request to a web server, or some other appropriate data to prompt the server for a response.
You can terminate the connection by either pressing Ctrl-C or type the service-specific quit command.
For example, you can close a connection to a file transfer protocol, FTP, server with the
$ nc -vt 203.0.113.96 21 Connection to 203.0.113.96 21 port [tcp/ftp] succeeded! 220 (vsFTPd 2.0.5) $ QUIT 221 Goodbye.
nc reports success but does not allow you to send any commands, or you get a response from the service-daemon reporting the service is not available. In that case, you might have transmission control protocol wrappers, TCP wrappers, providing access control.
An FTP service being blocked by TCP wrappers could look like the following example:
$ nc -vt 203.0.113.96 21 Connection to 203.0.113.96 21 port [tcp/ftp] succeeded! 421 Service not available.
Programs that are compatible with TCP wrappers are compiled with
libwrap. To check if a program can use TCP
wrappers, use the following command:
$ ldd /path/to/binary | grep libwrap
The following example checks the
vsftpd program for the
libwrap shared-library file.
ldd /usr/sbin/vsftpd | grep libwrap libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f62c734a000)
If the program is not compatible with TCP wrappers, the preceding
grep command does not return anything.
A blocked connection produces a log entry. Check the program's logs for relevant messages.
vsftpd logs, found at /var/log/vsftpd.log, a blocked connection due to tcp wrappers looks like the following example:
Tue Jun 7 16:14:21 2011 [pid 28599] CONNECT: Client "203.0.113.43", "Connection refused: tcp_wrappers denial."
The /etc/hosts.deny file establishes the definition for blocked connections. If you have trouble seeing an entry for your service in the file, use
grep to search for it.
Search the file for the program name by running the following command:
$ sudo grep "vsftpd" /etc/hosts.deny vsftpd : ALL
Try commenting out any offending lines using a hash (#). Changes to this file take effect automatically—you don't need to restart any services.
Note that TCP wrappers allow a connection by default, so if it is the cause of the issue, there must be an entry in /etc/hosts.deny for the
service. You could rename the file /etc/hosts.deny to temporarily remove all your deny rules. For example, run
sudo mv /etc/hosts.deny /etc/hosts.deny.old. Note that this command affects all applications that use TCP wrappers. Don't forget to change it back after you finish your tests, if necessary.
If you have completed all the tests in this article without identifying any issues, the service is likely running
normally. The next step is to test the connectivity to the server by using
Updated 24 days ago