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. If your only purpose is to use TCP/IP over a dialup, PPP has little advantage over SLIP. (PPP does have a checksum, which SLIP does not. However if your modem does error control -- and most modems that would be used with SLIP do -- that is probably not a major advantage. The sorts of errors that would likely get by the modem's error control will be caught by TCP/IP's checksums.) 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. I believe as of the net-2 release (with 0.99pl10), this is the preferred version. The file slip.instructions in this directory give instructions on how to set up SLIP with the 0.99pl10 kernel and the net2 utilities. 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. KA9Q seems to be the subject of much misunderstanding. It's been called a "emulation" or "not real TCP/IP". It's a completely real TCP/IP. Indeed at the moment it does a better job of conforming to the recommendings of the RFC's than the kernel-based TCP/IP does (though that's changing). However it's implemented as a user-mode program. This causes two disadvantages: - in theory there might be a performance penalty. However in practice (at least with SLIP) it is not visible, and I think I can show that the number of context swaps is no larger than with the kernel-based implementation. - more seriously, with KA9Q you don't have access to as many services. With the kernel-based implementation, people can write network programs, and as long as they use the socket interface correctly, you can use them. With KA9Q, all network code is in the KA9Q program itself. In order to add a service, you must add something to KA9Q. KA9Q has telnet, ftp, X, and a few other things, but it does not have the wide variety of software that's available for use with the kernel-based TCP/IP. The KA9Q version of telnet is fairly good (in some ways better than the telnet that comes with net-2). The FTP is mediocre. Note that it is possible to use KA9Q as a server. The Linux version doesn't do this, but some other Unix implementations do. If that is done, it's possible that the full range of network software could work with it. In that case it would look to the user just like a kernel-based implementation. However in doing thing this way, a performance penalty is introduced, since every packet has to activate both the KA9Q server and the actual application program. That (and difficulty of implementation) is the reason I did the more traditional KA9Q implementation. I regarded KA9Q as a temporary measure, until the kernel-based TCP/IP was ready. I think as of 0.99pl10, as long as you're willing to install my patches, I'd use the kernel-based version. If you are not willing to install patches, KA9Q will perform a lot better than the kernel version. (One remaining use for KA9Q is to support TCP/IP in amateur radio. That was the original reason it was written -- KA9Q is the author's call sign. KA9Q supports specialized radio interfaces that the kernel does not.) If 0.99pl10 is no longer the current release when you're reading this file, it's possible that these comments may be out of date. I'm hoping that the necessary patches will be integrated into the next release. Installation of kernel-based SLIP or 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 SLIP. 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. 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...)