6.4.1 slattach

The slattach command "attaches" the SLIP protocol to a specific serial interface. For example:

# 

slattach /dev/tty03 &

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:

slattach

 [

-h

 | 

-c

 | 

-6

] 

ttyname

 [

baudrate

]

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.

The baudrate argument sets the interface's transmission speed. Set the speed by entering a number that corresponds to the bit rate that is used to transmit and receive data on this line, e.g., 56000. Both ends of the line must set exactly the same bit rate. This may be determined by the characteristics of the leased line, or by the hardware interfaces for a direct cable connection. Regardless, the transmission speed is a physical characteristic limited by the equipment on the line. A default transmission speed of 9600 bits per second is used if no baudrate value is entered on the command line.

The ttyname is the name of the serial interface attached to the leased line or direct cable connection. The serial interfaces are identified by the system during the boot. dmesg and grep displays the interface names on a Slackware 96 Linux system:

> 
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 ttyname value on the slattach command. Notice that the slattach command identifies the physical serial device ( /dev/tty01 ) instead of the IP network interface ( sl0 ). That is because the SLIP IP interface does not exist until after slattach executes. The first slattach command creates the sl0 interface, the second creates the sl1 interface, and so on. slattach attaches a physical interface to the logical IP network.

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:

slattach

 [

-p 



protocol

] [

-s 



speed

] 

device

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.

6.4.2 Dial-Up IP

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 address. $locip and $rmtip are script variables used to identify the hosts at both ends of the link, which is analogous to the pointopoint parameter on the ifconfig command that we saw in the previous section. The two get statements set the local interface to the address 172.16.15.1 and the destination address to 172.16.15.3. SLIP does not have a standard way within the protocol to exchange addresses. We had to add specific local and remote IP addresses to the script.

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.

6.4.3 SLIP Server Configuration

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.

diplogin is used as the login shell for dial-in SLIP users. The system administrator puts diplogin in the /etc/passwd entry for each remote SLIP user as the user's login shell. For example:

craig:wJxX.iPuPzg:101:100:Craig Hunt:/tmp:/sbin/diplogin

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

user

A username. This is the key field against which a username from the /etc/passwd file or from an argument on the diplogin command line is matched.

password

An unencrypted password, the keyword s/key , or null (an empty field). If an unencrypted password is entered in this field, diplogin prompts the user for the password. This is in addition to the standard password from the /etc/passwd file that the user has already been required to enter. Because this second password is stored in an unencrypted format, it is not considered very secure. Sites that are big on security don't consider any reusable passwords secure enough to be meaningful, and sites that don't worry too much about security don't consider a second password necessary. For these reasons, the unencrypted password is rarely used. If this field contains the keyword s/key , diplogin invokes S/Key authentication. This requires that S/Key support is compiled into diplogin , and that S/Key is installed in your system. Because S/Key is a one-time password system, it's considered very secure. However, it is a headache for users and system administrators. See Chapter 12, Network Security for a full discussion of one-time passwords. If the password field is null, the authentication is left to login and the user is not asked for a second password.

remote-host

The hostname or IP address of the remote host; i.e., the computer from which the user is logging in.

local-host

The hostname or IP address of the local host; i.e., the computer on which this SLIP server is running.

netmask

The network mask for the serial interface written in dotted decimal notation, such as 255.255.0.0. If no value is provided the netmask defaults to 255.255.255.0, regardless of the class of addresses used on the network.

comment

A free-form comment field, similar to the gcos field in the /etc/passwd file.

protocol , mtu

The IP protocol and the maximum transmission unit used for this connection. Possible protocol values are SLIP, CSLIP, and PPP. The MTU is any valid transmission unit specified in bytes. The largest MTU used on SLIP lines is generally 1006 bytes. However, SLIP performance is often improved by smaller packet sizes. Common choices are 512 and 256.

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 .

6.4.4 Troubleshooting Serial Connections

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, minicom displays two header lines and then sends a Hayes command ( AT ) to the modem. We didn't set this command; it was part of the default minicom configuration. (If it causes problems, edit it out of the configuration using the menus discussed previously.) We then reset the modem ( atz ) and dial the remote server ( atdt ). When the modems connect, we log in to the server and configure it. (The login process is different for every remote server; this is just an example.) Everything appears to be running fine, so we end the connection by getting the modem's attention ( +++ ), hanging up the line ( ath ), and resetting the modem. Exit minicom by pressing CTRL-A followed by X. On our sample system the port and modem are working. If you cannot send simple commands to your modem, check that:

• The modem is properly connected to the port

• You have the correct cables

• The modem is powered up

• The modem is properly configured for dial-out and for echoing commands

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:

• The modem does not respond to the script. Check that you are using the correct device on the port command. Make sure that if the script contains databits , parity , speed , or stopbits commands that they are set to values compatible with your modem. Double-check that the modem is Hayes-compatible, particularly if you attempt to do modem configuration using dip keywords instead of using send .

• The modem fails to connect to the remote host. Make sure the modem is configured exactly as it was during the manual login. The modem's databits, parity, etc. need to match the configuration of the remote system. It is possible that you will need a special configuration, for example, 7-bit/even-parity, to perform the login before you can switch to the 8-bit/no-parity configuration required by PPP and SLIP. Don't forget to check that the phone number entered in the dial command is correct, particularly if the modem displays VOICE, RING - NO ANSWER, or BUSY when you expect to see CONNECT.

• The script hangs. It is probably waiting for a response. Make sure that the string in each wait command is correct. Remember that the string only needs to be a subset of the response. It is better to use the string " > " than it is to use " Port9> " if you are not sure whether the remote system always displays the same port number. Use a substring from the end of the expected response so that the script does not send to the server before the server is ready for input. Also try putting a delay into the script just before the script sends the first command to the server, e.g., sleep 2 to delay 2 seconds. A delay is sometimes needed to allow the server to initialize the port after the modems connect.

• The remote server displays an error message. The script probably sent an incorrect value. Check the string in each send command. Make sure they terminate with the correct carriage-return or line-feed combination expected by the remote server.

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:

# 

netstat -ni

 Name Mtu  Net/Dest     Address     Ipkts Ierrs Opkts Oerrs Collis Queue le0  1500 172.16.15.0  172.16.15.1      1     0    4     0      0     0 lo0  1536 127.0.0.0    127.0.0.1     1712     0 1712     0      0     0 ppp0 1006 172.16.15.26 172.16.15.3      0     0    0     0      0     0

The interface, ppp0 in the example, has been installed. The default command in the script creates a default route. Use netstat to see the contents of the routing table:

# 

netstat -nr

 Routing tables Destination      Gateway          Flags  Refcnt  Use Interface 127.0.0.1        127.0.0.1           UH      1    28      lo0 default          172.16.25.3          U      0     0      ppp0 172.16.15.0      172.16.15.1          U      21 1687      le0

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.