[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 |