Modem Access

Modem Access

The service access facility (SAF) is a port management system that manages requests and responses for access to system ports. In this case, a port is defined as the physical connection between a peripheral device and the system. For example, most systems have one or more serial ports that allow for sequential data transmission, effectively down a single line. In contrast, a parallel port allows for several lines of data to be transmitted bidirectionally. The SAF system is designed to allow requests to be made to the system from peripheral devices through ports and ensure that these requests are appropriately serviced by the relevant port monitor.

Modems, which allow Solaris 9 systems to connect to the Internet over a phone line, require SAF to operate through system serial ports. Thus, it’s important to understand how to configure ports, port monitors, and listeners in preparation for making an Internet connection using a modem. Note that most Solaris systems are never accessed through a modem; however, if a system’s only network card has died and the console is physically inaccessible, a modem can be a lifesaver.

The Point-to-Point Protocol (PPP) daemon is commonly used to set up modem access to an Internet service provider (ISP). PPP supports TCP/IP and provides the Challenge Handshake Authentication Protocol (CHAP), providing a higher level of security than usually found on modem links. The PPP daemon relies on the chat program to perform the dial-up and handle connections. In this section, we’ll examine how to set up port monitors and PPP for Internet connections.

Port Monitors

Central to the idea of providing services through serial ports is the port monitor, which continuously monitors the serial ports for requests to log in. The port monitor doesn’t process the communication parameters directly, but accepts requests and passes them to the operating system. Solaris 9 uses the ttymon port monitor, which allows multiple concurrent getty requests from serial devices.

To configure the port for a terminal, start up admintool and enter the user mode, which can be either Basic, More, or Expert. In most cases, Basic setup will be sufficient . admintool allows the configuration of most parameters for the port, including the baud rate for communications, default terminal type, flow control, and carrier detection. The values entered here should match those on the matching VT-100 terminal. Once the settings have been saved, it is possible to check the validity of the settings by using the pmadm command:

# pmadm -l -s ttyb

The Service Access Facility (SAF)

The process that initiates the service access facility is known as the service access controller (/usr/lib/saf/sac). It is started when the system enters run level 2, 3, or 4, as shown in this /etc/inittab entry:

sc:234:respawn:/usr/lib/saf/sac -t 300

Here, the respawn entry indicates that if a process is not running when it should be, it should be respawned. For example, if a system changes from run level 2 to run level 3, sac should be running. If it is not present, it will be restarted.

When sac is started, it reads the script /etc/saf/_sysconfig, which contains any local configurations tailored for the system. Next, the standard configuration file /etc/saf/_sactab is read, and sac spawns a separate child process for each of the port monitors it supports (ttymon and listen). A sample _sactab is shown here:

# VERSION=1
zsmon:ttymon::0:/usr/lib/saf/ttymon #

Port monitors also read a configuration file (/etc/saf/zsmon/_pmtab) that is used to configure the ttymon and listen port monitors. A sample _pmtab file is shown here:

# VERSION=1
ttya:u:root:reserved:reserved:reserved:/dev/term/a:I::
/usr/bin/login::9600:ldterm,ttcompat:ttya login\: ::tvi925:y:#
ttyb:u:root:reserved:reserved:reserved:/dev/term/b:I::
/usr/bin/login::9600:ldterm,ttcompat:ttyb login\: ::tvi925:y:#

The point of this hierarchical configuration file structure is that values read from /etc/saf/_sysconfig and /etc/saf/_sactab by sac are inherited by the spawned port monitor processes, which then have the ability to configure their own operations.

The SAF has two types of port monitors: the terminal port monitor (ttymon) and the network port monitor (listen). For example, the ttymon port monitor for the console is started in run levels 2, 3, and 4, through an /etc/inittab entry like the following:

co:234:respawn:/usr/lib/saf/ttymon -g -h -p
    "`uname -n` console login: " -T vt100 -d
    /dev/console -l console -m ldterm,ttcompat

The ttymon process is active when a monitor is connected to a server, such as a dumb terminal, rather than a graphics monitor.

Point-to-Point Protocol (PPP)

PPP is the most commonly used protocol for connecting modems over a phone line (or, uncommonly, over a normal serial line) to support TCP/IP. It replaces the earlier Serial Line Interface Protocol (SLIP), which did not provide any level of security or authentication for serial line services. The Solaris 9 implementation of PPP is based on the ANU version (ftp://cs.anu.edu.au/pub/software/ppp). PPP provides reliable access to the Internet because it includes error correction and the ability to autodetect some network parameters. All of the parameters for the PPP daemon (pppd) are stored in /etc/ppp/options. Alternatively, for options that are specific to each serial port, a new configuration file can be created (such as /etc/ppp/options.cua.a for the serial port /dev/cua/a). This is useful where two modems are connected to the two standard serial interfaces on a SPARC system that are connected to two separate modems, which in turn dial completely different ISPs—the lesson for high availability is to “be prepared” for the worst-case scenario. Supporting network operations through a 56K modem is going to be challenging, but not impossible, in an emergency. Figure 17-2 shows a PPP configuration with high availability in mind.

Click To expand Figure 17-2: PPP configuration with high availability.

Setting Up Port Listeners

The listen port monitor is managed by the listen and nlsadmin commands. In contrast to ttymon, the listen port monitor manages network ports and connections by listening for requests to access services and daemons. The listen monitor uses the Transport Layer Interface (TLI) and STREAMS to implement OSI-compliant network service layers. Specific networks ports are assigned to the listen monitor, and child processes are spawned to handle each client request. One of the key features of listen is that it can provide services that are not managed by inetd—since all daemons can be accessed through a listen service. This is an important feature for the different users accessing services on a Solaris system. For example, a network connection could serve web traffic, while a dial-in connection could cater to telnet or SSH access.

The nlsadmin command is used to set up transport providers for STREAMS-compatible network services. In order to configure a TLI listener database, the nlsadmin command can be used to configure the listener. First, the TCP/IP database is created:

# nlsadmin -i tcp

Next, set the local hexadecimal address:

# nlsadmin -l \x11331223a11a58310000000000000000 tcp

All services that need to be run will then need to be entered into the TLI listener database.

Adding a Serial Port

Like any modern server system, Solaris 9 supports the connection of simple external devices through both a serial (RS-232-C or RS-423) and a parallel port. The two most common uses for serial devices on a SPARC system are connecting a VT-100 terminal or equivalent, to operate as the system console if no graphics device is installed, and as a modem, enabling dial-up Internet access using the Point-to-Point Protocol (PPP). The former is a common practice in many server rooms, where the expense of a monitor and video card can be eliminated by using a VT-100 terminal as the console, because many SPARC machines require a display device to boot at all. On x86 systems, there are many more devices available that often only have drivers available for other operating systems. Sun and other third-party hardware vendors are slowly making releases available for these devices through the Solaris Developer Connection. If you need to obtain an updated copy of the Solaris Device Configuration Assistant, and any updated device drivers for supported external devices, these are currently available for download at http://soldc.sun.com/support/drivers/boot.html.

Solaris 9 has a graphical user interface (GUI) for serial device configuration, provided through the admintool program. admintool is generally used for system administration tasks, like adding users and groups, but it also has facilities for configuring parallel devices (like printers) and serial devices (like modems). It contains templates for configuring standard modem and terminal devices, and supports multiple ports. It’s important to note that SMC is slated to replace admintool in future releases of Solaris.

Adding a Modem

Solaris 9 works best with external Hayes-compatible modems, which are also supported by other operating systems such as Microsoft Windows. However, modems that require specific operating system support (such as so-called “WinModems”), will not work with Solaris 9. In addition, internal modem cards are generally not supported by Solaris 9. While older modems tend to use external (but sometimes internal!) DIP switches, modern modems can be configured using software to set most of their key operational parameters.

Modem access can be configured to allow inbound-only, outbound-only, and bidirectional access, which allows traffic in both directions, using a similar scheme. In the following example, we’ll consider the scenario of dial-out-only access. The modem should be connected to one of the system’s serial ports (A or B) and switched on. The A and B serial ports map to the devices /dev/cua/a and /dev/cua/b, respectively.

To test the modem, use the tip command

# tip hardwire

where hardwire should be defined in /etc/remote. The hardwire entry should be similar to this entry

hardwire:\
        :dv=/dev/cua/a:br#19200:el=^C^S^Q^U^D:ie=%$:oe=^D:

where 19,200 bps is the connection speed between the modem and the serial port. In addition, /etc/remote should have a connection string associated with each modem that’s connected to the system. For example, the string

cua1:dv=/dev/cua/a:p8:br#19200

specifies that 19,200 bps is the connection speed between the modem and the serial port, with 8-bit transmission and with no parity enabled. To use this entry specifically, you would use the command

# tip cua1

If the message

connected

appears on your terminal, the system is able to communicate successfully with the modem. For Hayes-compatible modems, command strings can be entered directly like this:

ATE1V1

If you see “ok”, the modem is communicating as expected and can be configured to run PPP.

Setting Up PPP

The first step in configuring PPP is to insert appropriate configuration information in /etc/ppp/options. The following options are the most commonly used:

  • <tty_name> Name of the terminal device to use for communication.

  • <speed> Speed at which to transmit data.

  • auth Specifies that authentication is required (noauth specifies that no authentication is required).

  • callback Requests a callback from the remote server. Useful for saving on long distance charges!

  • connect or init Specifies the chat script to configure line communications.

  • mru Sets a maximum receive unit (MRU) value that specifies a limit on the packet size transmitted by the server.

  • mtu Sets a maximum transmit unit (MTU) value that specifies a limit on the packet size transmitted by the client.

Other options may be required, especially for authentication, but using these options is generally sufficient to make a connection. For further information, you should consult Celeste Stokely’s PPP guide: http://www.stokely.com/unix.serial.port. resources/ppp.slip.html.

Using ttymon

The ttymon port monitor is managed by the ttyadm command. ttymon is designed to monitor requests from ports to allow remote access to the system. The ttymon operates continually, spawning child processes when appropriate in order to service requests, which are sequentially numbered (for example, ttymon1, ttymon2, and so forth). The most common request for terminals is probably for an interactive login; thus, /usr/bin/ login is requested. The sacadm command can be used to list all current ttymon processes:

# sacadm -l
PMTAG    PMTYPE  FLGS  RCNT  STATUS   COMMAND
ttymon1  ttymon  -     2     ENABLED  /usr/lib/saf/ttymon #ttymon1
ttymon2  ttymon  -     2     ENABLED  /usr/lib/saf/ttymon #ttymon2
ttymon3  ttymon  -     2     ENABLED  /usr/lib/saf/ttymon #ttymon3

In order to view the services currently being provided through a particular monitor, you can use the pmadm command for each monitor process:

# pmadm -l -p ttymon2
PMTAG     PMTYPE     SVCTAG     FLGS     ID     <PMSPECIFIC>
ttymon2   ttymon     11         u        root   /dev/term/11
   -   -   /usr/bin/login - 9600 - login:   -tvi925
ttymon2   ttymon     12         u        root   /dev/term/12
   -   -   /usr/bin/login - 9600 - login:   -tvi925
ttymon2   ttymon     13         u        root   /dev/term/13
   -   -   /usr/bin/login - 9600 - login:   -tvi925
ttymon2   ttymon     14         u        root   /dev/term/14
   -   -   /usr/bin/login - 9600 - login:   -tvi925

Here, we can see that ports /dev/term/11 through /dev/term/14 are being serviced using the login service.

Connecting to an ISP

Once the /etc/ppp/options file has been set up, a connection can then be made from the command line. For example, to connect using a 56K modem using the chat script emergency1.chat, the following command will establish a connection without authentication:

# pppd connect 'chat –f emergency1.chat' /dev/cua/a 57600 noauth

pmadm

The port monitors are managed by the pmadm command. Port services can be managed by using the following commands:

pmadm -a

Adds a port monitor service.

pmadm -d

Disarms a port monitor service.

pmadm -e

Enables a port monitor service.

pmadm -r

Removes a port monitor service.

sacadm

The sacadm command is used to manage port monitors. The following functions are available:

sacadm -a

Attaches a new port monitor

sacadm -e

Arms a port monitor

sacadm -d

Disarms a port monitor

sacadm -s

Initializes a port monitor

sacadm -k

Kills a port monitor

sacadm -l

Lists port monitor details

sacadm -r

Deletes a port monitor

tip

tip is a command that acts like a terminal. It can be used, for example, to access remote systems directly through a serial port, where one system acts as the console for the other. Next, we’ll use the tip command to connect a Solaris 9 system to a modem. Before proceeding, however, we’ll examine some of the key features of tip in its own right.

tip uses the /etc/remote file to enable it to make connections through the serial port. For example, if you have a profile set up in /etc/remote, it’s possible to fire up a terminal session immediately by using the command

# tip profile

where profile is the name of the profile that you’ve set up with all the settings that the port requires to operate. tip also uses initialization settings in the .tiprc file to specify its operational parameters.

The following table shows the most commonly used tip commands:

Command

Description

~.

Exits the session.

~c

Changes directory.

~!

Spawns a shell.

~>>

Sends a local file.

~<<

Receives a remote file.

~p

Sends a local file.

~t

Receives a remote file.

~C

Allows a local application to connect to a remote system.

~#

Issues a break command.

~s

Defines a variable.

~^z

Suspends tip.



Part I: Solaris 9 Operating Environment, Exam I