Installing Serial Line IP (SLIP) is very similar to installing PPP. As with PPP, support for SLIP is usually installed in the kernel - but that is only part of the configuration. The SLIP network interface also must be configured.
PPP and SLIP configuration is complicated by the fact that these serial line protocols support both dedicated and dial-up connections. For our Linux sample system, this means that two different commands are used to configure a SLIP interface depending on whether it is a dedicated or a dial-up connection. In this section we discuss both, beginning with the configuration command for dedicated connections.
This command tells the SLIP protocol to use /dev/tty03 as its serial interface. The slattach command can optionally set some configuration parameters for the serial interface. The syntax of slattach on a Slackware 96 Linux system is:
The three options, -h , -c , and -6 , select the type of SLIP protocol used. -h selects uncompressed SLIP with full headers. CSLIP with Van Jacobsen header compression is selected with -c . Use -6 to select six-bit SLIP. If none of these options is selected, the slattach command defaults to CSLIP.
> dmesg | grep tty tty00 at 0x03f8 (irq = 4) is a 16550A tty01 at 0x02f8 (irq = 3) is a 16550A tty03 at 0x02e8 (irq = 3) is a 16550A
This list of serial interface names is from a PC running Linux. Assume we
connect the direct connection cable to tty01, which is equivalent to
the MS-DOS interface COM2. In that case, use tty01 as the
Like ifconfig , the slattach command is stored in a startup file. It configures the serial interface when the system boots, and the interface remains dedicated to SLIP use unless some action is taken to detach it, i.e., the slattach process is killed. On a Slackware 96 Linux system the following commands might be added to the /etc/rc.d/rc.inet1 file to configure a dedicated SLIP connection:
slattach -c /dev/tty01 19200 & ifconfig sl0 macadamia pointopoint cashew route add default cashew 1
The pppd dedicated line configuration requires only one command. The slattach command needs an ifconfig command and a route command to complete the configuration. The route command is explained in Chapter 7, Configuring Routing .
The slattach command declares that the physical serial device /dev/tty01 is the SLIP network interface. In essence this creates the interface sl0. The ifconfig command configures the newly created SLIP interface. It sets the address of the interface to the IP address of host macadamia . Further, it says that the destination address of this interface is the IP address of the host cashew at the far end of the dedicated SLIP link. The IP addresses for both macadamia and cashew should be in the local hosts file before this ifconfig command is executed.
The examples in this section all use the syntax of the slattach command that comes with Slackware 96 Linux. SLIP commands are not standardized. The command that comes with your system will probably have a different syntax; carefully read your system's documentation so you'll know the exact syntax used on your system. For example, other versions of Linux use this syntax:
Here the various SLIP protocols are selected with the -p option. The acceptable protocol values are: slip , cslip , slip6 , cslip6 , and adaptive . If adaptive is selected, the system tries to determine which protocol is acceptable to the remote system. The -s option sets the line speed, e.g., -s 56000 . The device is one of the call units configured on the system. Examples of valid call unit device names are cua0, cua1, cua2, cua3, etc. The device names from cua0 to cua3 correspond to the MS-DOS devices COM1 to COM4. A call unit is normally associated with dial communications.
slattach expects the physical connection to the remote system to exist when slattach is invoked. The physical connection can be a direct connection, a leased line, or a dial line. But if a dial-up connection is used, some process, such as cu or tip , must establish the physical connection before slattach is invoked. As we have seen, dip is a command that is specifically designed to support dial-up IP connections.
Earlier in this chapter we used dip to create a dial-up PPP connection. dip can also be used for SLIP. It is actually quite simple. A slight modification of the dip script used earlier creates a SLIP link. The following script connects a PC named macadamia to a SLIP server named cashew :
# Set the local and remote addresses get $locip 172.16.15.1 get $rmtip 172.16.15.3 # Select the port and set the line speed port cua1 speed 38400 # Reset the modem and flush the terminal reset flush # Dial the SLIP server and wait for the CONNECT response dial *70,301-555-1234 wait CONNECT # Wait 2 seconds for the remote server to get ready sleep 2 # Send a carriage-return to wake up the server send \r # Wait for the Login> prompt and send the username wait ogin> send kristin\r # Wait for the Password> prompt and send the password wait word> password # Wait for the SLIP server's command line prompt wait > # Send the command required by the SLIP server send set cslip enabled\r # Select the SLIP interface as the default route default # Set the interface to CSLIP mode mode CSLIP # Exit the script exit
Modifications to a few lines from the PPP script were required to create a SLIP dial-up script. Obvious changes replace the remote server's PPP command with a SLIP command and change the mode command in the script to invoke SLIP instead of PPP. We also added some new lines to perform tasks for SLIP that PPP can do on its own.
The script begins by setting the local IP address and the remote IP
The default statement near the end of the script says that the SLIP connection is the local system's default route. Since SLIP is most often used to connect small isolated systems into the network, this is usually true. This statement performs the same function as the route command in the slattach example or the defaultroute option in the /etc/ppp/options file.
So far, we have used dip to establish a dial-in SLIP link to a remote server. dip can also provide the server side of a SLIP connection. The -i option sets dip to input mode, which configures the system to act as a dial-in server. An alternative, and more popular, way to invoke dip with the -i option is to use the diplogin command. diplogin is symbolically linked to the dip command and is exactly the same as specifying dip with the -i option. We'll use diplogin throughout this section.
login verifies the username and password, assigns the user /tmp as a home directory and starts his login shell. In this case the shell is diplogin .
The diplogin program then tries to find an entry for the user in the /etc/diphosts file. It searches for the username that was entered during the login process unless that username is overridden by another directly on the diplogin command line. For example: when the /etc/passwd entry shown above starts diplogin , the username craig is used to search the /etc/diphosts file. Conversely, in the /etc/passwd entry shown below, the username essex that appears after the diplogin command is used for the search.
hunt:AbxdkiThinR:102:100:Rebecca Hunt:/tmp:/sbin/diplogin essex
The format of entries in the /etc/diphost file is:
user : password : remote-host : local-host : netmask : comment : protocol , mtu
Assuming the two /etc/passwd entries shown above, we might have an /etc/diphosts file with the following entries:
craig::cashew:macadamia:255.255.255.240:Craig Hunt:CSLIP,512 essex::essex:macadamia::Remote client essex.nuts.com:PPP,1006
When the login authenticates the user craig , it starts diplogin as the login shell. diplogin finds the entry for craig , does not prompt for a second password, sets the local address to macadamia and the remote address to cashew , and starts a CSLIP server using an MTU of 512. However, if the user hunt logs into the system, login starts diplogin with the username essex . The /etc/diphosts entry for essex starts a PPP server with a local address of macadamia , a remote address of essex and an MTU of 1006. The essex entry allows the netmask to default to 255.255.255.0. The servers started by diplogin run until the modem hangs up the connection.
Clearly dip is more than just a chat script. It provides client and server support for a variety of protocols. See Appendix A for more information about dip .
There are several layers of complexity that make PPP and SLIP connections difficult to debug. To set up PPP and SLIP, we must set up the serial port, configure the modem, configure PPP or SLIP, and configure TCP/IP. A mistake in any one of these layers can cause a problem in another layer. All of these layers can obscure the true cause of a problem. The best way to approach troubleshooting on a serial line is by debugging each layer, one layer at a time. It is usually best to troubleshoot each layer before you move on to configure the next layer.
The physical serial ports should be configured by the system during the system boot. Check the /dev directory to make sure they are configured. On a Linux system the in-bound serial ports are /dev/ttyS0 through /dev/ttyS3 and the out-bound serial ports are /dev/cua0 through /dev/cua3 . There are many more tty* and cua* device names. However, the other devices are only associated with real physical devices if you have a multi-port serial card installed in your Linux system. Most UNIX systems use the names tty* and cua*, even if those names are just symbolic links to the real devices. Solaris 2.5.1 is a good example:
% ls -l /dev/tty? lrwxrwxrwx 1 root root 6 Sep 23 1996 /dev/ttya -> term/a lrwxrwxrwx 1 root root 6 Sep 23 1996 /dev/ttyb -> term/b % ls -l /dev/cua/* lrwxrwxrwx 1 root root 35 Sep 23 1996 /dev/cua/a -> /devices/obio/zs@0,100000:a,cu lrwxrwxrwx 1 root root 35 Sep 23 1996 /dev/cua/b -> /devices/obio/zs@0,100000:b,cu
If the serial devices do not show up in the /dev directory, they can be manually added with a mknod command. For example, the following commands create the serial devices for the first serial port on a Linux system:
# mknod -m 666 /dev/cua0 c 5 64 # mknod -m 666 /dev/ttyS0 c 4 64
However, if you need to add the serial devices manually, there may be a problem with the kernel configuration. The serial devices should be installed in your system by default during the boot.
The modem used for the connection is attached to one of the serial ports. Before attempting to build a dial-up script, make sure the modem works and that you can communicate with it through the port. Use a simple serial communications package, such as minicom , kermit , or seyon . First, make sure the program is configured to use your modem. It must be set to the correct port, speed, parity, number of databits, etc. Check your modem's documentation to determine these settings.
We'll use minicom on a Linux system for our examples. To configure minicom , su to root and run it with the -s option, which displays a configuration menu. Walk through the menu and make sure everything is properly set. One thing you might notice is that the port is set to /dev/modem . That device name is sometimes symbolically linked to the port to which the modem is connected. If you're not sure that the link exists on your system, enter the correct port name in the minicom configuration, e.g., /dev/cua1 . After checking the configuration, exit the menu and use the minicom terminal emulator to make sure you can communicate with the modem:
Minicom 1.71 Copyright (c) Miquel van Smoorenburg Press CTRL-A Z for help on special keys AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 OK atz OK atdt555-1234 CONNECT 26400/LAPM-V ^M Enter login> kristin Enter user password> Wats?Watt? Welcome to the PPP MODEM POOL PORT-9> set port ppp enabled +++ OK ath OK atz OK ^A CTRL-A Z for help | 38400 8N1 | NOR | Minicom 1.71 1995 | VT102 | Offline X
In the sample,
displays two header lines and then sends a
Hayes command (
When the modem responds to simple commands, use it to dial the remote server as we did in the example above. If the modem fails to dial the number or displays the message NO DIALTONE, check that the telephone line is connected to the correct port of the modem and to the wall jack. You may need to use an analog phone to test the telephone wall jack and you may need to replace the line between the modem and the wall to make sure that the cable is good. If the modem dials but fails to successfully connect to the remote modem, check that the local modem configuration matches the configuration required by the remote system. You must know the requirements of that remote system to successfully debug a connection. See the following list of script debugging tips for some hints on what to check. If you can successfully connect to the remote system, note everything you entered to do so, and note everything that the modem and the remote server display. Then set the remote server to PPP or SLIP mode and note how you accomplished this. You will need to duplicate all of these steps in your dip script.
Start with a bare-bones script, like the sample start-ppp.dip script, so that you can debug the basic connection before adding the complexity of error processing to the script. Run the script through dip using the verbose option ( -v ) option. This displays each line of the script as it is processed. Look for the following problems:
If you have trouble with the script, try running dip in test mode ( -t ), which allows you to enter each command manually one at a time. Do this repeatedly until you are positive that you know all the commands needed to log in to the remote server. Then go back to debugging the script. You'll probably have fresh insight into the login process that will help you find the flaw in the script.
Once the script is running and the connection is successfully made, things should run smoothly. You should be able to ping the remote server without difficulty. If you have problems they may be in the IP interface configuration or in the default route. The script should have created the serial interface. The netstat -ni command shows which interfaces have been configured:
The contents of routing tables are explained in detail in the next chapter. For now, just notice that interface used for the default route is ppp0, and that the default route is a route to the remote PPP server (172.16.25.3 in the example).
If the script creates the connection, the interface is installed, and the routing table contains the default route, everything should work fine. If you still have problems they may be related to other parts of the TCP/IP installation. Refer to Chapter 11, Troubleshooting TCP/IP , for more troubleshooting information.