MORE 6386 UUCP WOES ...

[Every system needs one]

In article <2096 at cuuxb.ATT.COM>, mmengel at cuuxb.ATT.COM (Marc W. Mengel) writes:
> In article <319 at argon.UUCP> daveb at argon.UUCP (Dave Berk) writes:
> > [ Woes of using a Hayes compatable modem on a Unix box ]
> >Can anyone out there shed any light on this problem ?  

[description of setting DCD to follow remote carrier]

[description of modifying L-devices to talk to modems]
> >Is it just me or isn't this a fundamental problem with the tty driver ?
> 
> No, its a fundamental problem with some modems -- they don't signal
> the host they are connected to that the line was disconnected.

You neglect the brunt of the problem: If you don't use a modem-control
device, it doesn't matter how you bludgeon it; it's not going to work
correctly.

Under Xenix, modem control devices are characterized by an uppercase
letter in the device name (tty1A instead of tty1a, etc).  This is not
absoulute, of course: you could name your device /dev/phil, if you
wanted to.

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.

> >How can I ever use it remotely without being paranoid that if the line
> >drops I can't log back in unless I physically am there to kill the
> >processes associated with the port and reset the modem ?

This, unfortunately, is bogus.  The modem should be set to reset on the
high-to-low transition of DTR.  It should also go back on hook.  The UNIX
stty parameter (set in /etc/gettydefs) to cause a drop of DTR on port
close is HUPCL (Hang UP on CLose).  In addition, the port should be set
-CLOCAL (Connection is LOCAL), thereby enabling the SIGHUP signal to
be set to all processes in that process group when a high-to-low transition
of DCD (Carrier Detect) occurs.

A normal login session:

UNIX box is off, Modem is off:		Modem can not, of course, answer phone
UNIX box is off, modem is on:		Modem can "hear" rings, but still
					can not answer the phone until DTR
					is asserted.
UNIX box on, port is disabled:		Since we are using a modem-control
					port, DTR is not asserted by the
					computer, since the port has not
					been opened.
UNIX box on, port is enabled:		/etc/getty calls open.  This raises
					DTR on the port.  Modem can now
					answer the phone if it rings.  Since
					we are using a modem control port,
					the open is stuck until DCD (carrier)
					is asserted by the modem.  A process
					status (ps -eda) at this point will
					show a getty on tty ?.
UNIX on, DTR high, phone rings:		Modem answers the phone.  Connection
					occurs.  Modem sends "CONNECT"
					message to the computer.
			[NB: at this point, if the port is not a Modem]
			[    control port or if DCD is forced high in ]
			[    the cable or the modem, the computer will]
			[    echo an invalid login message at the     ]
			[    modem.  Since the modem has not raised   ]
			[    DCD, it thinks it's calling out and you  ]
			[    want to hang up, so it does.  This can be]
			[    avoided by setting the modem up right or ]
			[    turning off result codes.  Turning off   ]
			[    result codes is a bad idea, since it can ]
			[    keep you from dialing out.               ]
					Modem raises DCD.  Open completes (a
					ps -eda will show a getty on tty##
					now).  The getty puts out the banner
					message in /etc/gettydefs and says
					"login:" and calls gets().
			[NB: while at this point, a recevied "break" ]
			[    will cause the baud rate to change, if  ]
			[    this is defined in /etc/gettydefs       ]
					After the user types in something and
					hits return, getty exec's /bin/login
					on the string and prompts for a
					password.  A ps -eda will show login
					on tty## now.  All future logon tries
					during this call will be handled by
					/bin/login, and it is no longer
					possible to change the baud rate.
[The user uses the machine for a while to the sound of "Jeapordy" 'Thinking
 music']

one of two things happens:

	1) The user logs out
	2) The user hangs up or is cut off

1) The user logs out:

The port is closed in the act of
hanging up and a signal is sent to
init.  Meanwhile, since the port is
closed and -CLOCAL was specified,
DTR is dropped to the modem.
					The modem resets and goes on hook,
					dropping DCD.
Init acts on the signal and runs
/etc/getty on the port again.
					The modem can answer the phone
					again.  The cycle repeats.
....
....
....
					
2) The user hangs up or is cut off:

					The modem drops DCD.
Since the port is set HUPCL, all
processes are killed by a SIGHUP
unless they were specifically told
to ignore the signal.  The shell
dies (same as logging out).  The
port is closed and the modem resets.
The init process is sent a signal.


....
....
....

This is the intended setup.  The one disadvantage is that you can't get
back in without calling again.  This can be subverted.  Instead of logging
out, you get to your lowest level shell (the one run by you logging in)
and type:

	exec /bin/login

You will get a "login:" again.  Hope this answers some recurring questions.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
|                   'I have an eight user poetic liscence' - me               |