Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Aug 2007 10:02:48 +0100
From:      Alex Zbyslaw <xfb52@dial.pipex.com>
To:        Bram Schoenmakers <bramschoenmakers@xs4all.nl>, freebsd-questions@freebsd.org
Cc:        Nikos Vassiliadis <nvass@teledomenet.gr>
Subject:   Re: Problem with dump over SSH: Operation timed out
Message-ID:  <46BC29B8.5050904@dial.pipex.com>
In-Reply-To: <200708091851.14649.bramschoenmakers@xs4all.nl>
References:  <200708091025.43912.bramschoenmakers@xs4all.nl> <200708091704.31952.nvass@teledomenet.gr> <46BB2730.8090702@dial.pipex.com> <200708091851.14649.bramschoenmakers@xs4all.nl>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Bram Schoenmakers wrote:

>> If you can write (and compress if short of disk space) the dump 
>> locally and
>>
>>try an scp to your remote host as Nikos is suggesting, that will narrow
>>down the problem a bit.  Any other large file will do: doesn't have to be a
>>dump.
>>    
>>
>
>As I wrote in my initial mail:
>
>======
>* Downloading the very same big file over SCP causes problems too, below some 
>SCP debug output. The connection drops quickly after it gained a reasonable 
>download speed.
>  
>
Sorry, didn't pick up the thread until late in the day.  If this is the 
case, gzip over bzip2 is not likely to be the answer, nor is any SSH 
keepalive option (though they'd be easy to try *just in case*).

Other than Nikos' PMTU suggestions I don't have much to offer.

  You could try another ethernet card if you have one to see if that 
makes any difference;

  or you can do some creative monitoring with tcpdump to see what 
traffic is being sent (try to exclude the actual ssh transfer);

  can you try the scp with *no* firewall in place;  this is straw clutching.

Presumably *some* data does actually arrive at the other end?

--Alex




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?46BC29B8.5050904>