Re: [rdiff-backup-users] SSH time out, how to remedy? [Scanned]

[Pieter Donche]

On Fri, 5 Jun 2009, Maarten Bezemer wrote:

> On Fri, 5 Jun 2009, Pieter Donche wrote:
>
> > > However, data connections in FTP can be both active and passive, meaning 
> > > that they can be originated at local or remote side. What type of FTP did 
> > > you test?
> >
> > FTP was started on the backup server, to fetch a large file on the target
> > machine.
>
> That wasn't what I meant. Did you use passive FTP or active FTP file 
> transfers, and/or does that make any difference.

both backup server and target machine are FreeBSD7.2. The FreeBSD ftp command 
uses default passive mode (man ftp) One could use option -A: force active
mode [man ftp: It is only useful for connecting to very old servers that 
do not implement passive mode properly.] but this was not used.

> > > For now, especially since you say that tweaking the firewall settings 
> > > 'fix' your problem, I'd say your firewall device is screwing things up.
> >
> > As I said, there were never problems when the backup server and target
> > machine were in the same building (different subnets), but the problem
> > arose when the backup server was moved to a different building 5 kms away.
> >
> > For some reason when backup server was still in same building as target,
> > the situation of receiving more than 3 requests per minute did not
> > happen, so the firewall didn't drop anything.
> >
> > Now it seems this situation does happen and the firewall acted upon
> > that situation.  The question is how can this situation now happen...
>
> rdiff-backup opens an ssh connection only once, so that shouldn't trigger 
> your firewall.
> Is this firewall a separate device, or maybe just Linux iptables?

the firewall is a SUSE linux computer (a PC), with Shoreline firewall (aka 
Shorewall) software, the PC has no other functions that being a firewall.

> And, if you say that the only difference is the systems now being 5km apart, 
> looking for the source of the problems in this 5km network connection is a 
> good way to start. Which leaves me with the question:
>
> > > Did you monitor failing sessions with tcpdump at both ends? That may be a 
> > > lot of data to parse through, but may be very helpful in pinpointing the 
> > > problem. Connections only time out after a lot of retransmits, and at some 
> > > point in the network between the two hosts either the data or the ack 
> > > packets get dropped (or corrupted, or wrongly rewritten by some firewall 
> > > device).

The other end is a central server room, they don't have time to do any
analyzing :-(

> Regards,
> Maarten