telnet is one of the first commands that one learns in one's UNIX
journey. Nowadays telnet is getting superseded by ssh. Other tools like
cat and ls make him feel at home though he is still tottering. It is a
long journey to comfort from being a newbie in the UNIX command line
UNIX command line utilities with their gazillion options and command
line switches account for the power and versatility of the OS. Command
line tools can be easily glued together in a shell script; they can be
interconnected with pipes which feed the previous output to the next
command and you can redirect the output to simple text files.
This process you can do ad infinitum and you reach a stage when the
existence of tools in the environment make you quite comfortable with
the UNIX ecosystem. These tools help you improve your productivity, help
you with complex programming tasks and most importantly help you
troubleshoot harrowing network problems.
Ask any sys admin and you will know how often the network messes up.
Every now and then we have worm attacks, traffic overloads, routing
issues, reachability problems, network slowness, ssh bruteforce attacks
and in addition to all of this the sys admin has to deal with Windows
viruses and malware.
Hard pressed for time, network administrators latch on to open source
tools and sometimes commercial GUI tools to make their lives simpler. As
you can clearly see, command line tools are useful not only for a newbie
to become quickly comfortable with the environment but also help
advanced network administrators deal with everyday problems.
Of all the tools that I have used so far netcat in short known as nc has
a very special place in my bag of tricks. Though socat is supposed to be more
powerful than netcat, I have hardly used it.
No, no. I am not biased against socat. Certainly not. I have not had a
chance to realize its value yet. That is all.
netcat with its simple and yet incredibly powerful command line
constructs has helped me innumerable times to validate TCP and UDP end
to end connectivity.
What do I mean by that?
The practical problems I have had to face mostly involved certain TCP or
UDP ports being closed in between, packets getting dropped in firewalls
and so on. Usually the problem is on one of the endpoints. But a very
simple test involving netcat can quickly get the message across that
there is a problem.
Of course you can argue that you can do the same thing with telnet too.
$ telnet 192.168.1.5 80
will tell us if a HTTP server is listening at port 80 in 192.168.1.5.
nc will do the same thing with
$ nc -v 192.168.1.5 80
You can run a TCP server on 192.168.1.3 with
$ nc -l -p 1234
and you can connect to it from another machine by
$ nc 192.168.1.3 1234
Now you can type at one end and see that printed on the other end.
This is an example of basic usage of this tool.
Now I will give you one more basic example.
You can run a UDP server with
$ nc -l -u -p 1234
and you can connect to it from another machine by
$ nc -u 192.168.1.3 1234
Very simple. At the same time very powerful too. You can even instrument
UDP holepunching technique documented here with netcat. You can
specify the local port to bind to and remote port to connect to with a
single command line. Do this at both ends and you find that you can chat
between two machines behind two NAT devices. This is a very advanced use
but the command lines used are not at all cryptic.
I mainly used nc for debugging these two situations:
Proving that a certain UDP or TCP port is closed
Finding out whether there is proper routing happening
between two IP addresses
Once again I used the same command line as above to test connectivity.
You can find whether a port is open or closed by using the verbose
switch(-v). It won't take more than a few seconds to find out even on
very slow bandwidth lines.
Finding out end to end connectivity and IP routing particularly with
port forwarding/redirections can be really easy when you use netcat in
conjunction with tcpdump. netcat will
send the TCP handshake packets and tcpdump will show the destination and
source IP addresses. If they are not getting rewritten properly or if
packets do not get responded to, then you know there is a problem.
It is invaluable in such situations. But netcat is not limited to
debugging routing problems. I will wrap up with some of the features
of netcat that I think will arouse your curiosity to use netcat.
Some interesting features of netcat
Outbound and inbound connections, TCP or UDP, to or from any ports.
Built-in port-scanning capabilities, with randomizer.
Advanced usage options, such as buffered send-mode (one line every N
seconds), and hexdump (to stderr or to a specified file) of transmitted
and received data
(Not available on BSD)
Simple file transfers using UNIX file redirection
Did you know you could stream audio or video on linux without any configuration? Note that this is a push model. So we have to start the streaming client first. This is what you have to do. On the streaming client, setup the listener.
$ nc -l -p 1234 | mplayer -cache 8192 -
This will wait for media from the network to play.
On the streaming server, push the media data (any mplayer playable file) thusly.
$ cat video.mpg | nc <ip/dns of streaming client> 1234
This is doing a lot of injustice to this marvelous tool since I listed
only the most basic features. There are many more.