Linux Network Administrator's Guide, 2nd Edition By Olaf Kirch & Terry Dawson 2nd Edition June 2000 1-56592-400-2, Order Number: 4002 506 pages, $34.95

Chapter 7
Serial Line IP

Contents:
General Requirements
SLIP Operation
Dealing with Private IP Networks
Using dip
Running in Server Mode

Packet protocols like IP or IPX rely upon the receiver host knowing where the start and end of each packet are in the data stream. The mechanism used to mark and detect the start and end of packets is called delimitation. The Ethernet protocol manages this mechanism in a LAN environment, and the SLIP and PPP protocols manage it for serial communications lines.

The comparatively low cost of low-speed dialup modems and telephone circuits has made the serial line IP protocols immensely popular, especially for providing connectivity to end users of the Internet. The hardware required to run SLIP or PPP is simple and readily available. All that is required is a modem and a serial port equipped with a FIFO buffer.

The SLIP protocol is very simple to implement and at one time was the more common of the two. Today almost everyone uses the PPP protocol instead. The PPP protocol adds a host of sophisticated features that contribute to its popularity today, and we'll look at the most important of these later.

Linux supports kernel-based drivers for both SLIP and PPP. The drivers have both been around for some time and are stable and reliable. In this chapter and the next, we'll discuss both protocols and how to configure them.

General Requirements

To use SLIP or PPP, you have to configure some basic networking features as described in the previous chapters. You must set up the loopback interface and configure the name resolver. When connecting to the Internet, you will want to use DNS. Your options here are the same as for PPP: you can perform your DNS queries across your serial link by configuring your Internet Service Provider's IP address into your /etc/resolv.conf file, or configure a caching-only name server as described under "Caching-only named Configuration" in Chapter 6, "Name Service and Resolver Configuration."

SLIP Operation

Dialup IP servers frequently offer SLIP service through special user accounts. After logging in to such an account, you are not dropped into the common shell; instead, a program or shell script is executed that enables the server's SLIP driver for the serial line and configures the appropriate network interface. Then you have to do the same at your end of the link.

On some operating systems, the SLIP driver is a user-space program; under Linux, it is part of the kernel, which makes it a lot faster. This speed requires, however, that the serial line be converted to the SLIP mode explicitly. This conversion is done by means of a special tty line discipline, SLIPDISC. While the tty is in normal line discipline (DISC0), it exchanges data only with user processes, using the normal read(2) and write(2) calls, and the SLIP driver is unable to write to or read from the tty. In SLIPDISC, the roles are reversed: now any user-space processes are blocked from writing to or reading from the tty, while all data coming in on the serial port is passed directly to the SLIP driver.

The SLIP driver itself understands a number of variations on the SLIP protocol. Apart from ordinary SLIP, it also understands CSLIP, which performs the so-called Van Jacobson header compression (described in RFC-1144) on outgoing IP packets. This compression improves throughput for interactive sessions noticeably. There are also six-bit versions for each of these protocols.

A simple way to convert a serial line to SLIP mode is by using the slattach tool. Assume you have your modem on /dev/ttyS3 and have logged in to the SLIP server successfully. You will then execute:

# slattach /dev/ttyS3 &

This tool switches the line discipline of ttyS3 to SLIPDISC and attaches it to one of the SLIP network interfaces. If this is your first active SLIP link, the line will be attached to sl0; the second will be attached to sl1, and so on. The current kernels support a default maximum of 256 simultaneous SLIP links.

The default line discipline chosen by slattach is CSLIP. You may choose any other discipline using the -p switch. To use normal SLIP (no compression), you use:

# slattach -p slip /dev/ttyS3 &

The disciplines available are listed in Table 7.1. A special pseudo-discipline is available called adaptive, which causes the kernel to automatically detect which type of SLIP encapsulation is being used by the remote end.

Table 7.1: Linux Slip-Line Disciplines

Disclipline	Description
slip	Traditional SLIP encapsulation.
cslip	SLIP encapsulation with Van Jacobsen header compression.
slip6	SLIP encapsulation with six-bit encoding. The encoding method is similar to that used by the uuencode command, and causes the SLIP datagram to be converted into printable ASCII characters. This conversion is useful when you do not have a serial link that is eight bit clean.
cslip6	SLIP encapsulation with Van Jacobsen header compression and six-bit encoding.
adaptive	This is not a real line discipline; instead, it causes the kernel to attempt to identify the line discipline being used by the remote machine and to match it.

Note that you must use the same encapsulation as your peer. For example, if cowslip uses CSLIP, you also have to do so. If your SLIP connection doesn't work, the first thing you should do is ensure that both ends of the link agree on whether to use header compression or not. If you are unsure what the remote end is using, try configuring your host for adaptive slip. The kernel might figure out the right type for you.

slattach lets you enable not only SLIP, but other protocols that use the serial line, like PPP or KISS (another protocol used by ham radio people). Doing this is not common, though, and there are better tools available to support these protocols. For details, please refer to the slattach(8) manual page.

After turning over the line to the SLIP driver, you must configure the network interface. Again, you do this using the standard ifconfig and route commands. Assume that we have dialed up a server named cowslip from vlager. On vlager you would execute:

# ifconfig sl0 vlager-slip pointopoint cowslip
# route add cowslip
# route add default gw cowslip

The first command configures the interface as a point-to-point link to cowslip, while the second and third add the route to cowslip and the default route, using cowslip as a gateway.

Two things are worth noting about the ifconfig invocation: The pointopoint option that specifies the address of the remote end of a point-to-point link and our use of vlager-slip as the address of the local SLIP interface.

We have mentioned that you can use the same address you assigned to vlager's Ethernet interface for your SLIP link, as well. In this case, vlager-slip might just be another alias for address 172.16.1.1. However, it is also possible that you have to use an entirely different address for your SLIP link. One such case is when your network uses an unregistered IP network address, as the Brewery does. We will return to this scenario in greater detail in the next section.

For the remainder of this chapter we will always use vlager-slip to refer to the address of the local SLIP interface.

When taking down the SLIP link, you should first remove all routes through cowslip using route with the del option, then take the interface down, and send slattach the hangup signal. The you must hang up the modem using your terminal program again:

# route del default
# route del cowslip
# ifconfig sl0 down
# kill -HUP 516

Note that the 516 should be replaced with the process id (as shown in the output of ps ax) of the slattach command controlling the slip device you wish to take down.

Dealing with Private IP Networks

You will remember from Chapter 5, Configuring TCP/IP Networking, that the Virtual Brewery has an Ethernet-based IP network using unregistered network numbers that are reserved for internal use only. Packets to or from one of these networks are not routed on the Internet; if we were to have vlager dial into cowslip and act as a router for the Virtual Brewery network, hosts within the Brewery's network could not talk to real Internet hosts directly because their packets would be dropped silently by the first major router.

To work around this dilemma, we will configure vlager to act as a kind of launch pad for accessing Internet services. To the outside world, it will present itself as a normal SLIP-connected Internet host with a registered IP address (probably assigned by the network provider running cowslip). Anyone logged in to vlager can use text-based programs like ftp, telnet, or even lynx to make use of the Internet. Anyone on the Virtual Brewery LAN can therefore telnet and log in to vlager and use the programs there. For some applications, there may be solutions that avoid logging in to vlager. For WWW users, for example, we could run a so-called proxy server on vlager, which would relay all requests from your users to their respective servers.

Having to log in to vlager to make use of the Internet is a little clumsy. But apart from eliminating the paperwork (and cost) of registering an IP network, it has the added benefit of going along well with a firewall setup. Firewalls are dedicated hosts used to provide limited Internet access to users on your local network without exposing the internal hosts to network attacks from the outside world. Simple firewall configuration is covered in more detail in Chapter 9, TCP/IP Firewall. In Chapter 11, IP Masquerade and Network Address Translation, we'll discuss a Linux feature called "IP masquerade" that provides a powerful alternative to proxy servers.

Assume that the Brewery has been assigned the IP address 192.168.5.74 for SLIP access. All you have to do to realize that the setup discussed above is to enter this address into your /etc/hosts file, naming it vlager-slip. The procedure for bringing up the SLIP link itself remains unchanged.

Using dip

Now that was rather simple. Nevertheless, you might want to automate the steps previously described. It would be much better to have a simple command that performs all the steps necessary to open the serial device, cause the modem to dial the provider, log in, enable the SLIP line discipline, and configure the network interface. This is what the dip command is for.

dip means Dialup IP. It was written by Fred van Kempen and has been patched very heavily by a number of people. Today there is one strain that is used by almost everyone: Version dip337p-uri, which is included with most modern Linux distributions, or is available from the metalab.unc.edu FTP archive.

dip provides an interpreter for a simple scripting language that can handle the modem for you, convert the line to SLIP mode, and configure the interfaces. The script language is powerful enough to suit most configurations.

To be able to configure the SLIP interface, dip requires root privilege. It would now be tempting to make dip setuid to root so that all users can dial up some SLIP server without having to give them root access. This is very dangerous, though, because setting up bogus interfaces and default routes with dip may disrupt routing on your network. Even worse, this action would give your users power to connect to any SLIP server and launch dangerous attacks on your network. If you want to allow your users to fire up a SLIP connection, write small wrapper programs for each prospective SLIP server and have these wrappers invoke dip with the specific script that establishes the connection. Carefully written wrapper programs can then safely be made setuid to root.[1] An alternative, more flexible approach is to give trusted users root access to dip using a program like sudo.

[1] diplogin must be run as setuid to root, too. See the section at the end of this chapter.

A Sample Script

Assume that the host to which we make our SLIP connection is cowslip, and that we have written a script for dip to run called cowslip.dip that makes our connection. We invoke dip with the script name as argument:

# dip cowslip.dip
DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93)
Written by Fred N. van Kempen, MicroWalt Corporation.
connected to cowslip.moo.com with addr 192.168.5.74
#

The script itself is shown in Example 7.1.

Example 7.1: A Sample dip Script

# Sample dip script for dialing up cowslip
# Set local and remote name and address
        get $local vlager-slip
        get $remote cowslip
        port ttyS3                # choose a serial port
        speed 38400              # set speed to max
        modem HAYES              # set modem type
        reset                    # reset modem and tty
        flush                    # flush out modem response
# Prepare for dialing.
        send ATQ0V1E1X1\r
        wait OK 2
        if $errlvl != 0 goto error
        dial 41988
        if $errlvl != 0 goto error
        wait CONNECT 60
        if $errlvl != 0 goto error
# Okay, we're connected now
        sleep 3
        send \r\n\r\n
        wait ogin: 10
        if $errlvl != 0 goto error
        send Svlager\n
        wait ssword: 5
        if $errlvl != 0 goto error
        send knockknock\n
        wait running 30
        if $errlvl != 0 goto error
# We have logged in, and the remote side is firing up SLIP.
        print Connected to $remote with address $rmtip
        default                  # Make this link our default route
        mode SLIP                # We go to SLIP mode, too
# fall through in case of error
error:
        print SLIP to $remote failed.

After connecting to cowslip and enabling SLIP, dip will detach from the terminal and go to the background. You can then start using the normal networking services on the SLIP link. To terminate the connection, simply invoke dip with the -k option. This sends a hangup signal to dip, using the process ID dip records in /etc/dip.pid:

# dip -k

In dip's scripting language, keywords prefixed with a dollar symbol denote variable names. dip has a predefined set of variables, which will be listed below. $remote and $local, for instance, contain the hostnames of the remote and local hosts involved in the SLIP link.

The first two statements in the sample script are get commands, which is dip's way to set a variable. Here, the local and remote hostnames are set to vlager and cowslip, respectively.

The next five statements set up the terminal line and the modem. reset sends a reset string to the modem. The next statement flushes out the modem response so that the login chat in the next few lines works properly. This chat is pretty straightforward: it simply dials 41988, the phone number of cowslip, and logs in to the account Svlager using the password knockknock. The wait command makes dip wait for the string given as its first argument; the number given as its second argument makes the wait time out after that many seconds if no such string is received. The if commands interspersed in the login procedure check that no error occurred while executing the command.

The final commands executed after logging in are default, which makes the SLIP link the default route to all hosts, and mode, which enables SLIP mode on the line and configures the interface and routing table for you.

A dip Reference

In this section, we will give a reference for most of dip's commands. You can get an overview of all the commands it provides by invoking dip in test mode and entering the help command. To learn about the syntax of a command, you may enter it without any arguments. Remember that this does not work with commands that take no arguments. The following example illustrates the help command:

# dip -t
DIP: Dialup IP Protocol Driver version 3.3.7p-uri (25 Dec 96)
Written by Fred N. van Kempen, MicroWalt Corporation.
Debian version 3.3.7p-2 (debian).

DIP> help
DIP knows about the following commands:

        beep         bootp        break        chatkey      config       
        databits     dec          default      dial         echo         
        flush        get          goto         help         if           
        inc          init         mode         modem        netmask      
        onexit       parity       password     proxyarp     print        
        psend        port         quit         reset        securidfixed 
        securid      send         shell        skey         sleep        
        speed        stopbits     term         timeout      wait         

DIP> echo
Usage: echo on|off
DIP>

Throughout the following section, examples that display the DIP> prompt show how to enter a command in test mode and what output it produces. Examples lacking this prompt should be taken as script excerpts.

The modem commands

dip provides a number of commands that configure your serial line and modem. Some of these are obvious, such as port, which selects a serial port, and speed, databits, stopbits, and parity, which set the common line parameters. The modem command selects a modem type. Currently, the only type supported is HAYES (capitalization required). You have to provide dip with a modem type, or else it will refuse to execute the dial and reset commands. The reset command sends a reset string to the modem; the string used depends on the modem type selected. For Hayes-compatible modems, this string is ATZ.

The flush code can be used to flush out all responses the modem has sent so far. Otherwise, a chat script following reset might be confused because it reads the OK responses from earlier commands.

The init command selects an initialization string to be passed to the modem before dialing. The default for Hayes modems is "ATE0 Q0 V1 X1", which turns on echoing of commands and long result codes, and selects blind dialing (no checking of dial tone). Modern modems have a good factory default configuration, so this is a little unnecessary, though it does no harm.

The dial command sends the initialization string to the modem and dials up the remote system. The default dial command for Hayes modems is ATD.

The echo command

The echo command serves as a debugging aid. Calling echo on makes dip echo to the console everything it sends to the serial device. This can be turned off again by calling echo off.

dip also allows you to leave script mode temporarily and enter terminal mode. In this mode, you can use dip just like any ordinary terminal program, writing the characters you type to the serial line, reading data from the serial line, and displaying the characters. To leave this mode, enter Ctrl-].

The get command

The get command is dip's way of setting a variable. The simplest form is to set a variable to a constant, as we did in cowslip.dip. You may, however, also prompt the user for input by specifying the keyword ask instead of a value:

DIP> get $local ask
Enter the value for $local: _

A third method is to obtain the value from the remote host. Bizarre as it seems at first, this is very useful in some cases. Some SLIP servers will not allow you to use your own IP address on the SLIP link, but will rather assign you one from a pool of addresses whenever you dial in, printing some message that informs you about the address you have been assigned. If the message looks something like "Your address: 192.168.5.74", the following piece of dip code would let you pick up the address:

# finish login
wait address: 10
get $locip remote

The print command

This is the command used to echo text to the console from which dip was started. Any of dip's variables may be used in print commands. Here's an example:

DIP> print Using port $port at speed $speed
Using port ttyS3 at speed 38400

Variable names

dip understands only a predefined set of variables. A variable name always begins with a dollar symbol and must be written in lowercase letters.

The $local and $locip variables contain the local host's name and IP address. When you store the canonical hostname in $local, dip will automatically attempt to resolve the hostname to an IP address and to store it in the $locip variable. A similar but backward process occurs when you assign an IP address to the $locip variable; dip will attempt to perform a reverse lookup to identify the name of the host and store it in the $local variable.

The $remote and $rmtip variables operate in the same way for the remote host's name and address. $mtu contains the MTU value for the connection.

These five variables are the only ones that may be assigned values directly using the get command. A number of other variables are set as a result of the configuration commands bearing the same name, but may be used in print statements; these variables are $modem, $port, and $speed.

$errlvl is the variable through which you can access the result of the last command executed. An error level of 0 indicates success, while a nonzero value denotes an error.

The if and goto commands

The if command is a conditional branch, rather than a full-featured programming if statement. Its syntax is:

if var op number goto label

The expression must be a simple comparison between one of the variables $errlvl, $locip, and $rmtip. var must be an integer number; the operator op may be one of ==, !=, <, >, <=, and >=.

The goto command makes the execution of the script continue at the line following that bearing the label. A label must be the first word on the line and must be followed immediately by a colon.

send, wait, and sleep

These commands help implement simple chat scripts in dip. The send command outputs its arguments to the serial line. It does not support variables, but understands all C-style backslash character sequences, such as \n for newline and \b for backspace. The tilde character (~) can be used as an abbreviation for carriage return/newline.

The wait command takes a word as an argument and will read all input on the serial line until it detects a sequence of characters that match this word. The word itself may not contain any blanks. Optionally, you may give wait a timeout value as a second argument; if the expected word is not received within that many seconds, the command will return with an $errlvl value of 1. This command is used to detect login and other prompts.

The sleep command may be used to wait for a certain amount of time; for instance, to patiently wait for any login sequence to complete. Again, the interval is specified in seconds.

mode and default

These commands are used to flip the serial line to SLIP mode and configure the interface.

The mode command is the last command executed by dip before going into daemon mode. Unless an error occurs, the command does not return.

mode takes a protocol name as argument. dip currently recognizes SLIP, CSLIP, SLIP6, CSLIP6, PPP, and TERM as valid names. The current version of dip does not understand adaptive SLIP, however.

After enabling SLIP mode on the serial line, dip executes ifconfig to configure the interface as a point-to-point link, and invokes route to set the route to the remote host.

If, in addition, the script executes the default command before mode, dip creates a default route that points to the SLIP link.

Running in Server Mode

Setting up your SLIP client was the hard part. Configuring your host to act as a SLIP server is much easier.

There are two ways of configuring a SLIP server. Both ways require that you set up one login account per SLIP client. Assume you provide SLIP service to Arthur Dent at dent.beta.com. You might create an account named dent by adding the following line to your passwd file:

dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin

Afterwards, you would set dent's password using the passwd utility.

The dip command can be used in server mode by invoking it as diplogin. Usually diplogin is a link to dip. Its main configuration file is /etc/diphosts, which is where you specify what IP address a SLIP user will be assigned when he or she dials in. Alternatively, you can also use the sliplogin command, a BSD-derived tool featuring a more flexible configuration scheme that lets you execute shell scripts whenever a host connects and disconnects.

When our SLIP user dent logs in, dip starts up as a server. To find out if he is indeed permitted to use SLIP, it looks up the username in /etc/diphosts. This file details the access rights and connection parameter for each SLIP user. The general format for an /etc/diphosts entry looks like:

# /etc/diphosts
user:password:rem-addr:loc-addr:netmask:comments:protocol,MTU#

Each of the fields is described in Table 7.2.

Table 7.2: /etc/diphosts Field Description

Field	Description
user	The username of the user invoking dip that this entry will apply to.
password	Field 2 of the /etc/diphosts file is used to add an extra layer of password-based security on the connection. You can place a password in encrypted form here (just as in /etc/passwd) and diplogin will prompt for the user to enter the password before allowing SLIP access. Note that this password is used in addition to the normal login-based password the user will enter.
rem-addr	The address that will be assigned to the remote machine. This address may be specified either as a hostname that will be resolved or an IP address in dotted quad notation.
loc-addr	The IP address that will be used for this end of the SLIP link. This may also be specified as a resolvable hostname or in dotted quad format.
netmask	The netmask that will be used for routing purposes. Many people are confused by this entry. The netmask doesn't apply to the SLIP link itself, but is used in combination with the rem-addr field to produce a route to the remote site. The netmask should be that used by the network supported by that of the remote host.
comments	This field is free-form text that you may use to help document the /etc/diphosts file. It serves no other purpose.
protocol	This field is where you specify what protocol or line discipline you want applied to this connection. Valid entries here are the same as those valid for the -p argument to the slattach command.
MTU	The maximum transmission unit that this link will carry. This field describes the largest datagram that will be transmitted across the link. Any datagram routed to the SLIP device that is larger than the MTU will be fragmented into datagrams no larger than this value. Usually, the MTU is configured identically at both ends of the link.

A sample entry for dent could look like this:

dent::dent.beta.com:vbrew.com:255.255.255.0:Arthur Dent:CSLIP,296

Our example gives our user dent access to SLIP with no additional password required. He will be assigned the IP address associated with dent.beta.com with a netmask of 255.255.255.0. His default route should be directed to the IP address of vbrew.com, and he will use the CSLIP protocol with an MTU of 296 bytes.

When dent logs in, diplogin extracts the information on him from the diphosts file. If the second field contains a value, diplogin will prompt for an "external security password." The string entered by the user is encrypted and compared to the password from diphosts. If they do not match, the login attempt is rejected. If the password field contains the string s/key, and dip was compiled with S/Key support, S/Key authentication will take place. S/Key authentication is described in the documentation that comes in the dip source package.

After a successful login, diplogin proceeds by flipping the serial line to CSLIP or SLIP mode, and sets up the interface and route. This connection remains established until the user disconnects and the modem drops the line. diplogin then returns the line to normal line discipline and exits.

diplogin requires superuser privilege. If you don't have dip running setuid root, you should make diplogin a separate copy of dip instead of a simple link. diplogin can then safely be made setuid without affecting the status of dip itself.

Back to: Sample Chapter Index

Back to: Linux Network Administrator's Guide, 2nd Edition