Modem Installation and Configuration Guide

Modem Installation and Configuration Guide

[Selecting a Modem] [Modem Protocols] [modem "speed"] [Modem Installation] [Modem Cables] [Port Selection] [Modem Configuration] [non-supported modems] [Talking to the Modem] [Add Dialin Modem] [Serial Design]

Selecting a Modem

A number of different modems are supported for IRIX SLIP, IRIX PPP, and MST (MorningStar) PPP. Generally, you just need a high quality V.32 or faster modem. Under most circumstances you should avoid using proprietary modem protocols such as PEP or HST and stick with the standard ones (the "V" protocols).

The "V.nn" modem protocols

A short diversion on the "V" number protocols: These are CCITT standards for modems, and allow modems from different manufacturers to interoperate (talk to each other). Some of the standards refer to modem carrier (or modulation) speeds, and others refer to additional, higher level protocols. The protocols of interest include:
9600bps full-duplex modulation (fall-back to 7200bps and 4800bps)
14400bps full-duplex modulation, fully compatible with V.32
end-to-end error correction, runs "on top of" V.32, etc, and adds more than 10% to the effective throughput, even for compressed data
data compression, theoretically capable of 4:1, more commonly gets 1.5:1 to 2.5:1 on non-compressed data. In practice, it is usually limited by DTE (serial port) speeds.
Not really a standard, this 19200bps extension of V.32bis was driven by industry co-operation, while waiting for V.34. It is effectively obsolete.
28800bps, original (working) name for V.34. Most implementations were incompatible with each other. It is obsolete.
28800bps, an industry attempt to make the V.FAST implementations more compatible. Obsoleted by V.34, although some modems may continue to support this for backwards compatibility.
the final name of the V.FAST standard (committee approval was in July 1994). It can generally connect up to 33600bps.
X2, Flex56
some of the names used to designate a proposed asymmetric 56kbps analog modem standard. I haven't any personal experience with either of them yet. Important note: You can't get >33600bps between 2 machines on analog phone lines -- in order to get ~56000bps, one end must be on a digital (ie: T1 or B/PRI) link to the phone company central office.
You can normally expect that a faster modem (eg: V.34) will also support all speeds of a slower modem (eg: V.32) and is compatible with the slower modem (aside from proprietary speeds from other manufacturers, of course!). Some V.34 modems will also support V.FC, V.32ter, and other "temporary" protocols, for backwards compatibility with the existing installed base.

I have heard reports that some of the newer modems (especially the digital modem banks used by ISPs) don't support speeds slower than 2400bps, so it may be time to discard that old 1200bps modem you were saving as a backup...

About the modem "speed"

There are 2 speeds that are used with modems: Because V.42bis data compression exists, it is no longer useful to have the DTE (serial port) run at the same speed as the modulation (this is impossible anyway for 14400, 28800 and the fallback speeds). In general, the DTE should be set to the highest speed common to both the modem and the computer, though rarely more than 2x the fastest modulation speed. Hardware flow control (RTS/CTS flow control) is used to prevent data overruns (or data losses). Modern modems and computers support 38400bps or faster DTE speeds.

The older SGI machines (that came out before the O2) only support serial speeds up to 38400bps with the builtin serial ports. Faster serial speeds are available with serial expansion ports, such as teh SCSI-attached ones from Central Data. The O2, Octane, O200, and O2000 machines support serial speeds of at least 115200bps. Note: there is a bug in the PPP support in the first release of IRIX-6.3 for the O2 which limited speeds to 38400bps. For many additional reasons, you want to be running the "IRIX 6.3 for O2 including R10000" or later release.

Supported Modems for IRIX SLIP and PPP

The following modems have support in IRIX for SLIP and PPP (this means that there is a /usr/lib/uucp/fix-modem script and an entry in ~uucp/Dialers): You should choose the fastest modem that you can that is compatible with what you are connecting to. V.34 (aka 28800) modems are now the standard, and X2 and Flex56 are becomming common. Otherwise, make sure that you get at least a V.32bis (aka 14400) modem. For SLIP and PPP purposes, a Telebit WorldBlazer is just a more expensive version of the T3000, and performs identically. Therefore you should only spend the extra money if you will be doing a lot of UUCP to another WorldBlazer.

There are a lot of very cheap modems out there, mostly using the Rockwell V.32bis chipset. They may work OK for dialout applications, but are usually inappropriate for unattended dialin usage. It is worth spending the extra money for a quality modem for dialin purposes, if only for the peace of mind. Just remember that all modems, no matter what the manufacturer, ocassionally burp, and need occasional attention.

Supported Modems for Morningstar PPP

MorningStar supports a large number of modems. See their documentation for more information.

Modem Installation

Modem Cable Selection

Modem cables seem to cause the most problems. There are now 3 types of cables applicable to SGI machines:

Standard Mac modem cables don't work. Many of the so-called high speed modem cables, while technically not correct (they seem to often be missing RTS), seem to work well enough. This is the first place to check if your connection is flakey.

SGI computers really need full (aka 7-wire) modem cables. Consult `man serial` for details of the pinout (note that the picture is looking towards the computer, not the cable end!). The 7 signals and their meaning are:

The modem needs to be attached to one of the serial ports with a real modem cable. At the moment you cannot buy a third-party, mass-market modem cable for an IRIS workstation or server. Some of the newest "high speed" Mac modem cables are reputed to work for the Indigo (and Indy, etc) line, but most Mac modem cables support either Modem Control lines or Hardware Flow Control lines, but not both. Other Mac "high speed modem cables" that I've tested seem to be missing the RTS pin. For the newer hardware with fast serial ports (Indigo, Indigo2, Indy) and a packetized protocol like PPP, that doesn't seem to be much of a limitation. You need a cable that supports both (all seven lines) to run a SLIP or PPP connection on an IRIS.

Standard Mac modem cables tend to have only TxD, RxD, GND and DTR. This is insufficient for any usage on an IRIS.

The Mac high-speed modem cables tend to have all but RTS. For many purposes, they may be acceptable. The lack of RTS means that you may get occasional data overruns (a type of error) when compressible data is flowing full-speed towards the IRIS. This is less likely on newer hardware, and in a packetized protocol like PPP. This is one source of FCS error from PPP.

The only thing fully supported by SGI is the full 7-wire cable, like the one SGI sells. To my knowledge, only the SGI cable and custom cables (which you have verified against `man serial`) are guaranteed to work.

In one sense, it is fortunate that the old high-end machines use a non-standard connector: there are no mass-market cables that are "close", so you have to build your own, or have them custom made. Again, full pinouts are in `man serial`.

The newer machines (O2, Octane, O200*) use standard PC-compatible hardware flow control modem cables.

A number of SGI cable part numbers are available. It is currently unclear to those of us not in manufacturing whether all were actually manufactured:

  Part Number    Cable Type                  Indigo2 Owner's Guide

  018-8114-001   Indigo to dumb terminal      p. 5-21
  X5-25TO8       Indigo to modem cable        p. 5-22
  X5-9TO8        Indigo to SGI/high-end 
		 (dials/buttons)   	      p. 5-23
  X5-ARCTO8      Indigo to PC (ARCS!)         p. 5-24

Note: "Indigo" referes to Indigo, Indigo2, and Indy unless otherwise stated. `man serial` has complete pinout information for serial cables.

Selecting a Port

On graphics machines, any port can be used. The low-end machines, such as, the PI, Indy, and Indigo family have only 2 serial ports (4 on the 4D/30 & 4D/35), and either can be used, although port tty1 needs to be specially configured in order to work. The larger machines generally have more than 2 serial ports and more can be added using the 6-port serial board. Challenge and Onyx can add the new audio/6-port serial card, and handles up to 115.2kbps. A server (non-graphics) machine cannot use port tty1, because tty1 is the console port.

Central Data Systems manufactures a SCSI serial expander that supports SGI equipment. I have little direct experience with the product, but I know of people successfully using it for SLIP and PPP servers. Be sure to download the latest driver from their Web page.

To configure the serial port tty1 for use, you must disable it as the Alt(ernate) Console port (default) before you can use a modem on this port. To do this, you must edit the /etc/inittab file to change the "Alt Console" line from "respawn" to "off".

Modem Configuration

IRIX supplies scripts for automatically configuring a modem for use with SLIP or PPP (or UUCP). The scripts are in /etc/uucp, and the names all start with "fix-". On a 5.x (and 6.x) system, the following fix-name scripts are available (these are also available for 4.0 systems by anonymous ftp from
    fix-dsi fix-hayes fix-intel fix-telebit fix-usr fix-zyxel

For example, if you wanted to program a dialout Telebit T3000 to run at 38400bps on port 2 you would give the following command:

    /usr/lib/uucp/fix-telebit -o -m t3000 -s 38400 2
You should normally only need to perform this operation once. In addition, using the "-io" option instead of "-o" makes the modem usable for dialin, dialout, or both.

If you are running MorningStar PPP, the same fix- scripts can be used.

Configuring non-supported modems

Most V.32 and faster modems can be configured to function successfully with an IRIS. Because most modems are at least partially Hayes-compatible, a standard init string can do the bulk of the job configuring the modem.

Required Modem Configuration

(common Hayes-compatible commands are in [brackets])
DCD follows carrier [&C1]
When the modem drops this signal, it is known as a hangup, and the process connecting to the modem port is supposed to exit. This requires that that the modem cable have this signal wired.
DTR off causes the modem to hangup and reset [&D2]
This signal is controlled by the computer. For many modems, using [&D3] to cause the modem to recall the stored configuration is preferred. Reportedly, some modems screwup here. This requires that that the modem cable have this signal wired.
RTS/CTS enabled [&H3]
also known as Hardware Flow Control, it is out-of-band, and allows full binary (8bit) data to flow through the modems without dropping any characters. It also requires that these 2 signals be wired in the modem cable.
command echo on [E1]
this makes it easier to debug, and some programs want this.
result codes maximum verbosity [Xnn]
all dialer scripts require verbose command results, the value in the argument varies from modem to modem.
fixed DTE speed
Lock the serial port speed to the highest speed supported by both the modem and the computer. This is usually 38400 or faster for recent equipment (post T2500). The mechanism to do this is not standardized, and not all modems do it for dialout.
disable escape character [s2=128]
When used for binary data, some modems can appear to lock up if the escape character (default +) is enabled. In any case it is a security hole on a server.
After configuring the modem by hand, you will need to add one or more entries in the Dialers file. It is usually easiest to find one that is similar, and copy it and modify it for your modem. The following might be a minimal starting point (for IRIX-5.2 and earlier releases and IRIX-6.0):
mymodem	=W-, "" \dAT\r\c OK\r-AT\r\c-OK\r ATs0=0\r\c OK\r ATdtw\T\r\c CONNECT-\c-CONNECT
IRIX-5.3 (and IRIX-6.0.1) supports additional capabilities in the Dialers file:
mymodem	=W-, ABORT BUSY ABORT NO\sCARRIER ABORT NO\sDIALTONE "" \dAT\r\c OK\r-AT\r\c-OK\r ATs0=0\r\c OK\r ATdtw\T\r\c CONNECT-\c-CONNECT
For (client) dialback purposes you'll need to add something like this (for releases prior to IRIX-5.2):
db-mymodem	=W-, "" \dAT\r\c OK\r-AT\r\c-OK\r ATs0=1&C0\r\c OK\r ATdtw\T\r\c CONNECT-\c-CONNECT
In IRIX-5.2 (and IRIX-6.0) and later, there is a chat script escape code to disable DCD (\M). Therefore, (client) dialback can be done entirely in the /etc/uucp/Systems file, and standard /etc/uucp/Dialers entries can be used. See the documentation in /etc/uucp/Dialers.

And if you are going to use it as a dialin modem as well, you will need an entry for use with uugetty like:

mymodemin =W-,    "" \dAT\r\c OK\r-AT\r\c-OK\r ATs0=1\r\c OK\r

Typing Directly to the Modem

There are many cases when you need to talk directly to the modem. Since you need to have the UUCP files installed anyway (eoe2.sw.uucp) then you already have the cu program installed. This is a very brief tutorial on cu, see `man cu` for more information.

First, you need to configure the system to let cu talk to the serial port that you've connected the modem on. The examples will assume that you are using port 2 at 38400bps. Add the following lines to /etc/uucp/Devices (/usr/lib/uucp/Devices in IRIX-4.x):

Direct ttyd2 - Any direct
Direct ttym2 - Any direct
Direct ttyf2 - Any direct
Then after the modem and serial cable are connected and turned on, give the commands (the first must be done as root, but should only need to be done once):
chown uucp.uucp /dev/tty[dmf]2
cu -s 38400 -l ttyd2
It should print (connected), then leave the cursor at a blank line. All commands to modern modems start with at, and end by hitting the Return or Enter key on your keyboard. The simplest command is just:
which should echo the characters you typed, and then print OK on it's own line. The following commands work on most modems, and are usefull to know (spaces are optional, and are used for clarity):

Once you have configured your modem (or verified that it is working), you should repeast the process using the /dev/ttyf2 port, the one that PPP or SLIP will be using. Exit from cu, and start it again with the command:

cu -s 38400 -l ttyf2

One final instruction: to exit from cu, type the following 4 keys:

<enter key>~.<enter key>

Adding Dialin Modems

Each server may support one or more dialin modems (2 maximum on an Indigo, Indigo2, PI, Indy, O2, Octane, 4 on 4D/30 and 35, more on Power Series, Challenge/Onyx, and Origin/Onyx2 machines or if you have installed additional serial boards). The file /etc/inittab (details vary between releases) must be modified as follows to add dialin modems (NOTE don't do this for dialout modems!):

The original lines, about 20-30 lines from the top, should look like the following (the exact format varies for different releases):

   # Use the ttym* or ttyf* device names and the du_* or 
   #       dx_* gettydefs tags for ports with modems.  
   #       See the getty(1M), uugetty(1M), init(1M),
   #       gettydefs(4), and inittab(4) man pages.
   # on-board ports
   tp:23:respawn:/etc/getty tport co_9600  # textport
   t1:23:respawn:/etc/getty ttyd1 co_9600  # alt console
   t2:23:off:/etc/getty -N ttyd2 co_9600   # port 2
   t3:23:off:/etc/getty -N ttyd3 co_9600   # port 3
   t4:23:off:/etc/getty -N ttyd4 co_9600   # port 4
Note: there are major changes coming in IRIX-6.5, check out the /etc/inittab on your system.

Change these line to look like the following (assuming 2 modems, a ZyXEL and a T3000):

   # Use the ttym* or ttyf* device names and the du_* or dx_* 
   #       gettydefs tags for ports with modems.  See the getty(1M), 
   #       uugetty(1M), init(1M), gettydefs(4), and inittab(4) 
   #       man pages.
   # on-board ports
   tp:23:respawn:/etc/getty tport co_9600  # textport
   t1:23:respawn:/usr/lib/uucp/uugetty -Nt 20 -izyin,conn ttyf1 dx_38400  # 
   t2:23:respawn:/usr/lib/uucp/uugetty -Nt 20 -it16in,conn ttyf2 dx_19200  # 
   t3:23:off:/etc/getty -N ttyd3 co_9600   # port 3
   t4:23:off:/etc/getty -N ttyd4 co_9600   # port 4
Use "-izyin,conn" for ZyXEL modems, and "-it16in,conn" for T1600, T3000 and QBlazer modems. Similar entries are available for other modem types (see ~uucp/Dialers for the valid list). If only one modem is in use, the unused port(s) should be "off" instead of "respawn". Again, make sure that you use the same speed everywhere for a given port/modem, or things may "mysteriously" break.

Note: If the server is a graphics-less machine, don't change the "t1" line, since it is used by the console terminal, and can't be used for a modem.

After making the changes, type the following command for each modem installed. Use the approriate modem type: zy1496, t2500, t1600, etc as needed:

   % su
   # /usr/lib/uucp/fix-zyxel -i -s 38400 1
   # /usr/lib/uucp/fix-telebit -i -m t1600 -s 19200 2

Many systems can benefit from using 38400 or faster serial speed. However, not all older modems or older SGI machines support 38400 (or at least not reliably). In addition, the software support is not complete prior to IRIX-5.0. 38400 capability can be added by adding the following line to the /etc/gettydefs file if it doesn't exist:

   dx_38400# B38400 # B38400 SANE TAB3 HUPCL #\r\n\n$HOSTNAME login: #dx_38400

The /etc/inittab file entry supporting 38400 might look like:

   T2:23:respawn:/usr/lib/uucp/uugetty -Nt15 -it16in,conn ttyf2 dx_38400 # modem port

After all of the modems have been configured, give the following command to have your changes take effect:

   % su
   # /etc/telinit q

Serial Port Design History


Why the serial ports are almost, but not quite, like a Mac

This is the history behind the DIN-8 serial port on the previous generation of SGI desktop machines, provided to me by one of the engineers involved <> (lightly edited):

I was just reading your modem config info on your home page and thought I would add a few missing bits about the 4D/3x,Indigo,Indigo R4k, Indigo2, and Indy serial ports.

When we designed Indigo, we wanted to to make the serial ports be Mac compatible. We choose the same connector and duart as the Mac (or at least the more modern Macs). This was an 8 pin mini-din using RS-422 style signals. (No piece of SGI equipment has every been really RS-422 or RS-232 compliant and those names aren't the right ones anyway [it's EIA, not RS since ~1980]). RS-422 uses differential signalling which means that there are two receive lines and two transmit lines. Each pair has a normal and an inverted copy of the same data. The data is extracted by comparing the two instead of comparing one of them against ground. This is more robust in both high speed and long distance situations; it's the same technique as differential SCSI.

One of the things that they did on the Mac was add support for multiple senders on a serial line. This is for the LocalTalk version of AppleTalk. They did this by using the RTS signal from the duart to tri-state (disable) the output of all but one of the machines sending on the shared cable. We originally designed Indigo to support this with the intention of supporting localtalk directly. So Apple didn't/couldn't use RTS for its normal meaning. Whats more, since the differential send/receive took two more pins, they didn't have enough pins anyway.

So when we did the Indigo, we designed in two modes: IRIS and Mac. In IRIS mode, the RTS is passed through to the Transmit+ line. The diagram on the serial man page incorrectly lists pin 8 as signal ground in IRIS mode, it is actually Receive Data+ and shouldn't be grounded (I think).

Anyway, none of this really changes your answers page, but that's the story on how come Apple doesn't use RTS and how we turned out to be almost, but not quite, the same as them.

P.S. One more thing that's different in Mac mode: the CTS pin can be used to provide an external baud rate clock. This was for MIDI which runs at a strange rate. You put it in the mode with a special streams ioctl.

P.P.S. I had originally intended that we would add a /dev/ttyaXX that accessed the ports in Apple mode, but never got around to it. You need to put the port in Apple mode with a streams ioctl.

Additional info:

The next level of intricacy to the serial ports is the voltage levels that are used. In the original RS-232 spec (now properly called EIA-232), the voltage swings for logical 0/1 were nominally +/- 12 volts. Computer makers have fudged this to -12 / 0 for a long time without too many problems. However, EIA-422 is spec'ed at +/- 5v. Indigo used +/- 5v which would have been okay, except that some anti-EMI components lowered the potential to something more like 4v which wasn't enough in some cases. Indy corrects this using a custom part. However, there have been all kinds of problems with that and I'm not sure where things currently stand. Some MIDI adapters (and maybe even some cheap tablets) are parasitic in that they power themselves from the DTR line. These don't work on some versions of Indy because there isn't enough power available.

Hopefully there has been enough info here for you to figure out your connection problem. This info is based on looking at the problem from the client (dialing) end, becuase that is where most problems are discovered.

Other Useful Information

A random selection of potentially useful WWW pages:

I hope and intend that this documentation can help you with your PPP connection problems. My other commitments (like work) permitting, I will attempt to help you on issues not covered, or that you are unclear on. Please make sure that you provide me a valid return email address! (I won't try to fix it).

[Back to Top] Scott Henry <>
Last modified: Sun Feb 1 14:24:45 1998