On Wed, 18 Apr 2001, Daniel Lamblin wrote:

> this is more a usability question that's port inspecific, but since I'm only
> subscribed to macppc I thought I'd mail it here.
> 
> Imagine you ssh from behind a firewall to you home netbsd machine, and edit a
> file.  You don't save it because you're not done, and someone talks to you for
> long enough to have the idle connection dropped by the firewall.  Then you ssh
> back in to the box w looks like this:
> bash-2.03$ w
>  2:03PM  up 8 days, 16:05, 4 users, load averages: 0.20, 0.16, 0.16
>  USER    TTY FROM              LOGIN@  IDLE WHAT
>  daniell  p0 nettender.mil.em 10:34AM  1:37 vi link_mp3codec 
>  rsa      p1 63.142.232.2     10:36AM     0 -bash 
>  daniell  p2 nettender.mil.em  1:37PM     0 w 
>  prak     p3 dsl092-069-098.b 12:52PM     2 -bash 
> 
> (I'm daniell), the process is still alive on tty p0, it's still my process, is
> there any signal or other odd thing I could do to connect my tty p2 to ttyp0
> and pick up where I left off, at least sending a :wq?  I know vi has the whole
> recover mode, but it tends to miss my last 1 or 2 lines, which I sometimes
> have the hardest time recalling.
> 
> is this even possible or should I just keep on killing the login shell for
> ttyp0?

Why is your firewall dropping the connection for you? I use NAT, and when
logging from inside my house to other sites, I don't have a
dropping-connection problem (*).

The only other thing I can think of is to use screen, which is in the
package collection. It lets you run a program on a virtual screen, which
you can detatch and re-attach. I use it to keep long-running icb sessions
active. You'd use "screen vi file". Then if things died, you could come in
and do a "scree -r -D" where -r means re-attach and -D means detatch it
even though it looks like the other screen is still alive.

Take care,

Bill

(*) modulo a little bug I found with tcp sessions dying when an
interveening router sends an icmp unreachable message. I've (finally) sent
the patch to the maintainer.