Why does SCP hang on copying files larger than 1405 bytes?

networking scp ftp

46,674

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 ;)

46,674

Author by

Chandranshu

Full-stack generalist. Mostly work in Ruby on Rails and Javascript. Can write shell scripts and debug Linux system issues.

Updated on September 18, 2022

Comments

Chandranshu over 1 year

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?
Admin about 13 years

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..
Admin about 13 years

@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.
Brian Redbeard about 13 years

This fixed it. Could you please point out why setting MTU to a lower value works? Just a pointer would be enough.
Admin about 13 years

@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?
Brian Redbeard about 13 years

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.
Brian Redbeard about 13 years

Thanks for the pointers. I found another article here that nicely explains why lower MTUs might be better.
Brian Redbeard about 13 years

@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 ^^
Brian Redbeard about 13 years

@Stephan I found another article which suggested pinging a remote machine with the DF bit set with increasingly larger packet sizes to figure out the optimal MTU. Using that, I have set my MTU to 1472. Anything larger and my old problem resurfaces.
Admin about 13 years

@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.
phemmer almost 12 years

@Chandranshu this should not be necessary. The IP protocol is designed to accommodate for mismatched MTU sizes. Your'e not doing something horrible like blocking all ICMP packets are you?
psusi almost 12 years

@Patrick, IP fragmentation is horrible for performance, so TCP disables it and relies on getting ICMP feedback when a router finds the packet too large and will start sending future packets smaller until they fit. Stupid routers ( the kind that use PPPoE, which steals 8 bytes for its header ) often don't bother sending those messages.
phemmer almost 12 years

@psusi and setting a lower MTU for ALL traffic is better than having traffic for a single destination require frame size negotiation?
psusi almost 12 years

@Patrick, yes... if the problem is a single ( or few ) destination(s). In this case, the problem router is on his end, so it makes for a reduced MTU to ALL hosts, and also prevents the auto sizing mechanism from working, thus, you need to manually lower the MTU.
Chandranshu over 11 years

@Shadur: I had originally asked this question on stackoverflow and it was shortly moved here thereafter. So, I was delayed in accepting this answer well by over an year.
Chandranshu over 11 years

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