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...
28800and 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.
/usr/lib/uucp/fix-modem script and an entry in
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.
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 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
`man serial` has complete pinout information for serial
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".
/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 ftp.sgi.com:/sgi/modems):
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 2You 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
mymodem =W-, "" \dAT\r\c OK\r-AT\r\c-OK\r ATs0=0\r\c OK\r ATdtw\T\r\c CONNECT-\c-CONNECTIRIX-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-CONNECTFor (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-CONNECTIn 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
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 directThen 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 ttyd2It 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:
atwhich 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>
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
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 <[email protected]> (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.
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]http://reality.sgi.com/employees/scotth/ Scott Henry <[email protected]> Last modified: Sun Feb 1 14:24:45 1998