> I am trying to set up a telecommuting system for my company.  One
> thing I have noticed is that if a remote user has established a TCP
> connection (`rlogin', say) over PPP, and the PPP connection goes down
> for a while -- I haven't taken the time to figure out exactly how
> long -- the TCP connection will be closed.

This is almost certainly due to keepalives, which are designed for
exactly this: to ensure that if connectivity is lost, the connection
goes.

Someone mentioned a way to make rlogind not enable keepalives.  If the
rlogin client in use doesn't do them, or can be made to not do them,
this could work.

Other people have been babbling about standards violations.  These
people should probably go read the relevant RFCs.  In the absence of
data being sent over a TCP connection, there is no requirement that
anything at all be sent.  And indeed, I have seen connections survive
extended (multiple hours) connectivity outages, coming back to life
instantly when they are used, provided of course connectivity is back
up at the time.

Keepalives (use of which AFAIK is neither required nor forbidden by any
RFC, though making them available to network programs may be) are
_designed_ to make the connection go away if the connectivity does;
basically, if you don't want 'em, don't use 'em. :-)  NetBSD rlogind
has a -n option, which disables them; NetBSD rlogin doesn't use them,
leaving them up to the server.

> It would be nice if we could arrange for people to be able to hang up
> the phone for long periods -- at least 24 hours, and preferably
> arbitrarily long -- without losing their TCP connections.

As you can, provided nothing attempts to send data on the connection
and keepalives are off.

(Note that for rlogins, even if you use rlogind -n, if something (such
as biff, write, talk) attempts to send data to the login, the loss of
connectivity will be noticed.  About all you can do about this is to
use screen or some such.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu