> Ya know, I used to have this happen to me a lot ... unfortunately, I
> forget what the solution was (other than to use rlogin, which may
> have been the final solution).

I find rlogin has its own problems.  It uses a nonexistent feature that
is approximated in at least two incompatible ways, and can break badly.
This nonexistent feature is out-of-band data over TCP.  TCP doesn't
have out-of-band data; what it does have is an urgent pointer, which is
just a pointer into the data stream.  Berkeley kludged this into an OOB
mechanism by decreeing that the byte pointed to by the urgent pointer
was an OOB byte.  (The "two incompatible ways" refers to _which_ byte
the urgent pointer is considered to point to; it's really a pointer
between two octets in the data stream.)

This worked well enough to be usable for low OOB data rates over fast
links.  When rlogin wants to send a burst of OOB stuff, especially over
a lossy connection, the receiving end can easily lose an intermediate
OOB byte, by seeing only the final position of the urgent pointer.  If
the sending and receiving end kludge OOB data in different ways, then
the OOB byte will get swapped with a data stream byte and just about
nothing will be usable.

I finally got fed up and wrote my own rlogin-like program, which uses
two TCP connections, one for data and one for the sort of control
information that would have gone over the OOB channel in rlogin.  Never
had a lick of trouble with it in operation, only the usual porting
troubles.  (It's available on request, but I don't have the NetBSD port
done yet.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu