On Tue, 26 Sep 2000, Bruce McCulley wrote:
> It looks like the xterm session is still alive, although I just can't
> find the pixels showing me what it's doing.
Does the xterm still appear in the window list/task bar/whatever?
> mybox# ssh [EMAIL PROTECTED]
> firewall# setenv DISPLAY mybox:0
> firewall# xterm -lf xterm.log
> xterm# ssh -l my_account server.internal.net
> server# ftp mybox.mydomain.com
How are these boxes connected together, from an IP network point of view?
mybox <-----> firewall <-----> cloud <-----> server
... or ...
mybox <-----> cloud <-----> firewall
^
|
V
server
... or something else entirely?
> ... the xterm display to wink out of this universe. The ftp has continued
> for the remainder of the transfer (it was about halfway through), so it
> seems the glitch didn't affect the xterm process on the firewall ...
FTP may continue running even if the terminal it was using has hung-up if it
hasn't felt the need to read or write the terminal since.
> ... at least not enough to abort the ssh session on the server.
According to the command sequence you give, the FTP session was running
cleartext between "mybox" and "server". As was the X11 traffic between
"firewall" and "mybox". This is why I asked about the connection layout --
while SSH is encrypting the two shells you start with it, you seem to be using
cleartext sessions after that. You never setup port forwarding, nor do you
use an X11 proxy on the firewall to start the xterm. Therefore, losing SSH
would not effect the FTP data transfer.
--
Ben Scott <[EMAIL PROTECTED]>
| "...it is important to realize that any lock can be picked with a big |
| enough hammer...." -- Sun System & Network Admin manual |
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
