Theres hope for TIA users, read this about SLiRP!

John Babina (babina@CS.SunySB.EDU)
Wed, 22 Mar 1995 00:09:27 -0500


Check out this I got from a friend.. its a new TIA type program and it has
a feature that sounds like it will make CUSEEME work. We just need a CUSEEME
expert to write the patch they explain below.

Anyone out there know CUSEEMEs innards enough to do this?

-John

Forwarded message:
>
> (there's allready a program called slurp, so I've changed the name to slirp.
> give it some time to propagate through the source)
>
> NOTE: This is an ALPHA release! There WILL be bugs, so don't put your whole
> organisation's IP connectivity through it! (yet) :)
>
>
> What is SLiRP?
> --------------
>
> SLiRP is a SLIP/CSLIP emulator which allows a normal user with a shell
> account on a UNIX system to act like a SLIP/CSLIP account (a-la TIA).
> SLiRP can be (loosly) thought of as a cross between TIA and term (it's a
> SLIP-emulator, but comes with source, can redirect ports, etc.)
>
>
> Some of the features of SLiRP
> -----------------------------
>
> * It's free
>
> * It comes with source
>
> * The TCP/IP code is based on 4.4BSD which is widely regarded as a very
> stable and complete implementation. This means it does all the things
> expected of TCP implementations. eg: slow start, congestion avoidance,
> exponential backoff, round-trip-time calculation, delayed ACKs, Nagle
> algorithm, incoming and outgoing IP fragments, etc. etc. The TCP/IP code
> was actually taken from the excellent FreeBSD 2.0 sources. Infact, I went
> out of my way to do as little modification to it as possible. Most things
> that I regarded as unnecessary (eg: the rfc1323 performance enhancments)
> were simply commented out, so if you want to experiment with them, you can.
>
> * Because SLiRP is basically the 4.4BSD TCP/IP code in userland, you can
> easily experiment with the theories of TCP, it's performance etc. without
> having to recompile and reboot a kernel.
>
> * SLiRP can redirect ports, so, for example, even though you don't have a real
> address on the Internet (as with all SLIP-emulators) people can still ftp,
> telnet, etc. into your home machine.
>
> * Redirection doesn't require a seperately compiled program, like term does
> (with tredir). It can be done with either a configuration file, or telnet
> (provided your telnet can connect to a specified port.. and if can't, then
> what can I say... get a real OS! :)
>
> * Since nothing needs to be compiled on the client side, it works with any OS
> that can talk SLIP/CSLIP (tested on Windows, NetBSD and Linux only)
>
>
> Planned features:
>
> * PPP (I'm gonna steal FreeBSD 2.0's implementation, so it shouldn't take
> too long :)
>
> * Compression over a telnet session (One of the reasons I still occasionally
> use term)
>
> * trsh-like program, which lets you run multiple shells on the remote-host
> without the need to login multiple times (will be done through telnet).
>
> * tupload-like program, which will let you download/upload files without the
> need to login via ftp.
>
>
> A little more about SLiRP
> -------------------------
>
> SLiRP was written because of frustration with term's cumbersome way of
> emulating a net-connection (to be fair, term was never written for that
> purpose, it's a tribute to Bill Reimers it's come as far as it has), and
> with the lack of source and arcane licensing of TIA (lack of source being
> the main frustration).
>
> Here's a little comparison to put SLiRP in perspective:
>
> ... Advantages of SLiRP over term:
>
> * Only needs compilation on one side of the link (the remote side)
>
> * No need to "port" software
>
> * Can be used by non-UNIX users (DOS/Win/Mac/etc.)
>
> * Is more secure
>
> * Is easier to use by multiple users (since you're using the kernel's
> networking code, which is already multi-user (well, should be...))
>
> ... Advantages of term over SLiRP:
>
> * Compression (this is planned in SLiRP. Infact, I plan to "borrow" the
> compression code from term :)
>
> * Term has more complete emulation (see below)
>
> * Trsh, tupload (working on it)
>
> ... Advantages of SLiRP over TIA:
>
> * Comes with source
>
> * Its free
>
> * Comes with source
>
> * Its free
>
> * Comes with source
>
> * Its free
>
> I'm sure there are other advantages, but those are the main ones :)
>
> (Don't know enough about TIA to list anymore...)
>
> ... Advantages of TIA over SLiRP:
>
> * Support (although, most of the TIA FAQ's could in theory apply to SLiRP as
> well.. especially the DOS/Win/Mac FAQ's)
>
> * TIA has been ported to more OS's (working on it)
>
> (Don't know enough about TIA to list anymore...)
>
>
> How to run SLiRP
> ----------------
>
> First, compile SLiRP according to the instructions in the file INSTALL.
> Then all you need to do is run "slirp", quit your comms software (or disable
> it, or whatever) and run your SLIP/CSLIP software onyour home machine.
>
>
> Which programs do not work over SLiRP?
> --------------------------------------
>
> Any programs that bind() a port, then tell the other end of the connection
> where they should connect() to this bound port.
>
> For example: when you "get" a file during an ftp session, the ftp client
> bind()'s a socket, has a look at which port the socket is bound to, then
> tell's the ftp server the address and port of this socket (with the PORT
> command). The ftp server then connect()'s to this address/socket pair.
>
> Now, since your machine isn't really on the Internet, this connect() request
> will not arrive to your host, so it will not work.
>
> SLiRP emulates this by bind()ing it's own port on the server that *is* on
> the internet, and tells the ftp server about *that* address/socket pair.
> When the server connect()'s to it, SLiRP will then connect back to your
> machine.
>
> Currently, ftp (PORT) and irc (DCC SEND and DCC CHAT) are emulated, since
> these are the only programs I use which require this emulation.
>
> If you have a program that does not work with SLiRP, you can do one of 2
> things:
>
> * Find out the format of the "command" and write the code to do a similar
> type of translation as is currently done by SLiRP. See the funcions
> tcp_emu() and tcp_tos() to see how this is done.
>
> * If you can't do the above, and you have the sources to the program, you
> can recompile it with XXX included in the SLiRP package (XXX actually, I
> havn't written this yet..)
>
>
> How do I redirect a port?
> -------------------------
>
> Say you want to let your friend ftp to your home machine. Because your home
> machine isn't really on the Internet, they can't ftp into it directly. You
> need to redirect a port from the host machine (where SLiRP is running) to
> your home machine.
>
> There are 2 ways of doing this:
>
> 1) Put a line in your config file like the following:
>
> redir tcp [port to redirect] [your home IP address]:[port to redirect to]
>
> For example, if you want to redirect port 5000 to port 21 on your home
> machine (ftp port), and your home machine's IP is 123.123.123.123, you'd have:
>
> redir tcp 5000 123.123.123.123:21
>
> Now, your friend can "ftp host.SLiRP.is.running.on 5000" and she'll be
> ftp-ing to your home machine.
>
> The second way is shown below...
>
>
> Controlling SLiRP using telnet
> ------------------------------
>
> Redirection (and other misc. config stuff) can be done on the fly by
> telneting to a specific (hopefully unused) network class address.
> [currently, it's 1, but that *could* be used. You can change it with the -x
> command line option]
>
> The format is as follows:
>
> telnet CTL.COMMAND.HPORT.LPORT PORT
>
> Currently, CTL is 1.
>
> COMMAND depends on which command you want to do. Please read the file
> src/h/ctl.h for all the commands and their description. Some of the
> commands include:
> 10 = destroy a previously redirected TCP port
> 11 = redirect a TCP port
> 12 = redirect a TCP port, but only allow one connection
>
> HPORT and LPORT combine to set which port on your home machine to redirect
> to. If you are redirecting to a port < 256, then HPORT = 0. Otherwise the
> formula is (HPORT * 256 + LPORT).
>
> PORT is the port on the remote-host to redirect.
>
> Examples:
>
> To redirect port 5000 to your ftp port, as in the example above, do:
>
> telnet 1.11.0.21 5000
>
> Now anyone can ftp to your home machine by ftping to the host SLiRP is
> running on, port 5000.
>
> To redirect port 7000 to your X server (port 6000), do:
>
> telnet 1.11.23.112 7000
>
> (since 23*256 + 112 = 6000)
> (though, I honestly don't know if X works over SLiRP)
>
> To destroy the above redirection, do:
>
> telnet 1.10.23.112 7000
>
> etc.
>
> If PORT is 65535, SLiRP will bind any port it can, and report back to you
> which port it redirected.
>
> SLiRP will tell you wheather it succeeded or not by writing to the telnet
> connection, then close the connection.
>
> So, you should get a message something like:
>
> OK. Successfully redirected XXXX to AAA.BBB.CCC.DDD:ZZZZ.
>
> if it succeeded, or:
>
> ERROR. Failed to redirect TCP port XXX to YYY: [reason it failed]
>
> if it failed. (The redirection should always succeed if the PORT given was
> 65535)
>
> You may also use included program "slirpctl", which takes human-readable
> arguments, and does the above automatically. If your home machine is not
> Unix-like, you can compile slirpctl on the remote-host and use it with the
> -n argument, which will tell you exactly where to telnet to to execute the
> command requested. Type slirpctl -h for a list of arguments.
>
>
> Notes
> -----
>
> * Type "slirp -h" for a list of command-line options.
>
> * To quit SLiRP you simple kill your SLIP/CSLIP software then send 5 0's
> (zeros) down the line, with a 1 second pause between each.
>
> * The code to try and "guess" how much it can write to the modem is flakey.
> If you see that your modem isn't being used at it's maximum capacity (eg:
> an ftp session to the remote-host, the modem's RECEIVE light is not
> shining brightly all the time), you might want to increase the baudrate by
> using the -b BAUDRATE command-line option. If you choose a number which
> is far greater than the actuall baud rate, SLiRP will write to the modem
> as fast as the OS allows, hence you'll get the maximum bandwidth.
> However, there will be a noticable increase in lag for interactive data
> (eg: a telnet session).
>
> * SLiRP was written in an xterm which is 110x35 characters in size. I just
> had a look at portions of the source through an 80x25 character console. It
> is NOT pretty! :) Apoligies to the xterm-deficient.
>
> * You can choose any IP you wish for your home machine, except the following:
>
> - Any weird IP address which has some meaning to IP, like 255.255.255.255,
> 0.0.0.0, 127.0.0.1 (infact, all 127.xxx.yyy.zzz), etc., etc.
>
> - Do not choose an address which begens with SLiRP's CONTROL address. eg:
> by default SLiRP's CONTROL address is 1 so all address of the form
> 1.xxx.yyy.zzz are not permitted.
>
>
> How to contact the author
> -------------------------
>
> If you have any suggestions, additions, patches, questions, comments, liquor
> you can e-mail me at u923168@student.canberra.edu.au or
> danjo@freedom.wit.com (preffered)
>
> You can ftp SLiRP updates and patches from freedom.wit.com in
> /misc4/danjo/SLiRP.
>
> There's also a WWW page (under construction) on http://www.wit.com/~danjo/
>

_____________________________________________________________________________
John Babina III Computer Science Graduate Student, SUNY Stony Brook, NY USA
URL: http://godzilli.cs.sunysb.edu/~babina/ E-Mail: babina@cs.sunysb.edu