Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

We have a SFTP server which was working fine until we added another ISP. The connection to the SFTP server is not going through the new ISP, I confirmed it with tracert. No change was made on the server either. But since then, some users' SFTP or SSH connections time out/hang if the executed command has a larger return. Here's the scenario:

  1. I can continue to ping and the ping will always return even when SSH/SFTP times out
  2. I can connect to the server, it asks for authentication and lets me log in.
  3. If the ls command for my root directory is returning a small number of files or folders, then it shows the listing of files and folders
  4. If the ls command for my root directory is larger than let's say 5 or 6 files or folders, then it hangs/times out.
  5. While trying this, I tried running a ping to the server, and it's returning all the time.
  6. This doesn't happen to everyone, but it seems to happen to users who are in another city..

  7. I tried different SFTP clients (FileZilla and WinSCP). Both have the same issue.

I ran WireShark on my PC (which is outside of our network and outside of the city), when SFTP/SSH times out, I see retransmission and part of segment not captured errors coming up, which leads me to believe there might be some packet loss somewhere between the hops.

Expert Info (Note/Sequence): Retransmission (suspected)
Previous segment not captured (common at capture start)

Is SFTP/SSH that sensitive to packet loss? Wouldn't SSH/SFTP retransmit/reacknowledge to avoid these packet loss errors? Is there something on the server settings I can tweak in order to make this work?

share|improve this question
    
Since this is a question about a corporate, large scale network, it is off topic here. I am voting to migrate to serverfault.com. –  terdon Aug 10 '13 at 1:07
    
Thank you Terdon. Should I create this question on serverfault.com myself or will this has to be migrated? –  user2480011 Aug 10 '13 at 1:41
    
I have marked it for migration to server fault. If enough users agree, it will be moved automatically so you don't need to do anything. If you would prefer to have the question moved you can flag it for moderator attention and ask them to move it for you. –  terdon Aug 10 '13 at 8:09

2 Answers 2

I wonder if the problem is a combination of asymetric routing and MTU issues. What you describe does sound like an MTU issue.

You may be able to test/fix this by clamping your MTU - see the here for the appropriate hacks.

share|improve this answer
    
Thanks Davidgo. It happened to be an issue with packet fragmentation in the ISP side. One of their hop probably doesn't have the correct MTU set. –  user2480011 Aug 12 '13 at 20:10

Short Answer:

You probably have an MTU/fragmentation problem. Try setting the MTU to 576 for the network interface on the client, eg ifconfig eth0 mtu 576.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.