NetCat is a tool for connecting stdin(3)/stdout(3) to a TCP/UDP connection, giving Shell scripts the power to excercise or even provide network services.

It was initially written for Unix by someone known only as Hobbit and released as public domain. Development of this tool continued up to version 1.10. nc(1) is the ManPage for this tool, and it can be installed on Debian using apt-get install netcat.

It is freely given away to the Internet community in the hope that it will be useful, with no restrictions except giving credit where it is due. No GPLs, Berkeley copyrights or any of that nonsense.

There is now a fully POSIX-compatible rewrite known as GNU Netcat. It is maintained by Giovanni Giacobbi and has been referred to as "netcat ran through indent".

Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP Protocol. It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities.

To complicate matters, there is also another rewrite called netcat6 to adds support for IPv6 networks to the original utility.


From an email exchange on the CLUG List

Without thinking too hard, I thought that was what the listener/server-end netcat was supposed to do ... quit when the connection to it dies ...

One connection or both connections? Because netcat always uses two...

Well, you might be using netcat for something I've not. The listener end of netcat will shut down when the client end closes the port, this is a given ... however, the client end does not by default close the port when it's stdin reaches EOF ...

From "man nc"

Your standard input is then sent to the host, and anything that comes back across the connection is sent to your standard output. This continues indefinitely, until the net- work side of the connection shuts down. Note that this behavior is different from most other applications which shut everything down and exit after an end-of-file on the standard input.

What do you mean, netcat always uses two connections? There's stdin and stdout, for sure, but only one network connection ... perhaps I'm thinking at a lower level than you are.

Dito for the client - perhaps the client doesn't want to send anything (</dev/null) and only receive - you can't do that currently, as the client buggers off faster than you can look.

OK, an example must be needed ... I'll start a listener that sends data (rather like a mail server sends out an identification message when you connect), and then connect to it ... Two sessions, A and B ...

A$ echo "Hello" | nc -l -p 7777 > /tmp/reply

B$ nc localhost 7777

after a couple of seconds to absorb the importance of the word "Hello", I'll type into stdin of B's netcat ...


B's netcat doesn't quit, even though I've sent EOF. A's netcat doesn't quit, either. /tmp/reply has been populated though, and I can see its contents from another session ...

$ od -a /tmp/reply
0000000   G   r   e   e   t   i   n   g   s  nl

I can put more stuff into B's netcat, and finally get fed up and terminate it with ^C ... at which point A's netcat listener terminates. The contents of /tmp/reply haven't changed, though, because the shell redirection has been 'completed' when the EOF at the end of "Greetings" was sent.

If I didn't redirect the netcat listener's stdout, there would still be a stop on output when the EOF came through ... this is what you would see from the shell sesion ...

A$ echo "hello" | nc -l -p 7777

(I've made my ^D characters visible below :-
B$ nc localhost 7777
More Stuff

We're also reminded by ChrisSawtell? that there are multiple implementations of netcat out there :-

On Fri, 13 Aug 2004 23:35, Volker Kuhlmann wrote:
On Fri 13 Aug 2004 10:43:35 NZST +1200, Christopher Sawtell wrote:
To my knowledge there are at least three netcats.

It appears that there is also some reason for SuSE to put their change
into the netcat they're shipping, and that that particular
implementation isn't totally cleanly implemented.
That's the case for the original l0pht one.

Can you recommend any other one(s)?
Gnu NetCat
Local source mirror
I have built this one and I use it. It works.
Note that it's different from the original L0pht original.

Then there is another one created by an Australian by the name of Mark Pulford
I have not used this one. I merely know of its existence, but it's probably
well worth trying. I have used another of the author's tools successfully.

The Original L0pht NetCat:-
Local mirror:-
This is a 'Swiss Army Knife for the Internet".
It's a real double edged sword too.

There are lots of patches for it around, e.g.:-

I have used this one with both the patches applied.
It worked for me, but not under any difficult conditions, i.e. just moving
files across the local lan.

It appears OpenBSD has their own version that includes proxy support

Bidirectional netcat ...

While netcat is excellent, one thing it doesn't seem to do is to work as a generic proxy between two applications. The shell doesn't help, providing only unidirectional pipelines ... but with the use of FIFO pipes (sorry, not under Cygwin) you can construct something that will do the job.

From :-

mknod backpipe p
nc -l -p 80 0<backpipe | tee -a inflow | nc localhost 81 | tee -a outflow 1>backpipe

You only have to do the mknod once, in order to create a pipe entity on the filesystem. Have a look in the files inflow and outflow to see the stored results of your conversation.

I just wanted to document a tip I found for using tcpdump and ethereal over a network. This might be because (for example) one box doesn't run ethereal due to resource restrictions or lack of X libraries.

On the remote machine -

tcpdump -w - not (host workstation and port 31337) | nc workstation 31337

This takes the out put of tcpdump and dumps it in a file, but the file is stdout (-w -). tcpdump is set to not log port 31337 on the workstation. stdout is then piped to netcat? which transmits it over port 31337 to workstation (thats why we are not logging port 31337 on workstation, or we would be logging ourselves logging ourselves logging infinitum)

on the local machine (with ethereal)

nc -l -p 31337 | ethereal -i - -k -l

This again uses netcat to receive the data stream on port 31337 and feeds it to ethereal. Nifty huh?

I have to give credit for this to Adam Boileau on the nzlug list, I thought it was so good I had to record it.