From owner-freebsd-questions@FreeBSD.ORG Thu Aug 9 12:20:09 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CC6916A419 for ; Thu, 9 Aug 2007 12:20:09 +0000 (UTC) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: from gizmo.acns.msu.edu (gizmo.acns.msu.edu [35.8.1.43]) by mx1.freebsd.org (Postfix) with ESMTP id 3C06913C48D for ; Thu, 9 Aug 2007 12:20:09 +0000 (UTC) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: from gizmo.acns.msu.edu (localhost [127.0.0.1]) by gizmo.acns.msu.edu (8.13.6/8.13.6) with ESMTP id l79CGcio079458; Thu, 9 Aug 2007 08:16:38 -0400 (EDT) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: (from jerrymc@localhost) by gizmo.acns.msu.edu (8.13.6/8.13.6/Submit) id l79CGcUx079457; Thu, 9 Aug 2007 08:16:38 -0400 (EDT) (envelope-from jerrymc) Date: Thu, 9 Aug 2007 08:16:38 -0400 From: Jerry McAllister To: Bram Schoenmakers Message-ID: <20070809121637.GB79394@gizmo.acns.msu.edu> References: <200708091025.43912.bramschoenmakers@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708091025.43912.bramschoenmakers@xs4all.nl> User-Agent: Mutt/1.4.2.2i Cc: freebsd-questions@freebsd.org Subject: Re: Problem with dump over SSH: Operation timed out X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2007 12:20:09 -0000 On Thu, Aug 09, 2007 at 10:25:41AM +0200, Bram Schoenmakers wrote: > Dear list, > > There is a problem with performing a dump from our webserver at the data > centre to a backup machine at the office. Everytime we try to perform a dump, > the SSH tunnel dies: > > # /sbin/dump -0uan -L -h 0 -f - / | /usr/bin/bzip2 | /usr/bin/ssh > backup@office.example.com \ > dd of=/backup/webserver/root.0.bz2 > > DUMP: Date of this level 0 dump: Wed Aug 8 20:58:51 2007 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping snapshot of /dev/da0s1a (/) to standard output > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 60746 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > Read from remote host office.example.com: Operation timed out > DUMP: Broken pipe > DUMP: The ENTIRE dump is aborted. Note: I have been getting something that looks very similar when I try to dump a large file system - actually not all that large, just about 30 GB - over the net to a different machine. The one with the tape is running a quite old FreeBSD - around 4.9 I think - and can't be upgraded at the moment. The one I am attempting to dump is on 6.1 - which I want to move to 6.2, but have been stalling because I haven't been able to get a good dump. I don't have anything to add to Bram's facts here, just that the timeout like this is happening on another system too. ////jerry > > Here are some facts about the situation: > > * The client (where the dup takes place) runs FreeBSD 6.2-RELEASE-p4 > * The server (at the office) runs FreeBSD 6.1-RELEASE > * Both hosts have ipf installed > * Some IPF rules from the client: > > pass out quick on bge0 proto tcp from any to any flags S keep state > pass out quick on bge0 proto udp from any to any keep state > pass out quick on bge0 proto icmp from any to any keep state > pass out quick on bge0 proto gre from any to any keep state > pass out quick on bge0 proto esp from any to any keep state > pass out quick on bge0 proto ah from any to any keep state > > block out quick on bge0 all > pass in quick on bge0 proto tcp from any to any port = 22 flags S keep state > > block return-rst in log quick on bge0 proto tcp from any to any > block in quick on bge0 proto tcp all flags S > block return-icmp-as-dest(port-unr) in log quick on bge0 proto udp from any > to any > block in log quick on bge0 all > > * Some IPF rules from the server: > > pass out quick on re0 proto tcp from any to any flags S keep state > pass out quick on re0 proto udp from any to any keep state > pass out quick on re0 proto icmp from any to any keep state > pass out quick on re0 proto gre from any to any keep state > pass out quick on re0 proto esp from any to any keep state > pass out quick on re0 proto ah from any to any keep state > > pass out quick on re0 proto tcp from any to any port = 22 keep state > > pass in quick on re0 proto tcp from any to any port = 22 flags S keep state > > block return-rst in quick on re0 proto tcp all flags S > block in quick on re0 proto tcp all flags S > block return-icmp-as-dest(port-unr) in log quick on re0 proto udp from any to > any > block in log quick on re0 all > > * I've tried with TCPKeepAlive off > * Setting ClientAlive{Interval,CountMax} on the server did not improve things. > * Setting ServerAlive{Interval,CountMax} on the client neither, although I got > a different error: > > DUMP: Date of this level 0 dump: Wed Aug 8 21:05:26 2007 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping snapshot of /dev/da0s1f (/usr) to standard output > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 429177 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > Received disconnect from xxx.xxx.xxx.xxx: 2: Timeout, your session not > responding. > DUMP: Broken pipe > DUMP: The ENTIRE dump is aborted. > > * A dump from the client machine to another server works fine. The receiving > host has a similar internet connection as the office (cable). > * A dump from another webserver of ours, running FreeBSD-4.10-RELEASE in > another data centre can dump fine to the office with the same construction. > This webserver uses IPFW. > * Uploading a big file (200M) over SFTP to the 6.2 webserver causes no > problems. > * 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. > > Read from remote host office.example.com: Connection reset by peer > debug1: Transferred: stdin 0, stdout 0, stderr 77 bytes in 103.3 seconds > debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.7 > debug1: Exit status -1 > lost connection > > * Maybe the MTU value was the cause, but setting them to 1472 on both sides > didn't improve the situation as well. > > So as you may see I've tried a lot of things in order to make the dump work, > but so far no luck. Probably I'm missing something crucial. I think it has > something to do with the statetables in the firewall, but I was not able to > succeed with that assumption. > > Any suggestion is very welcome. > > Kind regards, > > -- > Bram Schoenmakers > > What is mind? No matter. What is matter? Never mind. > (Punch, 1855) > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"