Girish Venkatachalam is a UNIX hacker with more than a decade of
networking and crypto programming experience.
His hobbies include yoga,cycling, cooking and he runs his own
business. Details here:
More posts by Girish Venkatachalam.
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 world.
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. Simply running
$ 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:
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.
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.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Girish Venkatachalam © 2009-11-07 Girish Venkatachalam
An incompetent attorney can delay a trial for years or months. A competent attorney can delay one even longer. (Evelle J. Younger)