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?