Usage:
         tcptunnel [-srv <server> | -human] [-port <port> | -inetd]
                   [-enc | -dec] [-uu] [-srvport <port>] [-pwait <n>]
                   [-help] [-debug] [-verbose <N>] [-keepalive] [-proxy <proxy>]

    <srv>       name of server to connect to
    <srvport>   port on server or proxy to connect to.  default: 23
    <port>      local port to listen for client, default: 12333
    <inetd>     run in inetd mode (client i/o is on stdin/stdout)
    <human>     you are the server (server i/o is on stdin/stdout)
    <proxy>     name of firewall proxy server.
    <enc>       client --> encode --> server
    <dec>       client --> decode --> server
    <uu>        use uuencode, not binary->hex
    <pwait>     wait n seconds to combine small packets into larger ones.
                use decimals, 0.1 is good.  default: 0
    <verbose>   print all data transmissions to stdout.  set to 1 or 2:
                -verbose 1    print all data as-is
                -verbose 2    translate non-printable characters to '.'
    <keepalive> restart after connection is closed (use ctrl-c to terminate)


A versatile tcp tunnel.  Uses:
- tunnelling through a firewall or proxy
- redirecting tcp connections to other ports or machines
- debugging tcp connections in-place
- packet sniffing


The tcptunnel listens on local port <port> and when
a connection is made it connects the other end of the tunnel as
follows:
a) With no proxy specified, it connects the other end
   to <srvport> on <srv>.
b) With a proxy, it connects to <srvport> on <proxy>.
   It then directs the proxy to telnet to <srv>, and
   then it connects the ends of the tunnel.


Example 1:
Debugging a web server <-> browser connection.  What to do:

browser <--> tunnel <--> web server

tcptunnel -srv www.foo.com -srvport 80 -port 7777 -verbose 2 -keepalive

in browser, hit port 7777 on the box where tcptunnel is running (either
localhost or the box with the web server)


Example 2:
A tunnel for SSH, which allows ssh to operate through a firewall
which only allows telnet connections and not SOCKS.  Furthermore,
the firewall responds to some escape sequences, so binary data
can't be sent without encoding it.  What to do:

ssh client <--> tunnel/enc <--> firewall <--> tunnel/dec <--> ssh server

The tunnel waits for an incoming connection from the ssh client,
then connects to the firewall's telnet service and instructs
it to telnet to the external server.  The external server also has
a tunnel, which picks up the firewall's telnet request and redirects
it to the ssh server.  the two tunnels encode/decode the binary traffic
also.

***** by dan goldwater (c)opyright 1999 *****