On 12/26/2019 04:45 PM, Gordon Messmer wrote:> On 12/26/19 12:59 PM, H wrote: >> Are my observations above still consistent with your hypothesis? > > > Largely, yes.? I'm not sure why you'd be disconnected while transferring data (one of scp or sftp, right?), but it sounds like a DNAT-related limit. > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centosYes, I am using scp and sometimes, but not always, get disconnected within 10 minutes while transferring gigabyte files. I will try what you suggested in your previous post. I guess there is nothing I can change in the router itself?
On 12/26/2019 05:05 PM, H wrote:> On 12/26/2019 04:45 PM, Gordon Messmer wrote: >> On 12/26/19 12:59 PM, H wrote: >>> Are my observations above still consistent with your hypothesis? >> >> Largely, yes.? I'm not sure why you'd be disconnected while transferring data (one of scp or sftp, right?), but it sounds like a DNAT-related limit. >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos > Yes, I am using scp and sometimes, but not always, get disconnected within 10 minutes while transferring gigabyte files. I will try what you suggested in your previous post. I guess there is nothing I can change in the router itself? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centosI just looked at the settings in /etc/ssh/ssh_config on the workstation - which should apply to all users on it - I already had: Host * ?TCPKeepAlive yes ?ServerAliveInterval 60 ?ServerAliveCountMax 300 So, unless there are some other settings I should check, this should always apply when I open any ssh connection on the workstation, or?
On 12/26/19 2:49 PM, H wrote:> I just looked at the settings in /etc/ssh/ssh_config on the workstation - which should apply to all users on it - I already had: > > Host * > ?TCPKeepAlive yes > ?ServerAliveInterval 60Well, keep-alive options would only make a difference if the problem were a DNAT timeout.? If it's some other limitation imposed on DNAT, those won't have any effect. If you can reproduce this reliably and have admin access to both the server and client, you can determine whether the router is the problem: 1) Start an scp transfer of a large file 2) Use netstat or ss on the client to determine what port the client is using for the SSH connection 3) Use netstat or ss on the server to determine what port the client is using (NAT will probably change both the client's address and port) 4) Run "tcpdump -nn host <server address> and port <client TCP port>" on the client, using the values from step 2 5) Run "tcpdump -nn host <client address> and port <client TCP port>" on the server, using the values from step 3 6) Wait for the transfer to terminate I expect that when the client terminates, you'll see a TCP reset packet at the end of the output from tcpdump on the client side, but you won't see that packet in the tcpdump output on the server side.? If so, then the router is sending the TCP reset, and you'll need to work with its owners to resolve the problem. Incidentally, why are you connecting to an internal resource through an external address (NAT)?? Are you unable to connect directly to its internal address?