From: hedrick@geneva.rutgers.edu (Charles Hedrick) Subject: Re: SLIP [FAQ editor: please note] Date: 13 Feb 1993 21:19:49 GMT
It seems like we get a question about every other day asking about
SLIP. Would the FAQ editor please add this?
cs911461@ariel.yorku.ca (CHRISTIAN D. ARMOUR) writes:
>As I have pretty much given up on ever getting term to work (a terrible
>shame but the docs are pretty bad :-( ), I'm now looking for a version
>of SLIP to port to Linux. Has this already been done? Where can it
>be found? I did a quick scan of tsx-11 but didn't find anything. If
>it's actually there, I'll feel pretty stupid but it's still worth asking.
SLIP is Serial-Line IP. It is an encapsulation of TCP/IP for asynch
lines. Most commonly it's used as a way to connect a system to a
TCP/IP network using a modem. With a complete implementation of SLIP,
your system can act as a full-scale Internet network host. The only
difference in principle between a SLIP connection and Ethernet is that
a serial-line is normally a lot slower than an Ethernet.
You may run into PPP ("Point to Point Protocol"). This is a newer
protocol than SLIP. It's somewhat more general-purpose: it can
support synchronous lines as well as async, and it can support
protocols other than TCP/IP. It can be used for the same things as
SLIP. But because it's more general, it is also a lot more complex
than SLIP. (Many of us think it's a typical committee product.) I
don't know of any PPP's for Linux, though someone may have a newer
version of KA9Q that supports PPP.
There are at least two implementations of SLIP for Linux. One has
SLIP code that works with the normal Linux kernel-based TCP/IP. If
you use this, then all the normal TCP/IP utilities will work over
SLIP. Unfortunately it is still in alpha. In order to use it, you
must subscribe to the SLIP channel. The code for it is on
tsx-11.mit.edu, but the information needed to get it is available only
via the SLIP channel. The reports I've seen so far suggest that this
should be used only by people who want to help the debugging effort.
The other implementation of SLIP is based on KA9Q. KA9Q is an
implementation of TCP/IP originally written for MS/DOS, to support
amateur radio use of TCP/IP. It has now been ported to Linux and
other Unix-like systems, as well as some other micros. It is
available for educational and personal non-commercial use. I am
responsible for one port of KA9Q to Linux. It is on tsx-11.mit.edu,
as binaries/usr.bin/ka9qbin.N.tar.Z for binary and
sources/usr.bin/ka9qsrc.N.tar.Z for source. N is a version number. I
believe there are ports of newer versions of KA9Q, which may have more
features. I haven't tried any of them and so can't say anything about
them.
ka9qbin.N.tar.Z contains a READ.ME that explains how to install it.
Installation of KA9Q -- or any other version of SLIP or PPP -- will
probably require either some understanding of TCP/IP or help from your
local network support staff. That's frustrating to some people,
because Linux users typically want to be self-supporting.
Unfortunately SLIP by its nature requires cooperation with somebody
else. Its purpose is to tie you into a network. Normally that
network is run by a campus or corporate group. You're going to need
them to set things up so that you can connect via SLIP, and you're
going to need some information from them in order to be able to
configure KA9Q.
If you control the machine at the other end, in theory you can put
SLIP up there yourself. There are SLIP implementations for most
versions of Unix, and I believe Multinet for VMS also supports it.
(However don't ask me where to get them, because I don't know.)
However even in this case, you should still coordinate with the group
that runs your network. You'll have to configure the machine running
SLIP as a router. Many network managers will tend to get violent if a
user suddenly starts running an unauthorized router.
Here are the strengths and weaknesses of this version of KA9Q:
strengths:
reliability -- I have fixed several problems, including bugs
in the generic header compression code from Berkeley.
performance -- it's been carefully tuned. If the system you
are talking to supports header compression, response at
9600 or faster feels as good via SLIP as with Kermit or
other normal communications packages. At 2400 it's
slow, but usable, as long as you have header compression.
Without header compression, don't even think about
speeds below 9600.
telnet implements a number of newer features, so ^S and ^Q
are interpreted locally, and ^C and ^O stop output
fairly quickly. This of course assumes that you are
running a current telnet daemon on the other end. (Many
vendors, including Sun, supply versions of the telnet daemon
that are years out of date.) Telnet lets you type special
telnet commands using ^^ followed by a letter. (It is
compatible with the telnet in Cisco's terminal servers.)
It does local line editing when talking to IBM systems.
In general I prefer its user interface and general
operation over Berkeley's telnet.
weaknesses:
everything is packaged in a single executable. You can have
several telnet sessions, ftp sessions, etc., but they'll
all be part of one program. You can get back to command
level in that program, switch between sessions, close
a session etc. But what you can't do is open a bunch
of X windows and run separate copies of telnet or FTP
in each window. (There's one exception: It does support
X, so if you start up xterm on a remote system, you will
get a separate X window.) This is not intrinsic to
the KA9Q architecture. It is possible to do a server
implementation that would support multiple applications.
I haven't done that because I thought we were going to
have a "real" kernel-based implementation shortly.
there's only a limited number of services: telnet, ftp, X,
finger, ping. I doubt that mail or other things (even
when present) actually work.
there's almost no incoming services. ftp works OK. finger
is sort of there, though not quite the way you might
expect. Incoming telnet gets you sort of a talk link.
In general, this code is well suited to the needs of a single-user
system, but not a server or multi-user system.
I am spending almost no time doing anything with KA9Q, because I
assume it will be replaced by the kernel TCP/IP shortly. (However
it's taking much longer for the kernel TCP/IP to stabilize than I had
hoped.) Someone is apparently planning continuing support of a newer
version of KA9Q for its amateur radio services.
When installing SLIP (or any other TCP/IP software, for that matter),
you may find it useful to have a general introduction to TCP/IP. I
have written two papers, which when taken together give you much of
the information you would need to configure a TCP/IP-based host or
network. They are available via anonymous FTP at cs.rutgers.edu, as
runet/tcp-ip-intro.doc and .ps, and tcp-ip-admin.doc and .ps. .doc is
straight text. .ps is Postscript. These papers have been fairly
widely distributed. (I recently noticed one of them on the SunSolve
CDROM, without a titlepage that would show where it came from -- the
only signs of my authorship are in a footnote about 1/3 of the way
through the document. And Sun has added a Sun copyright notice...)