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 Hello
after a couple of seconds to absorb the importance of the word "Hello", I'll type into stdin of B's netcat ...
Greetings ^D
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 0000012
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 Greetings A$ (I've made my ^D characters visible below :- B$ nc localhost 7777 hello Greetings ^D More Stuff ^D B$
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 NetCatftp://ftp2.jetstreamgames/gentoo/distfiles/netcat-0.7.1.tar.bz2 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
It appears OpenBSD has their own version that includes proxy support http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/
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 http://www.ists.dartmouth.edu/library/classroom/nc-intro.v0.80.php :-
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 ourselves....ad 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.
No page links to NetCat.
