Re: conserver -> cyclade, ssh timeouts

On Mon, Oct 10, 2005 at 09:49:38PM -0400, Christopher Fowler wrote:
> Tune the keep alives to be more often.  I think the default is 7200
> seconds.  Make it 300?
> 
> I had the same issue with VPN tunnels between devices that needed to
> stay connected but were quiet.  I told pppd to send an echo packet every
> 60 seconds.  That solved that problem.
> 
> Some firewalls/routers may be intelligent enough to see a keep alive and
> not count it.  I'm not a pro on that subject so I'm not sure.
> 
> What concerns me most is why the Cyclades box does not see the failed
> connection.  when this happens are you basically locked out of that port
> until you do something like a reboot on the Cyclades?  If so I would
> call support and ask if there is a patch that fixes this.  
> 
> On Mon, 2005-10-10 at 18:33 -0700, Phil Dibowitz wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > I'm having a problem where the ssh connection from conserver to the
> > cyclades times out, and the ssh client sees it happen, and thus
> > conserver sees it happen - but the cyclade never sees this happen, and
> > thus the sock_sshd for that port lives on and the cyclade can never connect.
> > 
> > I know this is more of a cyclades question and less of a conserver
> > question - but I figure this is probably one of the best places to ask
> > if anyone's run into this.
> > 
> > Presumably the connection dies because there are firewalls in between
> > the two boxes that limit inactive state timeouts.
> > 
> > I've tried turning on keep alives on both sides... but haven't solved
> > the problem...

  I'm with Charlie on this one...when Phil says "the ssh client sees it 
happen", does this mean that the SSH session from the Conserver host to 
the Cyclades port recieved a FIN, to close the session? If so, can you
tell if the firewall sent the FIN (maybe because it was going to drop
an idle connection?), or did the SSH client itself timeout, and try to
send a FIN to the Cyclades, while closing the connection to Conserver?
Maybe the firewall has closed the idle-looking session by then.

  In the 'plain vanilla' telnet world, it was pretty common to see a
reverse TCP session (or many) be initialized, and then have the host
crash, or otherwise need to be rebooted. At that point, the host had
no chance to send a FIN to any of the reverse TCP sessions prior to
the reboot, and all of those sessions were lost in the reboot.

  When the host recovered, and tried to re-make the reverse TCP
sessions, it woudl be refused, as the sessions were already in use...

  On the console server, the session is still established. Just because
it hasn't heard from the host doesn't mean there is a problem. BUT, if
something comes in the serial port, and the console server tries to send
it to the coresponding session on the host, the host never answers, and
the Console Server will close *that* session because the host was not
answering. If nothing comes in the serial port, to stimulate that action,
the session could stay up indefinitely.

  In these cases, you woul dneed to log into the conosle server, attain
elevated privileges, and "clear" or "reset" the line(s) in question.
An ugly solution, but the alternative is rebooting the Console Server.
(Clearing the lines manually will preserve the uptime on your Console
Server, if such metrics are important to you. ;-)

  I like the 60-second timeout. A bit chatty, but not bad. Which firewall
or VPN solution are you trying to plumb this through? :-)

        -Z-