NOTE: there's allready a program called slurp, so I've changed the name to
slirp.  But don't panic, it's still pronounced the same.

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).


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
 while SLiRP is running.

* Since nothing needs to be compiled on the client side, it works with any OS
 that can talk SLIP/CSLIP (though, there are programs which you can compile
 on the client end if you want, just to make life easier)


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 (done)

* 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" (termify) 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)

* Tupload (working on it)

.. Advantages of SLiRP over TIA:

* Its free

* Comes with source

* Its free

* Comes with source

* Its free

* Comes with source

I'm sure there are other advantages, but those are the main ones :)

* CSLIP (can TIA do this?)

(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)

* Stability.  TIA is more mature than SLiRP. (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 on your 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. [I'm also
working on "talk", but it's not finished yet]

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 C class address. (Currently, 192.0.2.x)

All you need to do is telnet to 192.0.2.0, which will give you a
"command-line" where you can enter commands directly to SLiRP.  Most of the
config-file options are supported, the only ones that aren't are the ones
which would crash SLiRP (eg: increasing the MTU on-the-fly will crash SLiRP)

There are also aditional ones:

stats [ mbuf | ip | udp | tcp | udpsock | tcpsock ]

       Show statistics on [ ... ].

close N

       Close the session which has FD N.

kill N

       Kill the session which has FD N.

And others.  Type "help" to see them all (most).

Notes
-----

* Type "slirp -h" for a list of command-line options.

* The C class address 192.0.2.xxx is a special address to SLiRP.
 192.0.2.0 - SLiRP "command line"
 192.0.2.1 - An alias for the remote-host, -e and -p programs will be run
             on connection to the specified port.
 192.0.2.2 - An alias for the remote-host, but no -e, -p programs are
             executed.

 The difference between the last 2 are subtle, but distinct; for example,
 by default, when you telnet to 192.0.2.1 port 21 (telnet port) you'll
 automatically get a shell instead of a login prompt.  But if you telnet to
 192.0.2.2, you'll get the login prompt as offered by the remote-host.

* To quit SLiRP you simple kill your SLIP/CSLIP software then send 5 0's
 (zeros) down the line, with a 1/2 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).  (the -b BAUDRATE option has nothing to do with
 the actual baudrate, it's simply a guide for slirp so that interactive
 sessions are responsive)

* 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.

* PING does NOT yet work, so don't use ping to test the link.  Use
 telnet 192.0.2.0 instead.  This should give a "SLiRP command-line ready."
 message.  If not, then the link is not working.  If you can't telnet/ftp
 to a hostname, then your DNS entry is wrong.


How to contact the author
-------------------------

If you have any suggestions, additions, patches, questions, comments, liquor
you can e-mail me at [email protected].

You can ftp SLiRP updates and patches from blitzen.canberra.edu.au in
/put/slirp.

There's also a WWW page (under construction) at
http://blitzen.canberra.edu.au/~danjo.  I'll put the latest information on
SLiRP on this WWW page, so please check this page before e-mailing me.  (Of
course, if you need SLiRP to work to be able to use
Mosaic/Netscape/whatever, then you better e-mail me instead)

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.