[Box Backup] SSH Connection breaking up

Chris Wilson boxbackup@fluffy.co.uk
Thu, 3 Jan 2008 00:21:42 +0100 (CET)


Hi Guno,

On Wed, 2 Jan 2008, Guno Heitman wrote:

> It seems to me like something goes wrong with the bbackupd process and
> the ssh connection doesn't like this and is killed.

I don't think so, I think it's the other way around. There was a protocol 
error at the ssh level (which should be impossible for Box Backup to 
cause, as ssh shouldn't allow it to interfere with SSH protocol about 
which it knows nothing):

> sshd[13852]: fatal: buffer_append_space: len 1378402 not supported

This is a fatal error for sshd, so it closes the connection, which causes 
Box Backup to lose its own connection from the client to the server, and 
hence report:

> Box Backup (bbackupd)[13786]: WARNING: Exception thrown:
> ConnectionException(Conn_TLSWriteFailed) at SocketStreamTLS.cpp(403)
> Box Backup (bbackupd)[13786]: ERROR: Failed to upload file: <snip>:
> caught exception: Connection TLSWriteFailed (Probably a network issue
> between client and server.) (7/33)

One interesting thing is that you were running bbackupd (the client) on 
the same machine as sshd (the server). This isn't impossible but it does 
imply that your architecture is somewhat strange. Perhaps you're backing 
up to a machine on DSL with a dynamic IP address, from a server with a 
static address? Or did I misunderstand the situation/configuration?

> I've found an old
> post to this list that might be related:
> http://lists.warhead.org.uk/pipermail/boxbackup/2005-March/001271.html

Sorry, as far as I can tell that's not related at all, it's an error 
during restore (not backup) that should in any case be fixed now (but I 
haven't tested it) and doesn't involve ssh at all, but was or is 
definitely a bug in Box Backup at the communications layer.

> Anyone have an idea what could be wrong, or how I can get more detailed 
> information on what goes wrong?

First of all, please check out this bug report:

   http://www.mail-archive.com/debian-ssh@lists.debian.org/msg03193.html

and try disabling compression and control sockets on the ssh client.

If this doesn't solve the problem, I'd start to suspect both the hardware 
and the versions of openssh on both ends of the connection. I'd 
investigate whether anyone else had reported problems with that version of 
openssh and whether any other unexplained mysteries might indicate a 
hardware problem such as bad RAM. I'd also consider checking the memory on 
both ends using memtest86 for 24 hours if that's not too disruptive.

Then I'd try upgrading to the latest version of openssh on both ends, to 
see if that solves the problem. If not, then I'd enable maximum debugging 
in openssh and open a dialogue with the developers via their mailing list 
to get their help in fixing the problem.

While or instead of working on solving the problem with them, you could 
try another VPN-type solution such as OpenVPN or CIPE to create the 
tunnel.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |