Scripts to deal with A/UX's buggy UUCP

[Jeff Mann]

In article <1991Mar28.003019.1764 at mauxci.uucp> dumais at mauxci.UUCP (Paul Dumais) writes:
>In article <1991Mar27.014105.5418 at intacc.uucp> mann at intacc.uucp (Jeff Mann) writes:
>>I don't know if you've done something else to get around this, or what,
>>but on my system uucico will die if there is a getty on the line, 
>>regardless of whether you do an stty -modem. In other words, your
>>>		# have to worry about a getty. If not, we need to handle the
>>>		# getty by doing a stty -modem.
>>doesn't work for me. I have had to use the old method of specifiying
>>run levels which getty can exist in, and using init to turn the getty
>>on or off. Am I missing something? Anyone else with the same problem?
>>I'm planning to post my code which handles this, but part of it runs
>>suid root to handle the init, and if there's another way around it...
>>
>
>I have UUCP working just fine for both dial-in and dial-out on mauxci.UUCP.
>There is NO REASON to play with run levels.  Alexis <alexis at panix.uucp> has
>written some code to enhance the administration of UUCP but he is not mucking
>around with gettys or run levels.

Just because it works for you, doesn't mean it works for me! :-)
The fact is that getty and uucico don't co-exist peacefully on my system,
even using the gettydefs that you posted (except for the flow control,
which creates a SERIOUS SECURITY PROBLEM - see below).

This is as far as I've got debugging uucico/getty:
uucico opens and writes to the port ok.  However, if anything is
received from the modem before connecting (eg.  the RRING message), the
line is immediately lost. (Paul, this is different from what I told you
in e-mail, if you got my e-mail...) If I turn off echo and result codes
from the modem, the connection is made by uucico, but then my own
/etc/issue and login prompt is written to the port by getty.  This
really screws things up as far as expect/send sequences go!  However, I
then receive a message from getty on the console that the line is locked
by the uucico process, and getty does not respawn.  Looks like getty is
sending out /etc/issue and the login prompt BEFORE checking whether the
line is locked.  Same behaviour with cu.  Admittedly, I could re-write
all my expect-send sequences to take this into account, but that's just
too ugly for me, so I have arranged for getty to be shut off before
calling out.

Here is the debugging output of uucico with getty turned on:

# stty -n /dev/tty0 -modem
# /usr/lib/uucp/uucico -r1 -x4 -sweb
finds called
getto called
call: no. tty0 for sys web fixline - speed= 11
login called
wanted "" got that
wanted help): got ?
wanted help): ______System name: web______   userid: (? for help):got that
wanted ssword: ame: web______   userid: (? for help): ___-=-=-=-=-=-=-=-___=System name: web______   userid: (? for help): ___System name: web______   userid: (? for help): -=-=-=-=-=-=-=-=-=-=-=-____= Welcome to Matrix!  If you have any =____- problems or questions, call the     -____= Inter/Access office at 535-got ?
exit code 0
# Apr  1 20:29:36 getty[195]: line tty0 locked by pid 192

Note my system's (intacc's) banner and login prompt (stuff about Matrix and
Inter/Access) mixed in with the one from the remote system (web). I am able
to call web with no problem when getty is turned off.

This is the expected behaviour on many older uucp systems (getty must be
turned off before calling out), and is also mentioned in some places in
the A/UX documentation.  Other users (Richard Todd?) have reported being
unable to call out with getty active.

>
>Here are my settings on mauxci:
>(Macintosh IIfx, 8MbRAM, 500Mb, A/UX 2.0.1, TrailBlazer Plus)
>
Mine:  Macintosh IIci, 8mbram, 650mb, A/UX 2.0, Trailblazer t2500
Maybe the ci acts differently (unlikely, I think).  Maybe you have
a different version of getty. Mine is:

-rwx------   1 bin      bin        26988 Apr 10  1990 /etc/getty

Maybe you are using a serial port board in the NuBus which fixes
the problem. I am using the built-in modem port. Maybe you have echo
and result codes turned off when calling out, and haven't noticed that
your /etc/issue and login prompt are being sent to the port. Maybe it
has something to do with the phase of the moon :-)

Now, about that flow control - I have already e-mailed Paul about this,
but I wanted to make it known to the net:

>--
>GETTYDEFS
>--
>pd_2400# B2400 # B2400 HUPCL SANE2 TAB3 # ~MODEM ~DTR ~FLOW #login: #pd_1200
>
>[stuff deleted]
>
>BL_19200# B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # B19200 HUPCL OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD # FLOW ~DTR ~MODEM #Apple Canada, Inc. (mauxci) \r\n\nlogin: #BL_19200
>
>Note: I only use the 19200 line for my TrailBlazer so it points back to itself.
>The modem does the baud adjusting. I am using Hardware flow control.
>

This is a SERIOUS security problem.  In order to get the hardware flow
control working, you are disabling modem control.  Modem control is
absolutely essential on an incoming dial-up line.  The system MUST have
access to the carrier detect line from the modem (which is clipped on
Paul's cable diagram).  Otherwise, it will be unable to detect when
someone has hung up without properly logging out.  Humans, at least, do
this all the time.  That means that the next caller will get the
previous caller's shell, including all priveleges!!  This setup can also
cause several other less serious but potentially nasty problems.  DON'T
DO THIS!!!

Summary:

1. A/UX (at least with built-in serial ports) doesn't support modem
control and hardware flow control at the same time.

2. You MUST have modem control on an incoming line.

3. Therefore, you CAN'T use hardware flow control. Period.

4. Therefore, if you are using a Telebit, you can't use auto baud rate
   adjusting on incoming uucp calls. You must set S50=0 and use the normal
   method of sending breaks to cycle getty until the proper speed is
   attained.

>.  Paul E. Dumais   A/UX Specialist 	 	Apple Canada, Inc.	     .
>.  Internet: dumais at apple.com			7495 Birchmount Rd.	     .


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|  Jeff Mann  Inter/Access Artists' Computer Centre, Toronto  [416] 535-8601 |
|  intacc!mann at cs.toronto.edu   Matrix Artists' BBS: [416] 535-7598 2400 8N1 |
| ...uunet!mnetor!intacc!mann  mann at intacc.uucp   [416] 535-1443 Telebit 8N1 |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-