MORE 6386 UUCP WOES ...

[Greg A. Woods]

In article <16509 at onfcanim.UUCP> dave at onfcanim.UUCP (Dave Martindale) writes:
>In article <727 at wsccs.UUCP> terry at wsccs.UUCP (Every system needs one) writes:
>>
>>The general UNIX implementation of modem-control devices is that of setting
>>either bit 6 or 7 of the minor device number.  To find out for sure
>>which should be used on your system, check sio(7) in your manual.  In
>>general, if the minor device is greater than 64, it's a modem control
>>device.

Or asy(7) for 386/ix.

>I don't know about system V UNIXes, but on all of the older UNIX versions
>plus the BSD variants, the default device supported modem control - it's
>the only sane way to handle dialins.
>
>Sometimes an upper bit in the minor devices was used to add a "nowait"
>device, that allowed you to talk to the modem without waiting for
>Carrier Detect, but this is not always present.
>
>Maybe it is just Xenix that gives you no modem control by default?
>This is pretty brain-damaged behaviour.

I appologize in advance if this is redundant.

Terry appears to be talking specifically about Xenix.  I worked with
an SCO Xenix V/286 2.2.1 system for many months a while back.  It
supported both "modem control" and "no wait" ports by default.

I used this system with out too much trouble with ungetty to support a
bi-directional line by running the getty on the modem control device,
and uucico on the no wait device.  The only problems I had were with
getty's getting hung, or with the port getting locked up with a hung
open using O_EXCL.  (At least this is what appeared to happen.)

This system (ixpierre) is 386/ix 1.0.6 (SysVr3).  By default, (i.e.
when you install it), only "no wait" devices are supplied.  One can
add the modem control devices by simply mknod'ing the files.

I use a modem control device for my incoming line, and a no wait
device for my outgoing line.  I have yet to make the modem control
device operate successfully as a bi-directional port without re-wiring
the modem (which is impossible, since it is an internal modem).  If
the modem control device is used with 'uugetty -r tty01',

The modem control device works fine with a standard modem, and does
what you would expect it to.

The no wait device seems to have a lot of problems.  Both cu and
uucico often report "lost line errno - 0" when attempting to dial
out.  However, the port is OK once the call is made, and uucico even
seems to pay attention to carrier detect and give up if the line is
dropped.

If any sufficiently privledged process attempts to open for read
either device that is associated with an incoming call (i.e. root
running 'stty -a < /dev/tty01'), the modem drops the user.

Does anyone besides Microport and Sun support simple bi-directional
port usage by having a device driver which will prevent a getty's open
on the modem control device from completing whenever the no wait
device is open?  Does anyone have a version of asy(7) for 386/ix that
does this?  Why does AT&T seem to instist on keeping the uugetty
hack?  I see no reason for it given a fully functional modem that
adheres to the RS-232 spec. and an intelligent device driver.

BTW, pay no attention to the device names I've used.  I actually have
them backwards here, in order to conform to the ISC naming "standard"
(i.e. I didn't want to rename any devices, just add the modem control
devices).  I've called the incoming line acu00, and the outgoing line
tty01.  The ACU should really be the outgoing line :-).
-- 
						Greg Woods.

UUCP: utgpu!woods, utgpu!ontmoh!woods, {ontmoh,tmsoft,telly}!ixpierre!woods
VOICE: (416) 443-1743 [h]		LOCATION: Toronto, Ontario, Canada