Differences between version 7 and revision by previous author of NetCat.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 7 | Last edited on Wednesday, September 17, 2008 9:57:05 pm | by JimCheetham | Revert |
| Older page: | version 6 | Last edited on Sunday, August 28, 2005 2:12:05 am | by AristotlePagaltzis | Revert |
@@ -9,5 +9,156 @@
> 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 | http://netcat6.sourceforge.net/] to adds support for [IPv6] networks to the original utility.
-[
CLUG]
's wiki
has a [page
on NetCat
|http://clug
.net.nz/index
.php/netcat] with some examples
.
+---
+
+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 ...
+
+<verbatim>
+A$ echo "Hello" | nc -l -p 7777 > /tmp/reply
+
+B$ nc localhost 7777
+Hello
+</verbatim>
+
+after a couple of seconds to absorb the importance of the word "Hello", I'll type into stdin of B's netcat ...
+
+<verbatim>
+Greetings
+^D
+</verbatim>
+
+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 ...
+
+<verbatim>
+$ od -
a /tmp/reply
+0000000 G r e e t i n g s nl
+0000012
+</verbatim>
+
+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 ...
+
+<verbatim>
+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$
+</verbatim>
+
+We're also reminded by ChrisSawtell that there are multiple implementations of netcat out there :-
+
+<pre>
+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-.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..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.
+</pre>
+
+It appears [OpenBSD] has their own version that includes proxy support [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/]
+
+!!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 http://www.ists.dartmouth.edu/library/classroom/nc-intro.v0.80
.php :-
+> <verbatim>
+> mknod backpipe p
+> nc -l -p 80 <backpipe | tee -a inflow | nc localhost 81 | tee -a outflow 1>backpipe
+> <
/verbatim>
+
+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 -
+
+<verbatim>
+
+tcpdump -w - not (host workstation and port 31337) | nc workstation 31337
+
+</verbatim>
+
+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)
+
+<verbatim>
+
+nc -l -p 31337 | ethereal -i - -k -l
+
+</verbatim>
+
+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
.
