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?

link|improve this question
1  
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
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
1  
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
show 3 more comments
feedback

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

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

2 Answers

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

ip link set eth0 mtu 1400

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

link|improve this answer
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
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
Thanks for the pointers. I found another article here that nicely explains why lower MTUs might be better. – Chandranshu Mar 29 '11 at 14:09
1  
@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
@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. – Chandranshu Mar 30 '11 at 5:43
feedback

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.

link|improve this answer
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
feedback

Your Answer

 
or
required, but never shown