mike@bacchus.esa.oz (Mike McCauley) (07/06/90)
Hi folks.
We've got some strange behaviour concerning rlogin, Apollo and Unisys, and I'm
wondering if anybody has seen something similar with Unisys or any other
Unix box. Or maybe its (gasp!!) an Apollo problem..... Nah.
The Apollo is a DN3500 and runs SR10.2.
The Unisys U6050 is a 386 machine which runs Unisys' version of AT&T
System V release 3 (Unisys release 3.00.11.14) with BSD4.3 TCP/IP extensions. This
OS came originally from Convergent Technologies CTIX.
The two machines are connnected by Ethernet.
The problem occurs when someone attempts to rlogin to the Unisys from the Apollo. If
the Unisys has rhosts set up correctly, and there is no password for the user you
wish to log in as, you would expect to be immediatly connected to a shell on
the Unisys. Here, this correct behaviour happens about once in ten attempts. Usually,
you get a 'password:' prompt, which no password known to humanity will satisfy. You will
then be given a 'login:' prompt which will work as expected: typing the user name gives
immediate entry. However, at this stage the shell has the TERM environment variable
(which is propagated from the source machine) to something ridiculous like 'b' or 'f'.
The previous release of the Unisys software had a similar but related problem: the
user would be immediatly logged in, but some spurious characters would be passed
to the shell before you got a chance to type at it.
My guess is that the handshaking/formatting of information between rlogin on the Apollo
and rlogind on the Unisys is being upset. I believe that rlogin first establishes
a TCP connection with rlogind and then passes the local user name, remote user name,
some environment variables, terminal speed and window size, all separated by NULs.
If the Unisys rlogind was reading all the characters that were available, then
it might see a user name of 'fred<NUL>TERM=vt100' and ask for a password. This would explain
the presentation of a password prompt and the fact that the environment
variables are screwed up.
Anybody seen this before? Is it likely to be a Unisys or Apollo problem? If Unisys or Apollo
can't or wont fix it (we have no source licences) are there any suggestions?
--
Mike McCauley voice: (03)819-4554
Expert Solutions Australia fax: (03)819-5580
1st Floor, ACSnet: mike@bacchus.esa.oz
172 Burwood Rd, Hawthorn. VIC 3122