1. 28 Jun, 2002 1 commit
  2. 26 Jun, 2002 1 commit
  3. 11 Jun, 2002 1 commit
  4. 06 Apr, 2002 1 commit
    • Chad Barb's avatar
      Added SSL to capture (enabled with -DWITHSSL) · 2e536ba3
      Chad Barb authored
      To tip (or tiptunnel on a normal acl,) capture behaves the same.
      However, if a client connects and presents "USESSL" as the first six characters of their
      connection key, both sides initiate SSL negotiation.
      The server then attempts to get the key again. The second one is used for the check.
      SSL initialization is done on the first attempt by a client to connect via SSL.
      Capture assumes $(prefix)/etc/capture/cert.pem contains its certificate unless
      the '-c <certfile>' option is used.. if the certificate is not found or invalid, that
      connection fails, but normal connections will still succeed (and it will try to find the file
      again, next time an SSL connection is attempted.)
      On the client side, tiptunnel only uses ssl if there is a "ssl-server-cert:"
      property in the acl file. This is the SHA hash of the certificate that the capture server is
      expected to have (in hex.) If the certificate presented by the server does not hash to the
      same value, the connection is dropped.
  5. 05 Apr, 2002 1 commit
    • Chad Barb's avatar
      · 86c3a23a
      Chad Barb authored
      Added "fakie telnet" to tunnel; tells client to not act stupid (no local echo and no line-at-a-time,)
      and filters out client telnet replies so they don't blow the server's mind.
  6. 02 Apr, 2002 1 commit
    • Chad Barb's avatar
      · b05398fe
      Chad Barb authored
      Tiptunnel can now take "ssl-server-cert:" property from the ACL file,
      which is a SHA hash of the expected server certificate.
      (this is used to verify the server's identity,
      thus precluding man-in-the-middle attacks.)
      If no "ssl-server-cert:" is in the ACL,
      it will revert to using a normal TCP connection.
      In this version, authentication is still the same (even over SSL.)
      (next step: add SSL to capture server.)
  7. 29 Mar, 2002 1 commit
    • Chad Barb's avatar
      The tip tunnel.. · 025a6441
      Chad Barb authored
      Essentially tip, but instead of presenting a tty, it opens a tunnel port that (for instance)
      telnet can talk to. Example (on credit):
      tiptunnel /var/log/tiplogs/pc1.acl telnet
      Will open up a local port then fork/exec telnet with "localhost" and the tunnel port number as arguments.
      (Functionally equivalent to "tip pc1", only with telnet escape sequences)
      A later version of this program is what users will likely download for the quick-tip-through-the-web scheme.
      (next step: SSL)
  8. 29 Aug, 2001 1 commit
    • Leigh B. Stoller's avatar
      Fixup capture/tip/power_rpc27 so that capture returns a positive · ed55f418
      Leigh B. Stoller authored
      ack/nak for a connection so that the connecting process knows what the
      hell is going on. Turned out to be necessary for power control since
      we do that in parallel, and because it stays busy for 10 seconds on
      each power control. I think we will end up revisiting this at some
      point, adding blocking connections instead of connect/fail status.
  9. 20 Aug, 2001 1 commit
  10. 16 Aug, 2001 2 commits
  11. 14 Aug, 2001 1 commit
    • Leigh B. Stoller's avatar
      Move .acl file into tiplogs directory since nothing in /dev/tip · 3a67ca5f
      Leigh B. Stoller authored
      is actually used anymore.
      Added a "generic" entry to /etc/remote so that we do not need tip
      entries for each node; they all look the same anyway.
      Change tip to lookup up generic /etc/remote entry, just to make
      tip happy. The acl file comes from the tiplogs directory, as
      set in the header file.
  12. 13 Aug, 2001 1 commit
  13. 09 Aug, 2001 1 commit
  14. 31 Jul, 2001 1 commit
  15. 24 Jul, 2001 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint new version of capture/tip that is sockets based instead · 34499cb6
      Leigh B. Stoller authored
      of pty/tty based (since they have several annoying problems
      associated). Note that permission is granted via the use of an "acl"
      file; /dev/tip/machine.acl, which must be set to the group of the
      project the node is in, so the user can read out the process id number
      and the random bits that are used by capture to grant permission to
      use (tip sends the random bits across first thing). This handshake is
      due to change to a request/challenge scheme as described by Dave in
      email to the testbed list.
  16. 26 Jun, 2001 1 commit
  17. 05 Jan, 2001 2 commits
  18. 04 Jan, 2001 2 commits
  19. 02 Jan, 2001 1 commit
  20. 27 Dec, 2000 1 commit
    • Mike Hibler's avatar
      The Evisceration of Tip, Chapter 1. · 51f40ab4
      Mike Hibler authored
      Taken from the man page (ntip.1):
           Ntip differs from the traditional tip in a number of ways:
           1.   It does not support calling a remote system, all auto-dialing code
                has been removed.
           2.   All the cheezy file transfer support has been removed.
           3.   Most of the tilde escapes have been removed.  Mostly these were the
                file trasfer related ones.  See below for what remains.
           4.   Ntip ignores 90% of the remote(5) capabilities.  You can set the
                baud rate (br) and the device (dv).  Period.
           5.   All of tips variables are still present, but most don't do anything.
                It is left as an exercise to the interested user to differentiate.
           6.   By default, it operates in ``raw'' mode instead of the usual
                ``cbreak'' mode.  This means that all input processing (if any) is
                performed by the remote system.  Raw mode also disables
                ``raisechar'' and ``force'' variable interpretation.  Yes, you can
                actually run emacs on an ntip line (modulo the '~' thing).
           7.   Tip is the poster-child for fork-without-exec, creating separate
                reader and writer processes executing ``the same code.''  Ntip is a
                child of convenience and consists of a single process using
           8.   Ntip no longer uses uucp(1) style locking.  It relies on the TIOCEX-
                CL ioctl (see tty(4))  to provide ``reasonably mutually exclusive''
                access.  While it is still technically possible that two parties
                could open the same line and both get ``exclusive'' access to it, we
                consider this to be the source of amusing anecdotes rather than a
  21. 22 Dec, 2000 1 commit