Penguin
Recent Changes
Annotated edit history of NetCat version 7 showing authors affecting page license. View with all changes included.
Rev Author # Line
6 AristotlePagaltzis 1 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.
1 IanMcDonald 2
6 AristotlePagaltzis 3 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>.
1 IanMcDonald 4
6 AristotlePagaltzis 5 > 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.
4 CraigBox 6
6 AristotlePagaltzis 7 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/]".
5 CraigBox 8
6 AristotlePagaltzis 9 > 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.
5 CraigBox 10
6 AristotlePagaltzis 11 To complicate matters, there is also another rewrite called [netcat6 | http://netcat6.sourceforge.net/] to adds support for [IPv6] networks to the original utility.
5 CraigBox 12
7 JimCheetham 13 ---
14
15 From an email exchange on the CLUG List
16
17 >> 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 ...
18 >
19 >
20 > One connection or both connections? Because netcat always uses two...
21
22
23 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 ...
24
25 From "man nc"
26
27 > Your standard input is then sent
28 > to the host, and anything that comes back across the connection is sent
29 > to your standard output. This continues indefinitely, until the net-
30 > work side of the connection shuts down. Note that this behavior is
31 > different from most other applications which shut everything down and
32 > exit after an end-of-file on the standard input.
33
34
35 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.
36
37 > Dito for the client - perhaps the client doesn't want to send anything
38 > (</dev/null) and only receive - you can't do that currently, as the
39 > client buggers off faster than you can look.
40
41
42 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 ...
43
44 <verbatim>
45 A$ echo "Hello" | nc -l -p 7777 > /tmp/reply
46
47 B$ nc localhost 7777
48 Hello
49 </verbatim>
50
51 after a couple of seconds to absorb the importance of the word "Hello", I'll type into stdin of B's netcat ...
52
53 <verbatim>
54 Greetings
55 ^D
56 </verbatim>
57
58 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 ...
59
60 <verbatim>
61 $ od -a /tmp/reply
62 0000000 G r e e t i n g s nl
63 0000012
64 </verbatim>
65
66 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.
67 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.
68
69 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 ...
70
71 <verbatim>
72 A$ echo "hello" | nc -l -p 7777
73 Greetings
74 A$
75
76 (I've made my ^D characters visible below :-
77 B$ nc localhost 7777
78 hello
79 Greetings
80 ^D
81 More Stuff
82 ^D
83 B$
84 </verbatim>
85
86 We're also reminded by ChrisSawtell that there are multiple implementations of netcat out there :-
87
88 <pre>
89 On Fri, 13 Aug 2004 23:35, Volker Kuhlmann wrote:
90 On Fri 13 Aug 2004 10:43:35 NZST +1200, Christopher Sawtell wrote:
91 To my knowledge there are at least three netcats.
92
93 It appears that there is also some reason for SuSE to put their change
94 into the netcat they're shipping, and that that particular
95 implementation isn't totally cleanly implemented.
96 That's the case for the original l0pht one.
97
98 Can you recommend any other one(s)?
99 Gnu ~NetCat
100 http://netcat.sourceforge.net/
101 Local source mirror
102 ftp://ftp2.jetstreamgames/gentoo/distfiles/netcat-0.7.1.tar.bz2
103 I have built this one and I use it. It works.
104 Note that it's different from the original L0pht original.
105
106 Then there is another one created by an Australian by the name of Mark Pulford
107 http://www.kyne.com.au/~mark/software/ncat.php
108 http://www.kyne.com.au/~mark/software/ncat-1.0.1.tar.gz
109 I have not used this one. I merely know of its existence, but it's probably
110 well worth trying. I have used another of the author's tools successfully.
111
112 The Original L0pht ~NetCat:-
113 http://www.atstake.com/research/tools/network_utilities/
114 http://www.atstake.com/research/tools/network_utilities/nc110.tgz
115 Local mirror:-
116 ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/nc110.tgz
117 This is a 'Swiss Army Knife for the Internet".
118 It's a real double edged sword too.
119
120 There are lots of patches for it around, e.g.:-
121 ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/nc-v6-20000918.patch.gz
122 ftp://ftp2.jetstreamgames.co.nz/gentoo/distfiles/netcat-110-r6-gentoo-deb-patches.tbz2
123
124 I have used this one with both the patches applied.
125 It worked for me, but not under any difficult conditions, i.e. just moving
126 files across the local lan.
127 </pre>
128
129 It appears [OpenBSD] has their own version that includes proxy support [http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/]
130
131 !!Bidirectional netcat ...
132 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.
133
134 From http://www.ists.dartmouth.edu/library/classroom/nc-intro.v0.80.php :-
135 > <verbatim>
136 > mknod backpipe p
137 > nc -l -p 80 0<backpipe | tee -a inflow | nc localhost 81 | tee -a outflow 1>backpipe
138 > </verbatim>
139
140 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.
141
142 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.
143
144 On the remote machine -
145
146 <verbatim>
147
148 tcpdump -w - not (host workstation and port 31337) | nc workstation 31337
149
150 </verbatim>
151
152 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)
153
154 on the local machine (with ethereal)
155
156 <verbatim>
157
158 nc -l -p 31337 | ethereal -i - -k -l
159
160 </verbatim>
161
162 This again uses netcat to receive the data stream on port 31337 and feeds it to ethereal. Nifty huh?
163
164 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.

PHP Warning

lib/blame.php:177: Warning: Invalid argument supplied for foreach()