Basic troubleshooting with telnet and netcat
In the early years of computing,
telnet was used to connect to the command line on remote systems. SSH has replaced
telnet for remote access needs, and these days when you hear about
telnet, it is usually when somebody is using the client as a generic network troubleshooting tool.
That’s because, in troubleshooting sessions, sysadmins turn to
netcat to test connectivity to service offerings.
See what this process looks like for
[dminnich@dminnichlt tmp]$ telnet -4 www.redhat.com 80 Trying 126.96.36.199... Connected to www.redhat.com. Escape character is '^]'.
Here is a breakdown of the parameters:
-4means to use IPV4. This flag is not necessary but it made my logs prettier.
www.redhat.comis the hostname/IP address to connect to.
80is the port to connect to.
Connected to www.redhat.com line states that the connection was successful. This result means that the server is operational and there is nothing on the network (or any client or server machine) blocking this connection from happening.
You can exit out of
telnet by pressing Ctrl+] and then typing
^] telnet> quit Connection closed.
Here is an example of a failed connection in
[dminnich@dminnichlt tmp]$ telnet -4 www.redhat.com 21 Trying 188.8.131.52... telnet: connect to address 184.108.40.206: Connection timed out
Depending on how the remote network is configured, you may see a
Connection refused message immediately, or you may have to wait a while to get the
Connection timed out error. Alternatively, if
telnet sits there for a few seconds without any output, it is usually safe to assume that the connection will time out, so you can stop the connection attempt by doing a Ctrl+C.
When you see errors like this, it means that any of the following things are wrong:
- The server daemon isn’t running.
- The server itself isn’t up.
- A firewall rule is blocking the connection.
- There is no network route to the destination.
Now, look at this same process with Netcat (
ncat on Red Hat Enterprise Linux 8 and related distributions, abbreviated
nc). Here is an example of a successful connection using Netcat (Ctrl+C will exit the Netcat session:)
[dminnich@dminnichlt tmp]$ nc -w3 -4 -v www.redhat.com 80 Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Connected to 220.127.116.11:80.
-w3 says wait three seconds and then give up, which is a nice Netcat-native feature
telnet is missing.
Here is what a failed connection looks like in Netcat:
[dminnich@dminnichlt tmp]$ nc -w3 -4 -v www.redhat.com 21 Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Connection timed out.
Netcat also supports listening on ports for incoming connections, as well as basic port scanning and some other niceties. These features and the fact that lots of operating systems install Netcat but not
telnet by default are why some sysadmins are starting to use Netcat instead of
telnet for their troubleshooting needs.
Interacting with services
One final thing: Both of these tools can interact with the service offerings they connect to. If you type syntactically correct protocol messages and hit Enter, you will receive responses from the service. Here is an example:
[dminnich@dminnichlt tmp]$ nc -4 -w3 -v google.com 80 Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Connected to 18.104.22.168:80. GET / ... </body></html>
You may have to hit Enter a few times in the above example. Interacting with service offerings in this fashion gets complicated fast, especially when encryption comes into play, but if you need to test the internals of something—or if you don’t have a better protocol-specific tool like
curl around—you can make it work.