Open Computing ``Hands-On'': ``PC-Unix Connection'' Column: January 94

The Serial Saga

Modems and the Unix operating system are made for each other. Aren't they?

By Tom Yager

Welcome to my column. Rather than waste a lot of precious words describing what
it's about, I'll give you this example and let you draw your own conclusions. I
will, however, inflict a tiny bit of introductory text on you as a foundation
for the rest of this column (and those to come).

To research this column, as well as the reviews and features I write for Open
Computing, I operate a small private lab. Contained in it are several PCs
running different flavors of Unix, DOS and Windows, and Netware. There will
also be an Apple Macintosh (I'm awaiting an upgrade to a newer model) and a
Commodore Business Machines Inc. Amiga tower. I also have a SPARC-based machine
(a SPARCcard from Opus Systems, Inc.) for working good old Sun Microsystems
Inc.'s SunOS/Solaris into the mix. My systems, numbering 12 in all, are tied
together with a single Ethernet circuit carrying both TCP/IP and Novell Inc.'s
Netware IPX/SPX.

You'll learn more about the makeup of my lab in future articles. Better than
half of the equipment I use is provided by vendors. This way I can afford to
change the shape of the lab to reflect current technology--what you'd be likely
to buy if you set out to acquire your own Unix hardware or software. I also
avoid being dependent on any particular vendor's product or philosophy; if I
don't resell it or have my own money sunk into it, I can afford to shelve a
piece of the lab when it's no longer viable.

The Serial Serial

Before initiating this column, it had been a while since I'd built a PC Unix
box. Univel, or the Unix Systems Group, or whatever they're calling themselves
these days, set me up with its Unixware operating system. This value-added
version of System V Release 4.2 (a.k.a Destiny) seemed to have sufficient
functionality, compatibility, and promise to justify my building a new
dedicated system around it.

I contracted Mobius Computer Corp. to build a PC system for me, one of those
rare times I've shoveled my own cash into the lab. I wanted the security of
owning what will become my hub system, and I suppose I also wanted to suffer as
you do when your money's at stake. I got my dose of suffering, which Mobius
acted quickly to resolve, but then I tripped blithely into one of PC Unix's
densest minefields: serial ports.

As this new Unixware box is destined (no pun) to become the new Maxx, the name
of my connection to the rest of the world, I need to equip it to run a pretty
demanding combination of serial connections: three high-speed modems--two
Worldblazers and a T2500, all from Telebit Corp.--and a couple of serial
terminals plus ports for my laptops. After that, I need enough available ports
to hook up equipment brought in for reviews and such.

I turned to Equinox Systems Inc., a company with a broad line of serial
products, and my lab now has its Megaport XP. This piece of equipment is a
supersmart serial card that starts with eight ports and expands up to some
obscene number simply by hooking together external connector boxes like Legos.
It met my requirements, with each port going up to 38,400 baud, the connector
box housing eight DB-25 sockets, and all lines having full modem control.

That last bit--full modem control--turned out to be the snake pit. Those snakes
weren't of Equinox's making, and I'll digress for a moment to praise them both
for their responsive support and for their commitment to SVR4. Unlike other
vendors that sell SVR3 drivers with claims of compatibility, Equinox provides
genuine SVR4-compatible drivers that install easily and run effortlessly when
you've gotten the rest of the system to behave.

Full modem control means that most or all of the signal lines coming out of a
modem are passed through the serial card to the Unix driver. The most vital
control signals include carrier detect (CD), which the modem raises after it
negotiates a valid inbound or outbound connection; data terminal ready (DTR),
which the system raises when it wants the modem to answer incoming calls and
which the system drops briefly to terminate a connection; and clear to send and
request to send (CTS/RTS), which set up flow control between the host and the
modem.

My first trouble came when CD failed to work as advertised. In Unix, a program
that opens a serial port has two choices: open it and make an immediate
connection; or block, waiting for CD to go high. The first case allows programs
like uucico, the transmit/receive component of UUCP, to command the modem to
dial outgoing calls. Blocking on CD is what programs like getty will do to
automatically wake up when an incoming connection is made.

Most Unix modem setups are bidirectional, that is, you are able to manage both
incoming and outgoing calls. System V Unix has a primitive locking mechanism
that permits this control; outgoing calls are prevented if an inbound
connection is active. Similarly, getty will wait for an outbound session to end
before returning to watching CD for incoming calls.

At least, that's how it used to work and continued to work right through
Release 4.0. When SVR4.2 came out, USL's programmers invented something called
the Trusted Path driver--I hesitate to dignify it with capital letters--a
security enhancement meant to help prevent unauthorized access to system
hardware. This watchdog slobbered all over a perfectly workable Streams
implementation of serial device drivers. As a result, Unixware was hobbled from
the first day with busted serial support. The symptom: it's impossible to open
a port unless CD is high. This situation poses no problem for terminals, but it
kills any chance of configuring bidirectional modems.

The Forked Tongue

While I understood that it wasn't Equinox's fault their serial board wouldn't
work, I needed one that did. So I started shopping around for a board from a
vendor that solved the problem. I thought I had found one. I picked up another
intelligent eight-port card; the manufacturer promised me they had lots of
other Unixware users. "With modems, running bidirectional?" I asked. "Oh yes,"
they replied. The drivers turned out to be Release 3 non-Streams drivers; a
plus, I thought, because they wouldn't have the Busted, er, Trusted Path
Streams problem. The drivers did install, my kernel relinked just fine, but
then I discovered another problem: Release 3 drivers have no provision for
managing Release 4's hardware flow control.

RTS/CTS flow control isn't needed for most applications, but when you need it,
you can't live without it. In my case, I run three bidirectional Telebit
modems. When someone dials in, the Telebits send out a cacophony of tones that
link up with anything from old reliable 2,400 baud through V.32bis and
TurboPEP. In English, that means the modems might make a connection at anywhere
from 2,400 baud to more than 20 kilobaud. Rather than try to teach my system to
jockey interface speeds to match the connection speed, I've commanded the
modems to lock themselves at 38,400 baud. Flow control comes into play when a
connection is made at less than that, which is most of the time. Let's say I
dial in from a distant hotel using a basic 2,400-baud modem. If I request a
lengthy chunk of data--say, the output from the ls -l /usr/bin command--the
system will squirt those characters out at some 3,800 characters per second.
The bandwidth of the communications channel between modems is a scant 240
characters per second. To manage the difference, the modem is equipped with a
small internal buffer. The computer fills the modem's buffer at full speed, and
then the modem says "shut up" by dropping its CTS line. If the port is
configured with flow control, it will stop sending characters until CTS goes
high again.

The Termio settings to enable hardware flow control, like most things, were
never standardized in SVR3 Unix. There is a standard in Release 4, but it
relies on an auxiliary structure-- named termiox--which exists solely to
configure flow control. Release 3 drivers don't have this, and attempts to
toggle flow control in the Release 4-standard manner cause driver-level errors.
As a result, unless a vendor has resorted to an alternative scheme, such as
using minor device numbers to enable and disable flow control, Release 4 users
are better off with real Release 4 drivers.

The Happy Ending

For several weeks, my hard-won Mobius system sat idle for want of working
serial ports. Then the sun, or rather the Univel, broke through: I got a call
informing me that an official fix had been uploaded to the company's support
area on Compuserve. I downloaded and installed the fix. Know what it does? It
disables the Trusted Path. Ironic, isn't it, that progress sometimes means
stepping backward. So I have a working system, and I'm pleased to report that
Unixware's bidirectional modem support appears to be cleaner even than that
from The Santa Cruz Operation Inc. or Interactive Systems Corp., which never
quite got locking right.

There are a few morals in this convoluted story, and they're all related to
shopping for serial cards with your eyes open. First, make sure the vendor has
specific support for the type and version of Unix you're running. If they claim
to have some kind of universal driver, you might try to get the board on
approval; it may not work. If you're hooking modems to your system, make sure
the card and drivers you select support both bidirectionality and hardware flow
control. And be careful: one vendor's ``expert'' I spoke to thought
bidirectional meant data went both to and from the modem and hardware flow
control meant the board listened to CD. Sheesh. Isn't this stuff supposed to be
getting easier?

-------------------------------------------------------------------------------
Copyright © 1995 The McGraw-Hill Companies, Inc. All Rights Reserved.
Edited by Becca Thomas / Online Editor / UnixWorld Online / beccat@wcmh.com

 [Go to Content]   [Search Editorial]

Last Modified: Tuesday, 22-Aug-95 15:49:08 PDT