Modem Installation and Configuration Guide

Selecting a Modem

The "V.nn" modem protocols

V.32

9600bps full-duplex modulation (fall-back to 7200bps and 4800bps)

V.32bis

14400bps full-duplex modulation, fully compatible with V.32

V.42

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

V.42bis

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.

V.32ter

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.

V.FAST

28800bps, original (working) name for V.34. Most implementations were incompatible with each other. It is obsolete.

V.FC

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.

V.34

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.

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"

• the modulation speed. This is the speeds that the modems communicate with each other, and that the manufacturers advertize: 9600bps, 14400bps, 28800bps, etc (incorrectly called baud). They generally correspond to the V.* protocols above. Since the modems can retrain, and there are fallback (slower) speeds in each protocol, the actual modulation speed in use in a given phone call can vary. The V.32 and faster protocols are usually at a multiple of 2400bps.
• the serial port (DTE) speed. This is the speed that the modem talks to the computer (or terminal, etc). The speeds are mostly factor-of-2 multiples of 300bps. Common serial speeds for modern high-speed modems are: 9600, 19200, 38400, 57600, 76800, and 115200.

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

• Telebit V.32 modems: T2500, T1600, QBlazer
• Telebit V.32bis modems: QBlazer+, T3000, and WorldBlazer
• ZyXEL U-1496 (all versions), V.32bis
• Intel 14.4ex, V.32bis
• DSI 9624 models, V.32bis
• US Robotics (aka: USR), V.32bis and V.34+
• Hayes ACCURA (aka: hayes14), V.32bis
• Almost any true Hayes compatible can be made to work

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

Modem Installation

Modem Cable Selection

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

• The Challenge/Onyx and older "big boxes" use a more-or-less proprietary male DB-9 connector. Either buy from SGI, or make your own.
• The older desktop machines (Indigo, Indigo2, Indy) use an almost-but-no-quite Macintosh compatible cable pinout. This is where the most problems lie. The "high-speed" modem cables mostly work, but are usually missing the RTS signal.
• The new machines (O2, Origin, Onyx2, Octane) all use an IBM-compatible female DB-9 connector. Any IBM-PC full modem cable ought to work. Ensure that it support full hardware flow control.

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:

• TxD -- Transmit Data. This carries the data bits one way (say from computer to modem)

• RxD -- Receive Data. This carries the data bits the other way (echo, etc).

• GND -- signal ground, the reference for all other signals

• DTR -- Data Terminal Ready. The computer drops this to hang up a connection.

• DCD -- Data Carrier Detect. The modem raises this signal when the modems connect, and drops it when they hangup.

• CTS -- Clear To Send. The modem raises this when it can accept data.

• RTS -- Ready To Send. The computer raises this when it can accept more data.

  The data rarely comes in fast enough to cause this signal to be asserted, which is why the Mac "high-speed" modem cables mostly work.

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

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

    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

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

Configuring non-supported modems

Required Modem Configuration

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.

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

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

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

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

chown uucp.uucp /dev/tty[dmf]2
cu -s 38400 -l ttyd2

at

• at e1 -- enable command echo
• at &v -- display the modem settings
• at i -- display some model information
• at &w -- save your changes into NVRAM

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

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
   #

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
   #

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 <wiltse@esd.sgi.com> (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.

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.

• IP address and routing issues
• Proxy ARP routing on a split network
• resolving hostnames on an isolated machine
• configuring PPP for Irix-5.2 and later
• configuring SLIP for Irix
• troubleshooting a dialup connection
• dialup access the parent page.

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]