4    Point-to-Point Connections

The Digital UNIX system supports point-to-point connections using the following protocols:

• Serial Line Internet Protocol (SLIP)

• Point-to-Point Protocol (PPP)

This chapter describes both environments, how to plan for both environments, how to configure your system for both environments, and how to manage both environments.

4.1    Serial Line Internet Protocol (SLIP)

The Serial Line Internet Protocol (SLIP) is a protocol used to run IP over serial lines between two hosts. You can connect the two hosts either directly or over telephone circuits using modems. TCP/IP commands (such as rlogin, ftp, and ping) can be run over the SLIP connection.

4.1.1    The SLIP Environment

In the SLIP environment, systems can be directly connected to each other, if they are in close proximity; or connected through modems and a telephone network, if they are not. Figure 4-1 shows both of these simple SLIP configurations. Figure 4-2 shows a SLIP connection between two systems, with HOSTB acting as a gateway system.

Figure 4-1: Sample Simple SLIP Configuration

Figure 4-2: SLIP Configuration With Gateway System

4.1.2    SLIP Planning

This section describes those tasks you need to do before configuring SLIP.

4.1.2.1    Verifying the Correct Hardware

In verifying the correct hardware, you are verifying both the cables and modems, if used.

Make sure you are using the correct cable to connect to the serial port of your system. If you do not, you might experience signal loss and the software will fail to function properly.

If the two systems are in close proximity to each other, use one of the null modem cables listed in Table 4-1.

Table 4-1: Types of Null Modem Cable

Table notes:

1. xx denotes the cable length. For example, BC29Q-10 is a ten-foot cable.

If the two systems are connected through modems and telephone lines, see Table 4-6 for a list of modem cables to use.

When using modems with SLIP, adhere to the following guidelines:

• Use modems that can handle a serial port speed of 38,400 bits per second (bps). If the modems you plan to use cannot handle a serial port speed of 38,400, you should set them to the highest baud rate to which they can be set.

• Use modems that are V.32bis compliant with V.42bis compression. Alternatively, you can use modems that support the Microcom Network Protocol (MNP) because both V.42bis and MNP implement a subset of the other protocol.

• Set the modems to 8 bits, no parity, and connect them to the telephone network.

• Use hardware control flow, if possible. High-speed modems often fall back to a lower data rate when line degradation occurs.

  Note

  Do not use software flow control (XON/XOFF). It will corrupt the data stream causing the TCP layer over IP to issue retransmit requests for overruns.

4.1.2.2    Preparing for the Configuration

After you verify the communication hardware, you set up the system to run SLIP. Appendix A contains a worksheet that you can use to record the information that you need to provide to configure SLIP. If you are viewing this manual online, you can use the print feature to print part of the worksheet.

Figure 4-3 shows Part 3A of the Configuration Worksheet. The following sections explain the information you need to record in Part 3 of the worksheet. Configuration Worksheet, Part 3A

Figure 4-3: Configuration Worksheet, Part 3A

Type of connection

Check hardwired if the two systems are connected by a null modem cable, such as Digital BC22D-xx. Check modem if the two systems are connected by modem cables, modems, and telephone network.

Type of system

Check dial-in if the system is to answer calls from remote systems. Check dial-out if the system is to place calls to a remote system.

Local IP address

Your system's SLIP interface IP address. Each SLIP interface must have an IP address. For more information on SLIP, see the Technical Overview and startslip(8).

Network mask

Your network's subnet mask. This must be the same for both systems. See Section 2.2 for more information on the network mask.

Destination IP address

The destination system's SLIP interface IP address.

TTY device name

The name of a valid terminal device in the /dev directory that has a cable connection. This can be either the full path name (for example, /dev/tty00) or the name in the /dev directory (for example, tty00). For more information on the terminal line specification, see startslip(8).

Baud rate

The serial port speed used to connect the systems to each other or a system and the modem. The default baud rate is 9600 bits per second. For more information on the baud rate, see startslip(8).

SLIP login information

The login information for the SLIP connection. This includes user name, password, and login sequence; for example, the login prompt used on dial-out connections.

startslip subcommands

For dial-out systems, Table 4-2 shows the minimum startslip subcommands to specify in a setup script file that you create. Table 4-3 shows the optional startslip subcommands.

Table 4-2: Basic startslip subcommands

Subcommand	Information Required
myip	Your system's IP address.
dstip	The destination system's IP address.
netmask	The network mask for the subnetwork.
hardwired	None. Specifies that the two systems are connected by a null modem cable.
modemtype	The type of modem used, unless you have a direct connection.
opentty	The serial line and line speed (baud rate from the worksheet).
dial	The telephone number to dial.
expect	The information that you expect to receive on the serial line; for example, login sequences.
send	The information that you want to send on the serial line.
connslip	Configured the network interface and attaches the serial line to the network interface.

Table 4-3: Optional startslip Subcommands

Subcommand	Description
debug	This generates debugging messages to the log file specified.
gateway	Specifies that the destination system is a gateway to another system on a LAN.
icmpsup	Suppresses Internet Control Message Protocol (ICMP) traffic. ICMP traffic (such as that generated by the ping command) is not permitted to be sent over the SLIP connection. This frees line bandwidth for more critical traffic.
tcpcomp	Compresses TCP headers before they are sent over the SLIP connection. Compressing the TCP header allows for faster data transfers. The remote system must support this option to decompress the headers when they arrive at the remote end.
tcpauto	The local system compresses TCP headers when it detects that the remote system is compressing them. This option can be useful if you do not know whether the remote system is doing TCP header compression. Note If the tcpauto option is enabled on both systems, TCP header compression does not occur. One of the two systems must explicitly enable TCP header compression.

See startslip(8) for a complete list of the startslip subcommands.

slhosts options

For dial-in systems, Table 4-4 shows a list of options for each SLIP link specified in the /etc/slhosts file.

Table 4-4: slhosts File Options

Subcommand	Description
debug	This generates debugging messages to the daemon.log file.
icmpsup	Suppresses Internet Control Message Protocol (ICMP) traffic. ICMP traffic (such as that generated by the ping command) is not permitted to be sent over the SLIP connection. This frees line bandwidth for more critical traffic.
tcpauto	The local system compresses TCP headers when it detects that the remote system is compressing them. This option can be useful if you do not know whether the remote system is doing TCP header compression. This is the default.
tcpcomp	Compresses TCP headers before they are sent over the SLIP connection. Compressing the TCP header allows for faster data transfers. The remote system must support this option to decompress the headers when they arrive at the remote end. Do not specify the tcpcomp and tcpauto options together.

See slhosts(4) for more information.

Gateway

For dial-in systems, if your system is to act as a gateway for a dial-out system to access the LAN, check YES; otherwise, check NO.

4.1.3    Configuring SLIP

To configure SLIP, you must have verified the correct communications hardware and completed the configuration worksheet. A system in a SLIP environment can have one of the following roles:

• Dial-in system

• Dial-out system

You edit some system files and use startslip to configure both dial-in connections and dial-out connections.

4.1.3.1    Configuring a Dial-In System

To configure a dial-in system, log in as root and complete the following steps:

1. Set up your modem for dial-in access. See Section 4.3.2 for more information.

   Note

   Digital recommends that you use a getty process for SLIP dial-in access.

2. Edit the /etc/passwd file and create a dedicated entry for a SLIP user. For the login shell field, specify /usr/sbin/startslip. The login name you specify here is used to find an entry in the /etc/slhosts file; for example:

   slip1:password:10:20:Remote SLIP User:/usr/users/guest:/usr/sbin/startslip"
   

3. Edit the /etc/slhosts file and create an entry for the login name using the information from the worksheet. The /etc/slhosts file entry has the following syntax:

   login_name remote_ip local_ip netmask option

   For example, if Host D is the dial-in system in Figure 4-1, the entry is as follows:

   slip1 1.2.3.6 1.2.3.5 255.255.255.0 nodebug
   

   See slhosts(4) for more information.

4. Edit the /etc/inittab file and create an entry for each terminal device that is to run SLIP. For example:

   modem:3:respawn:/usr/sbin/getty /dev/tty00 M38400 vt100
   

   See inittab(4) for more information.

5. Issue the init q command to start the getty process immediately.

6. If the dial-in system is going to be a gateway for the dial-out system to reach other systems on the LAN, the dial-in system must be configured as IP router and must also run gated. See Chapter 2 for basic network setup information.

If any problems occur while using SLIP, see Chapter 13.

4.1.3.2    Configuring a Dial-Out System

To configure a dial-out connection, log in as root and complete the following steps:

1. Verify that there is an entry for your modem name in the /etc/acucap file. If your modem does not have an entry in the /etc/acucap file, do the following:

   1. Copy an entry similar to that of your modem.

   2. Modify the modem attributes to match your modem's attributes. Set up the modem for dial-out access by including the AT commands listed in Table 4-5 in the synchronization string (ss) of the entry. The other modem settings can remain as they are.

      Table 4-5: Modem Commands for Dial-Out Access

      Command	Description
      at&c1	Normal Carrier Detect (CD) operation. Tells the modem to not raise Carrier Detect until it sees Carrier Detect from the other modem.
      at&d2	Normal Data Terminal Ready (DTR) operation. This is important in that it tells the modem to hang up the line when DTR drops; for example, when the user logs off the system.
      ate1	Turns on echoing.
      atq0	Displays the result codes.
      ats0=0	Does not answer the phone.

      In addition, include the debug option (db). With debugging turned on, the modem will provide you with additional information with which to tune the modem attributes in the file. See acucap(4) for more information.

2. If you use getty to provide access to the system from a modem and a getty process is already running, do the following:

   1. Edit the /etc/inittab file and change the the Action field of the modem entry from respawn to off as follows:

      modem:23:off:/usr/sbin/getty /dev/tty00 M38400 vt100
      

      See inittab(4) for more information.

   2. Issue the init q command to terminate the getty process.

3. Create a file that contains startslip subcommands for SLIP dial-out connections by doing the following:

   1. Copy the sample script file from the startslip(8) reference page to a new script file.

   2. Use the tip command to dial out and log in to the remote system, writing down the exact prompt and login sequence on the worksheet.

   3. Edit the script file; modify the expect subcommands with the prompt and login information; and modify other subcommands with information from the worksheet.

   Note

   The sample script file specifies the debug subcommand and a debug file name at the beginning of the file.

   See startslip(8) for a complete list of subcommands and a sample script file.

4. Invoke the startslip command with the -ifilename option. The filename is the name the file containing the startslip subcommands.

After making the connection, startslip runs in the background. The telephone number (if any) and the process ID are logged in the /var/run/ttyxx.tel-pid file.

If any problems occur while using SLIP, see Chapter 13.

4.1.4    Terminating a SLIP Dial-Out Connection

To terminate a SLIP dial-out connection, do the following:

1. Determine the process ID of the startslip process to kill by using the following command:

   #  cat /var/run/ttyxx.tel-pid
   

   phonenum  8021455  pid 821
   

   In the previous command, ttyxx specifies the terminal line used for the SLIP connection. If you have multiple SLIP connections active on your system, there will be multiple files in the /var/run directory.

2. Kill the startslip process by using the following command and specifying the Process ID returned in step 1:

   #  kill 821
   

Alternatively, you could also turn off your modem to terminate the dial-out connection.

4.2    Point-to-Point Protocol (PPP)

The Point-to-Point Protocol (PPP) provides a standard way to transmit datagrams over a serial link and a standard way for the systems at either end of the link (peers) to negotiate various optional characteristics of the link. Using PPP, a serial link can be used to transmit Internet Protocol (IP) datagrams, allowing TCP/IP connections between the peers.

The Digital UNIX PPP subsystem is derived from public domain ppp-2.2, and supports IP datagrams. See RFC1661, RFC1662, RFC1332, and RFC1334 for more information about PPP.

4.2.1    PPP Environment

The systems can be directly connected to each other, if they are in close proximity; or connected through modems and a telephone network, if they are not. Figure 4-4 shows two simple PPP configurations with PPP connections between two systems that are connected to each other.

Figure 4-4: Simple PPP Configurations

Figure 4-5 shows two PPP connections. The first is between host A and host B, with host B acting as a gateway system. The second is between personal computer E and host D through terminal server C. The latter configuration might be very common for employees working at home and dialing in to a work system.

Figure 4-5: Network PPP Configuration

4.2.1.1    PPP Options

When you invoke pppd you can specify PPP options on the command line. In addition, the following files on a system can contain PPP options:

• /etc/ppp/options -- System default options that are read before user default options and command line options. This file contains any options that you want pppd to use whenever it is run. If authentication is required, add the auth and usehostname options to this file.

  Note

  If the /etc/ppp/options file does not exist or is unreadable by pppd, the daemon will not run. Only root should be able to write to this file.

• $HOME/.ppprc -- User default options that are read before command line options.

See pppd(8) for a description of pppd options.

4.2.1.2    Authentication

PPP provides two protocols for authenticating hosts and for authenticating your host system to others:

• Password Authentication Protocol (PAP)

• Cryptographic Authentication Protocol (CHAP)

Both protocols exchange secrets in order to complete the authentication process. PAP secrets are contained in the /etc/ppp/pap-secrets() file; CHAP secrets are contained in the /etc/ppp/chap-secrets() file. Only root should be able to read these files. Both files have the following format:

client server secret [ip_address ...]

• client -- Name of the machine to be authenticated.

• server -- Name of the machine requiring the authentication.

• secret -- Password or CHAP secret known by both client and server.

• IP addresses -- Zero or more IP addresses that the client may use (this field is only used on the server).

For example, if a LAN-connected host named work requires authentication, and a host home connects to it and authenticates itself using CHAP, both machines should have a /etc/ppp/chap-secrets file that contains an entry similar to the following:

home	work	"an unguessable secret"	home.my.domain

Note

The /etc/ppp directory contains files of secrets used for authentication, and should not be in a partition that is exported using NFS and accessible by other hosts.

If authentication is required, the /etc/ppp/options file must contain the auth and usehostname options.

4.2.2    PPP Planning

This section describes those tasks you need to do before configuring PPP.

4.2.2.1    Verifying the Correct Hardware

Verify that you have the hardware to connect to the serial port of your system. If the two systems are in close proximity to each other, use one of the null modem cables listed in Table 4-1.

If the two systems are connected through modems and telephone lines, see Table 4-6 for a list of modem cables to use. The modems are set to 8 bit, no parity, and connected to the telephone network.

4.2.2.2    Verifying PPP Support in the Kernel

Verify that PPP is supported in the kernel by entering the following command:

#  sysconfig -s | grep ppp

If it is not loaded and configured, configure it by entering the following command:

#  sysconfig -c ppp

4.2.2.3    Preparing for Configuration

After you verify PPP support in the kernel, you configure PPP by performing a sequence of steps. Appendix A contains a worksheet that you can use to record the information that you need to provide to configure PPP. If you are viewing this manual online, you can use the print feature to print part of the worksheet.

Figure 4-6 shows Part 3B of the Configuration Worksheet. The following sections explain the information you need to record in Part 3 of the worksheet.

Figure 4-6: Configuration Worksheet, Part 3B

Local IP address

The local system's IP address. For Digital UNIX systems connected to a local area network (LAN), this is already assigned if you already configured your network software; it is the IP address of the LAN interface.

If you have a standalone system, you must assign it an IP address. If you are using PPP to link it to another host that is connected to the Internet, assign the local system an address that is on the same subnet as the remote host. If the other host is not connected to the Internet, assign the local system any IP address.

Remote IP address

The remote system's IP address.

TTY device name

The terminal line is the name of any valid terminal device in the /dev directory. This can be either the full path name (for example, /dev/tty01) or the name in the /dev directory (for example, tty01).

Baud rate

The baud rate of the modem (or null modem) used to connect the systems and the terminal line specification. If your modem automatically senses the line speed or if you are using a null modem cable between hosts, you can specify any rate up to the maximum supported by the hosts. This is usually 38400.

Level of Authentication

The level of authentication required. In general, if your system is connected to a LAN, you should require the remote host to authenticate itself and should restrict the remote host's choice of IP address, based on its identity. Otherwise, the possibility exists for a remote host to impersonate another host on the local subnet.

Note

If you are configuring PPP for the first time, do not enable authentication until you can successfully establish a link.

Type of authentication

If you are using PAP authentication, check PAP. If you are using CHAP authentication, check CHAP.

pppd options

Options to supply the pppd daemon. The following options might be useful:

• defaultroute -- If you system is standalone and you are connecting to the Internet through the remote system, add a default route via the remote host by specifying this option.

• asyncmap -- If the serial line is not completely 8-bit transparent, specify this option; asyncmap 200a0000 is appropriate if the serial link includes a telnet link.

• mru -- To improve performance for multiple IP connections, reduce the MRU (maximum receive unit) on the local and remote systems. Digital recommends that you specify the mru 296 option.

See pppd(8) for additional options.

4.2.3    Establishing a PPP Connection

After you have completed the PPP planning tasks, you can now establish a PPP connection between your local system and a remote system. Establishing a PPP connection between two systems basically involves setting up a serial link and running pppd on both ends of the link.

Guidelines for running pppd are as follows:

• If you want the local address of the PPP link to differ from the IP address for the local host's Ethernet or other broadcast interface, put the desired address on the pppd command line with a colon appended as follows:

  local_addr:
  

• Do not use ifconfig to configure the addresses of the ppp interface. The pppd daemon assigns addresses and identifies the interface as up.

• Whether you run pppd manually on the remote machine or use a script file on the local machine to run pppd on the remote machine, do not provide a device name to pppd; it uses the controlling tty by default.

Systems in a PPP environment can have the following roles:

• Dial-in system

• Dial-out system

4.2.3.1    Establishing a Dial-Out Connection Manually

To establish a dial-out connection manually, do the following:

1. Connect the modem by using the tip or kermit command.

2. Log in to the remote machine.

3. Invoke pppd with the passive option on the remote machine as follows:

   %  pppd passive
   

4. Exit tip or kermit without having the modem hang up.

5. Start pppd on your system, using a command similar to the following:

   %  pppd /dev/ttya 38400
   

   The pppd daemon runs in the background. The two pppd daemon's then negotiate and bring up the link. If you have edited /etc/syslog.conf, you will see messages from pppd giving the local and remote IP addresses of the link when it is successfully established.

If any problems occur while using PPP, see Chapter 13.

4.2.3.2    Establishing a Dial-Out Connection Automatically

You can use the chat program to automate any dialog that might be required in establishing a dial-out connection. Chat script dialog can include the user name and password with which to log in to the remote system and the command to start pppd on the remote system. To establish a dial-out connection automatically, do the following:

1. Create a chat script file that contains that dialog information you want. The chat script file entries are alternately strings to look for and strings to send. For example, the following file named /etc/ppp/chat-script contains the following information:

   "" atdt2135476[1]
   login: myname      [2]
   Password: "\qmypassword"    [3]
   "$ " "\qpppd"       [4]
   

   1. Sends a dial command to the modem. [Return to example]

   2. Looks for the login: string and sends the myname string. [Return to example]

   3. Looks for the Password: string and sends the mypassword string. The \q prevents chat from logging it when you use the -v option. [Return to example]

   4. Looks for $ (the shell prompt) and sends pppd to start the pppd daemon on the remote machine. The \q cancels the effect of the previous \q. [Return to example]

2. Issue a pppd command on the local system similar to the following to start a link on ttya:

   #  pppd /dev/ttya 38400 connect 'chat -f /etc/ppp/chat-script'
   

If any problems occur while using PPP, see Chapter 13.

4.2.3.3    Configuring Dial-In Connections

Instead of having callers start the pppd daemon after they log in to you system, you can create a user account dedicated solely for PPP connections. Do the following:

1. Edit the /etc/password file and create an login entry for PPP users; for example user ppp.

2. Specify a password, if you want.

3. Specify /usr/sbin/pppd as the login shell.

A sample /etc/passwd file entry for PPP is as follows:

ppp:password:10:20:Remote PPP User:/usr/users/guest:/usr/sbin/pppd

4.2.4    Terminating PPP Connections

To terminate terminate the PPP link, send a TERM or INTR signal to one of the pppd daemons by issuing the following command:

#  kill `cat /etc/ppp/pppxx.pid`

In the previous command, pppxx specifies the pppd used for the PPP connection. The pppd specified in the command informs any other related pppd daemons to terminate (clean up and exit).

If pppd is attached to a hardware serial port connected to a modem, it should get a HUP signal when the modem hangs up, which will cause it to clean up and exit. This depends on the driver and its current settings.

4.3    Guidelines for Using Modems

The Digital UNIX system enables you to use a variety of modems for point-to-point connections to systems that are not in close proximity to each other. These connections can be Serial Line Internet Protocol (SLIP), Point-to-Point Protocol (PPP), and UNIX-to-UNIX Copy Program (UUCP) connections. In addition, these connections can be basic dial-out/dial-in connection; for example, log in to a remote system to perform remote system administration.

This section presents general guidelines for using modems on Digital UNIX systems for all types of connections. See Chapter 4 and Chapter 9 for specific information on SLIP and PPP connections, and UUCP connections, respectively.

4.3.1    Using the Correct Modem Cables

In order to connect a modem to the serial port of your system, you must use the correct cable. If you do not, you might experience signal loss, resulting in the software not functioning properly. Table 4-6 lists the cables you should use. The cable connector is either 25-pin or 9-pin, depending on the type of serial port on your system. See the hardware documentation for your system if you are uncertain about the type of serial port.

Note

DECconnect cables do not provide a sufficient number of wires for full modem control. Digital recommends that you do not use them.

Table 4-6: Types of Modem Cable

Table notes:

1. xx denotes the cable length. For example, BC22E-10 is a ten-foot cable.

4.3.2    Configuring a System for Dial-In Access

After you have obtained the correct cable and connected your modem to it and the telephone network, do the following:

1. Edit the /etc/remote file and create an entry similar to the kdebug entry. For example, if your modem is connected to tty00 and you are going to use a baud rate of 38,400 to access the modem, create an entry similar to the following:

   b38400:dv=/dev/tty00:br#38400:pa=none
   

   Note

   Some modems set their baud rate to the serial port rate. Be sure to access the modem using the same baud rate that you are going to specify to getty or uugetty. Otherwise, you might not be able to log in because of a mismatch in baud rates.

2. Use the tip command to access the modem as follows:

   tip b38400
   

   The tip utility responds with a connected message. You can now communicate with the modem.

3. If your modem is using the AT command language, enter the following command:

   at[Return]
   

   If the modem is not in quiet mode, it responds with an OK message.

4. Set the modem up for dial-in access. Table 4-7 lists the AT commands required. Most of these command settings are the default settings.

   Table 4-7: Modem Commands for Dial-In Access

   Command	Description
   at&c1	Normal Carrier Detect (CD) operation. Tells the modem to not raise Carrier Detect until it sees Carrier Detect from the other modem.
   at&d2	Normal Data Terminal Ready (DTR) operation. This is important in that it tells the modem to hang up the line when DTR drops. For example, when the user logs off the system.
   atq1	Sets the modem to quiet mode. Result codes are not sent to the system.
   ate0	Echo off. This prevents modem from echoing back the login prompt issued by the getty process.
   ats0=n	Specifies the number of rings to wait before answering. If n = 0 (zero), the modem will not answer.
   at&w0	Saves the current modem settings in NVRAM.

   Digital UNIX supports both hardware and software flow control. If the system supports hardware flow control, set the modem and the serial line to use hardware flow control by using the appropriate commands. If hardware flow control is not supported, you should use software flow control.

5. Edit the /etc/inittab file and create an entry for the modem. If you want to use the modem line in non-shared mode, create an entry similar to the following:

   modem:23:respawn:/usr/sbin/getty /dev/tty00 M38400 vt100
   

   If you want to use the modem line in shared mode (for dial-out and dial-in connections), use uugetty instead of getty and create an entry similar to the following:

   modem:23:respawn:/usr/lib/uucp/uugetty -r -t 60 tty00 38400
   

   If you specify a baud rate greater than 9600, you must edit the /etc/uugettydefs file and create an entry for the speed you want.

   With uugetty, you will be able to use the tip and cu utilities, but might not be able to use third-party utilities because of differences in file locking.

   Note

   If you want to use the uugetty utility, you must install the UNIX-to-UNIX Copy Facility subset.

6. As root, start the getty or uugetty process by entering the following command:

   init q
   

   The getty or uugetty process starts, then goes to sleep, waiting for someone to dial into the system.

4.3.3    Configuring Your System for Dial-Out Access

After you have obtained the correct cable and connected your modem to it and the telephone network, do the following:

1. Verify that there is an entry for the modem name specified with the modemtype subcommand in the /etc/acucap file. If your modem does not have an entry in the /etc/acucap file, do the following:

   1. Copy an entry similar to that of your modem. The following entry is for a US Robotics modem for use in shared mode with tip:

      us|US|US Robotics (28.8 fax/data modem):\
            :cr:hu:ls:re:ss=AT\rATE1Q0&C0X0&A0\r:sr=OK:\
            :sd#250000:di=ATD:dt\r:\
            :dd#50000:fd#50:os=CONNECT:ds=\d+++\dATZ\r\dATS0=2\r:\
            :ab=\d+++\dATZ\r\dATS0=2:
      

   2. Modify the modem attributes to match your modem's attributes and include the debug option (db). With debugging turned on, the modem will provide you with additional information with which to tune the modem attributes in the file. See acucap(4) for more information.

2. Create an entry in the /etc/remote for the system you want to call. Among the information you can supply is the Digital UNIX device, baud rate, and /etc/acucap that defines your modem. The following two entries are for the modem specified in step 1a.

   tip38400:tc=us38400   [1]
   us38400|38400 Baud dial out via US Robotics modem:\   [2]
         :el=^U^C^R^O^D^S^Q@:ie=#%$:oe=^D:\   [3]
         :dv=/dev/tty00:br#38400:ps=none:at=us:du:      [4]
   

   1. Points to the us38400 entry specifying shared capabilities for modems. [Return to example]

   2. First line of the us38400 entry. [Return to example]

   3. Defines end-of-line characters, and input and output end-of-file marks. [Return to example]

   4. Defines the UNIX device to open for the connection, the baud rate, the parity, the name of the /etc/acucap entry, and the dial-up line. [Return to example]

   See remote(4) for more information.

3. If you use getty to provide access to the system from a modem and a getty process is already running, do the following:

   1. Edit the /etc/inittab file and change the the Action field of the modem entry from respawn to off as follows:

      modem:23:off:/usr/sbin/getty /dev/tty00 M38400 vt100
      

      See inittab(4) for more information.

   2. Issue the init q command to terminate the getty process.

4. Use the tip command, specifying the -baud_rate flag and the telephone number to dial out as follows:

   tip -38400 8881234
   

   In this example, tip strips off the minus sign (-) from the baud rate and concatenates the tip command name and the baud rate to create the string tip38400. Then, tip searches the /etc/remote file for the entry matching the string. The entry in the /etc/remote file, points the capability information in the us38400 entry to initialize the modem.

   By specifying the telephone number on the command line, you can share the same modem attributes for outgoing connections that have different telephone numbers.

   When you log off the remote system and exit tip, the modem's saved settings are restored, readying the modem for the next user. If used in shared mode, the modem is available for dial-in access.