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

[Pieter Donche]

On Fri, 5 Jun 2009, Maarten Bezemer wrote:

> On Thu, 4 Jun 2009, Pieter Donche wrote:
>
> > The problem is solved, but still is puzzling ... I summarize:
> [..]
> > - the problem was SSH related (SCPing a large file on target machine via 
> > scp initiated on the backup server, also got 'stalled' and finally 
> > "connection lost", using FTP to transfer the file : no problem..
> >
> > - the target machine is behind a firewall. And that firewall has a 
> > limitation set up for SSH, to counter Brute Force SSH attacks: if more than 
> > 3 SSH login requests are performed from a same machine in a minute, one has 
> > to wait a minute before a next request will be honoured.
> [..]
> > Has anyone any ideas to what might be going on ?
>
> At first, my guess was that regressing took longer than some router inbetween 
> liked, resulting in a dropped connection, since regressing doesn't exchange 
> data for as long as it's running (at least when not running very verbose).
> Now, with your scp test stalling, it seems that dropping the connection 
> because of not sending any data may not be your only problem here.
> FTP and SCP have only very limited knowledge of the underlying tcp stack, so 
> should behave similar. 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.

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

> Apparently it is either dropping existing, active connections, or it is 
> failing to get some packets through properly. Maybe related to MTU/MRU 
> limitations somewhere along the path.
>
> 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).
>
> HTH,
> Maarten