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

[Maarten Bezemer]

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?

For now, especially since you say that tweaking the firewall settings 
'fix' your problem, I'd say your firewall device is screwing things up.
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