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.
From an email exchange on the CLUG List
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"
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.
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 ...
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 NetCat http://netcat.sourceforge.net/ Local source mirror ftp://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 http://www.kyne.com.au/mark/software/ncat.php http://www.kyne.com.au/mark/software/ncat-1.0.1.tar.gz 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:- http://www.atstake.com/research/tools/network_utilities/ http://www.atstake.com/research/tools/network_utilities/nc110.tgz Local mirror:- ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/nc110.tgz 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.:- ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/nc-v6-20000918.patch.gz ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/netcat-110-r6-gentoo-deb-patches.tbz2 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 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.
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?