This question already has an answer here:

I'm trying to copy a file from one of my local machines to a remote machine. Copying a file with size upto 1405 bytes works fine. When I try to scp a larger file, the file gets copied but the scp process hangs up and doesn't exit. I have to hit Ctrl-C to return back to the shell.

I have observed the same behavior with FTP as well. Any ideas about what might be causing this?

marked as duplicate by Gilles 'SO- stop being evil' linux Jul 22 '15 at 21:35

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

migrated from stackoverflow.com Jun 2 '11 at 0:23

This question came from our site for professional and enthusiast programmers.

  • 3
    The disk is nearly full and only has 1405 bytes left? Your firewall only allows one packet to pass (assuming 1500 MTU)? What does rsync do? Can you create the file manually? Does it work in the other direction? – Konerak Mar 29 '11 at 13:15
  • I don'thave an answer per se, but the size suggest to me that the network and packet size somehow is involved. I have found Wireshark and/or tcpdump good tools for troubleshooting in the past. – JenEriC Mar 29 '11 at 13:18
  • 1
    You say the file does get copied. Have you checked the contents to verify the whole file has been copied, or do you base the conclusion solely on the appearance of a file with the correct size in the target path? – Mels Mar 29 '11 at 13:18
  • @Konerak: The disk has lots of free space. The MTU is indeed 1500 but there is no firewall. The machine is directly behind a router. I can copy to the server from other machines. So, I think that is equivalent to be able to create the file manually. I can't check its working in the other direction as the client machine doesn't have a public IP. – Chandranshu Mar 29 '11 at 13:21
  • 4
    If you have a clean log, it certainly won't hurt to have it included. If you can mess around with the MTU size, try to decreae it and see if the problem decreases with the same amount; it might help someone to figure out whats going on. – JenEriC Mar 29 '11 at 13:32

This definitely sounds like MTU problems (like @Konerak pointed out), this is how I would test this:

ip link set eth0 mtu 1400

This temporarily sets the allowed size for network packets to 1400 on the network interface eth0 (you might need to adjust the name). Your system will then split all packets above this size before sending it on to the network. If this fixes the scp command, you need to find the problem within the network or make this ugly fix permanent ;)

  • 1
    This fixed it. Could you please point out why setting MTU to a lower value works? Just a pointer would be enough. – Chandranshu Mar 29 '11 at 13:32
  • 1
    See the Wikipedia page on MTU (look out for PPPoE) and maybe RFC 2516 wich suggests an MTU of 1492 when behind a home router. – Stephan B Mar 29 '11 at 13:40
  • 2
    @Chandranshu I'd like to point out that matching your network MTU to some ancient ATM header size is no longer important with current internet backbones, so if 1492 works for you - go for it ^^ – Stephan B Mar 29 '11 at 14:17
  • 3
    If his solution worked, you might want to accept his answer as valid so he gets the bounty. :) – Shadur Jul 16 '12 at 20:58
  • 2
    @psusi, shortly after I had reduced the MTU on this machine (which was at a client's office), we got to know that they were facing this issue while connecting to a number of hosts. It also began showing up for some other clients in the same area. It turned out that the common culprit in this case was the ISP who had setup a blackholing router by error as part of infrastructure 'upgrade'. – Chandranshu Jan 7 '13 at 8:31

Consider that the MTU is typically 1500 B (due to the limitations of ethernet). Of those 1500 B not all are used for 'data'. So-called protocol overheads take a hefty chunk out of the 1500.

  • SCP (uncompressed) requires a 65 B header.
  • TCP requires a 20-60 B header.
  • IP requires a 20-60 B header.

In light of this, it's not so surprising that your payload is limited to 1405 B.

P.s. Have a play with wireshark and check the IP headers. Are they allowing packet fragmentation?

  • 1
    The ssh protocol overhead goes into the TCP byte stream, not each individual packet. TCP obviously is aware of, and accounts for the size of its and IP's headers. – psusi Jul 22 '12 at 22:38

Sounds like bad hardware to me. If it's only one machine on the LAN, it might have a bad Ethernet card; if it's all machines on the LAN, I'd check the hub or router.

  • 1
    I disagree. If faulty hardware were in play, Chandranshu would very likely have difficulties in lots of other areas as well. Unless he's using some sort of h/w encryption acceleration device for the SSH connection, or something like that.. – Mels Mar 29 '11 at 13:20
  • @Mels: I am indeed facing problems while uploading files through even FTP. I also tried using HTTP to POST the file to a web server and the connection there hangs as well. May be I'll try with another network card. – Chandranshu Mar 29 '11 at 13:25
  • @Chandranshu: but you are able to browse the web using that machine? That's essentially the same thing. Is it always the same file you're trying to upload? Perhaps some kind of Deep Packet Inspection firewall is false-positive'ing on the contents of the file, thinking it's malware? – Mels Mar 29 '11 at 13:33
  • @Mels: To answer your question, I don't have a web browser on the machine. However, I could successfully issue GET requests and copy files from other remote machines. The problem used to appear only when large traffic originated from this machine. Stephan's answer above has helped me track down this problem and resolve it. – Chandranshu Mar 30 '11 at 5:48

Sounds like a bad router configuration, data packet transfer limit should be less amount I think


There is some kind of tunneling going on between the source and target machines involved. TCP will transmit an MSS when opening the connection (that will be used for ssh/scp), and this tunnels along the way (that add encapsulation, and thus reduce the maximum available MTU) should compensate by transparently modifying said MSS en-route to the destination (and vice versa).

Some tunnel (VPN?) is not doing its job. Or the MSS on your machine is misconfigured.

I am guessing you'll see the same behavior if you ssh to the machine from which you're trying to copy, and just do an ls in an empty dir. That should work fine. But if you "cd / ; ls -lR" (and thus get large packets), this will hang as well.

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