mmorse@note.nsf.gov (Michael Morse) (02/24/88)
While you wizards are thinking about problems of people's sessions
continuing after they hang up the phone, perhaps you can help me with
mine...
Here's the situation: We have a MICOM 600 port selector connected at
one end to 1000 PC's running terminal emulators, and at the other
end to ports (DHU11's) on a VAX 785 running ULTRIX 1.2. Very
occassionally, a user will tell the MICOM to connect to a VAX port,
but instead of getting the "login:" prompt, will be directly connected
to an already existing session, and therefore just get a shell prompt.
Assuming that a user is disconnecting from the MICOM, but the signal is
not getting to the VAX, I've tried to duplicate the problem, while
watching the signals on a datascope. Try as I might I've been unable
to duplicate the problem. When I'm watching, all the signals work
fine. That is, the PC's line to the MICOM drops DTR, the MICOM drops
DTR to the VAX, and login or the shell recognizes the hangup and
disappears.
Here are some clues:
1. We are *not* running ULTRIX login. We are running a login
from BSD that uses a hashed database.
2. The abnormal disconnects seem to always occur during login.
In other words, if the intruder (the person who gets into
someone else's session) does a "who am i" and then lastcomm,
it is obvious that the intruder has invoked all the commands
other than those in the other person's .login file.
3. Strangely, the intruders seem to be a random lot, but the
people whose privacy is being invaded are all on one floor
of the building, approximately 50 out of 1000 PC's. This
would seem to indicate some kind of hardware problem, except
that these people are also among the very few that know how to
make their PC's drop DTR. The other 950 people either don't
have modem signals in their data lines, or don't know how
to set them. In addition, one person in the group of
"privacy losers" has managed to make this happen when
connecting through our X.25 PAD installed in the MICOM.
4. Most of the users run the "new" csh distributed with ULTRIX
1.2 (has file name completion, autologout variable).
My original theory was that at some point in the login process the VAX
is ignoring hangups. If these users happened to hang up exactly at
that point, the MICOM would disconnect the line, but login would go on
its merry way and invoke the csh to process .login. Since the line
was free as far as the MICOM was concerned, it was free to connect
another user to the port. The problem with the theory is 1) I've been
unable to duplicate the problem, and 2) several readings of the source
code for login don't seem to indicate the possibility of such a
window. Other than that the theory fits the facts that I've
collected.
We are going to replace the hardware (cables and muxes) that connect
the privacy losers to the MICOM, but I don't have much confidence that
that will provide any clues. It appears that the MICOM is seeing the
disconnect (it considers the port free), so it's unclear what the
muxes could be doing wrong.
Has anybody seen this kind of intermittent problem? I'm assuming that
the VAX configuration is correct, since it works properly 99% of the
time. Does anyone know login well enough to suggest whether my theory
is possible? Most of the users have the following commands in their
.login:
set noglob;eval `/usr/ucb/tset -n -Q -s -I`
/bin/stty -tabs decctlq -lcase
Could these cause problems? Are there any commands that could present
a small window where hangups could be ignored? The VAX is usually
extremely loaded (load average 10 to 20) when the problem occurs.
Any ideas that anyone could contribute would be greatly appreciated.
We see a couple of these a week, so it's pretty annoying.
Thanks in advance,
Mike Morse
Michael Morse Internet: mmorse@note.nsf.gov
National Science Foundation BITNET: mmorse@NSF
Telephone: (202) 357-5942