d15b30d891
Submitted by: lee dilkie <lee@dilkie.com> PR: ports/68272
146 lines
5.4 KiB
Groff
146 lines
5.4 KiB
Groff
.TH NC 1
|
|
.SH NAME
|
|
nc \- TCP/IP swiss army knife
|
|
.SH SYNOPSIS
|
|
.B nc
|
|
.I "[-options] hostname port[s] [ports] ..."
|
|
.br
|
|
.B nc
|
|
.I "-l -p port [-options] [hostname] [port]"
|
|
.SH "DESCRIPTION"
|
|
.B netcat
|
|
is a simple unix utility which reads and writes data across network
|
|
connections, using TCP or UDP 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. Netcat, or "nc" as the actual program is named, should
|
|
have been supplied long ago as another one of those cryptic but
|
|
standard Unix tools.
|
|
.P
|
|
In the simplest usage, "nc host port" creates a TCP connection to the
|
|
given port on the given target host. 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
|
|
network 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.
|
|
.P
|
|
Netcat can also function as a server, by listening for inbound
|
|
connections on arbitrary ports and then doing the same reading and
|
|
writing. With minor limitations, netcat doesn't really care if it
|
|
runs in "client" or "server" mode -- it still shovels data back and
|
|
forth until there isn't any more left. In either mode, shutdown can be
|
|
forced after a configurable time of inactivity on the network side.
|
|
.P
|
|
And it can do this via UDP too, so netcat is possibly the "udp
|
|
telnet-like" application you always wanted for testing your UDP-mode
|
|
servers. UDP, as the "U" implies, gives less reliable data
|
|
transmission than TCP connections and some systems may have trouble
|
|
sending large amounts of data that way, but it's still a useful
|
|
capability to have.
|
|
.P
|
|
You may be asking "why not just use telnet to connect to arbitrary
|
|
ports?" Valid question, and here are some reasons. Telnet has the
|
|
"standard input EOF" problem, so one must introduce calculated delays
|
|
in driving scripts to allow network output to finish. This is the
|
|
main reason netcat stays running until the *network* side closes.
|
|
Telnet also will not transfer arbitrary binary data, because certain
|
|
characters are interpreted as telnet options and are thus removed from
|
|
the data stream. Telnet also emits some of its diagnostic messages to
|
|
standard output, where netcat keeps such things religiously separated
|
|
from its *output* and will never modify any of the real data in
|
|
transit unless you *really* want it to. And of course telnet is
|
|
incapable of listening for inbound connections, or using UDP instead.
|
|
Netcat doesn't have any of these limitations, is much smaller and
|
|
faster than telnet, and has many other advantages.
|
|
.SH OPTIONS
|
|
.TP 13
|
|
.I \-g gateway
|
|
source-routing hop point[s], up to 8
|
|
.TP 13
|
|
.I \-G num
|
|
source-routing pointer: 4, 8, 12, ...
|
|
.TP 13
|
|
.I \-h
|
|
display help
|
|
.TP 13
|
|
.I \-i secs
|
|
delay interval for lines sent, ports scanned
|
|
.TP 13
|
|
.I \-l
|
|
listen mode, for inbound connects
|
|
.TP 13
|
|
.I \-n
|
|
numeric-only IP addresses, no DNS
|
|
.TP 13
|
|
.I \-o file
|
|
hex dump of traffic
|
|
.TP 13
|
|
.I \-p port
|
|
local port number (port numbers can be individual or ranges: lo-hi
|
|
[inclusive])
|
|
.TP 13
|
|
.I \-q seconds
|
|
after EOF is detected, wait the specified number of seconds and then
|
|
quit.
|
|
.TP 13
|
|
.I \-b
|
|
allow UDP broadcasts
|
|
.TP 13
|
|
.I \-r
|
|
randomize local and remote ports
|
|
.TP 13
|
|
.I \-s addr
|
|
local source address
|
|
.TP 13
|
|
.I \-t
|
|
enable telnet negotiation
|
|
.TP 13
|
|
.I \-e prog
|
|
specify program to exec after connect (use with caution)
|
|
.TP 13
|
|
.I \-u
|
|
UDP mode
|
|
.TP 13
|
|
.I \-v
|
|
verbose [use twice to be more verbose]
|
|
.TP 13
|
|
.I \-w secs
|
|
timeout for connects and final net reads
|
|
.TP 13
|
|
.I \-z
|
|
zero-I/O mode [used for scanning]
|
|
.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
|
|
in the hope that it will be useful, with no restrictions except giving
|
|
credit where it is due. No GPLs, Berkeley copyrights or any of that
|
|
nonsense. The author assumes NO responsibility for how anyone uses
|
|
it. If netcat makes you rich somehow and you're feeling generous,
|
|
mail me a check. If you are affiliated in any way with Microsoft
|
|
Network, get a life. Always ski in control. Comments, questions, and
|
|
patches to hobbit@avian.org.
|
|
.SH BUGS
|
|
Efforts have been made to have netcat "do the right thing" in all its
|
|
various modes. If you believe that it is doing the wrong thing under
|
|
whatever circumstances, please notify me and tell me how you think it
|
|
should behave. If netcat is not able to do some task you think up,
|
|
minor tweaks to the code will probably fix that. It provides a basic
|
|
and easily-modified template for writing other network applications,
|
|
and I certainly encourage people to make custom mods and send in any
|
|
improvements they make to it. Continued feedback from the Internet
|
|
community is always welcome!
|
|
.P
|
|
Some port names in /etc/services contain hyphens -- netcat currently
|
|
will not correctly parse those, so specify ranges using numbers if you
|
|
can.
|
|
.SH "SEE ALSO"
|
|
/usr/share/doc/netcat/README
|
|
.SH AUTHOR
|
|
This manual page was written by Joey Hess <joeyh@debian.org> and
|
|
Robert Woodcock <rcw@debian.org>, cribbing heavily from Netcat's
|
|
README file.
|
|
.P
|
|
Netcat was written by a guy we know as the Hobbit <hobbit@avian.org>.
|