Package: netcat
Version: 1.10-33
Severity: wishlist
I suggest some examples be added, such as the following.
- Jim Van Zandt
--- debian/nc.1.old 2007-11-08 21:46:08.000000000 -0500
+++ debian/nc.1 2007-11-08 22:28:39.000000000 -0500
@@ -111,6 +111,53 @@
.TP 13
.I \-z
zero-I/O mode [used for scanning]
+.SH EXAMPLES
+.SS Simple File Transfer
+Netcat can be used as a simple data transfer agent, and it doesn't really
+matter which end is the listener and which end is the client -- input at one
+side arrives at the other side as output. It is helpful to start the listener
+at the receiving side with no timeout specified, and then give the sending side
+a small timeout. That way the listener stays listening until you contact it,
+and after data stops flowing the client will time out, shut down, and take the
+listener with it. Unless the intervening network is fraught with problems,
+this should be completely reliable, and you can always increase the timeout. A
+typical example of something "rsh" is often used for: on one side,
+
+ nc -l -p 1234 | uncompress -c | tar xvfp -
+
+and then on the other side
+
+ tar cfp - /some/dir | compress -c | nc -w 3 othermachine 1234
+
+will transfer the contents of a directory from one machine to another, without
+having to worry about .rhosts files, user accounts, or inetd configurations
+at either end. Again, it matters not which is the listener or receiver; the
+"tarring" machine could just as easily be running the listener instead. One
+could conceivably use a scheme like this for backups, by having cron-jobs fire
+up listeners and backup handlers [which can be restricted to specific addresses
+and ports between each other] and pipe "dump" or "tar" on one machine to "dd
+of=/dev/tapedrive" on another as usual. Since netcat returns a nonzero exit
+status for a denied listener connection, scripts to handle such tasks could
+easily log and reject connect attempts from third parties, and then retry.
+.SS Encrypted File Transfer
+.\" example courtesy of Tom Buskey <[EMAIL PROTECTED]>
+Suppose you have an ssh tunnel, and you want to copy a file to the
+remote machine. You could just scp it directly, but that opens up
+another connection. The goal is to re-use the existing connection.
+You can use netcat to do this:
+
+When you SSH in, add -L 31000:127.0.0.1:31000
+
+On the remote:
+
+ nc -lvnp 31000 127.0.0.1 > file
+
+On the local:
+
+ nc -v -w 2 127.0.0.1 31000 < file
+
+No extra overhead. TCP takes care of error correction. SSH has already
+encrypted the pipe.
.SH COPYRIGHT
Netcat is entirely my own creation, although plenty of other code was
used as examples. It is freely given away to the Internet community
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'testing'), (500,
'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.17 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages netcat depends on:
ii libc6 2.6.1-5 GNU C Library: Shared libraries
netcat recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
