mgetty 0.18 / ESIX SVR4.0.3A bug

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi!  I posted this on the net and thought I would send you a copy in
case you don't see it for a while and can provide any help.  I am
having a problem with mgetty and the stock ESIX SVR4.0.3A ASY driver.

Joe Buehler

#############################################################

I have installed mgetty+sendfax 0.18 on my ESIX SVR4.0.3A box.

I am having problems with mgetty.  Out of the box, it does not
cooperate well with cu and uucico: neither can dial out when mgetty is
activated in /etc/inittab.

I did some tracing with truss.  The problem appears to be
peculiarities of the ASY driver, which leads me to believe that
everyone who has run mgetty on ESIX SVR4 is using FAS or SAS instead
of the stock ASY driver.

Here is the sequence of events I see with truss:

1. mgetty opens the ASY device, does some TCGETA and TCSETA calls,
chats with modem to initialize it

2. cu opens ASY device, does some initialization, eventually changing
tty settings with TCSETA

3. That TCSETA causes SIGHUP to be given to mgetty (no big deal), and
causes subsequent ioctl()'s by cu on the ASY device to start failing
with errors like NXIO (big deal!).  write() returns an error, as I
recall, read() returns eof: it looks like the device is closed, as far
as the driver is concerned.

4. cu exits shortly thereafter

If I rip out the mgetty modem initialization code and put in a
straight TCSETA that sets the ASY modes to the same modes that ttymon
uses, cu and uucico work fine.

It is not clear to me at present if mgetty can chat with the modem
without causing this problem.  Before I work on this, I thought I
would ask to see if anyone has already fixed this.

HAS ANYONE FIXED MGETTY TO BE ABLE TO USE THE STANDARD ESIX SVR4 ASY
DRIVER?

I would like to avoid installing SAS or FAS if I can: I have never had
any problems with my ASY drivers.