Home
Main website
Display Sidebar
Hide Ads
Recent Changes
View Source:
NetCat
Edit
PageHistory
Diff
Info
LikePages
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 <i>Hobbit</i> 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 <tt>apt-get install netcat</tt>. > 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 [GPL]s, [Berkeley copyrights | BSDLicense] or any of that nonsense. There is now a fully [POSIX]-compatible rewrite known as [GNU Netcat | http://netcat.sourceforge.net/]. It is maintained by Giovanni Giacobbi and has been referred to as "[netcat ran through indent|http://mike.filespanker.com/post/67/]". > 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. --- 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-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. </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 0<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.
No page links to
NetCat
.
