Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It seems highly implausible, even ridiculous, to me.

I login by SSH to the CentOS server. I FTP to another server and begin a large file transfer out (uploading to other server).

After some time (usually about 3 - 30 seconds), I get kicked off SSH.

I have never had a problem on any other server where I got kicked out of SSH because of FTP bandwidth.

root@my_server [/home/my_folder/public_html]# ftp
Connected to
220 (vsFTPd 2.3.5)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name ( buttle_butkus
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd speedtest
250 Directory successfully changed.
ftp> 2gb_file.tar.gz
local: 2gb_file.tar.gz remote: 2gb_file.tar.gz
227 Entering Passive Mode (xx,xxx,xx,xx,xxx,xxx).

Connection closed by host


Server hosting company said that it's because "all of the bandwidth is being used by FTP". I have never heard of such a thing, but before I tell them they're crazy I wanted to ask the experts here.

They also suggested I change the UserBandwidth option in pure-ftpd.conf to 15. That's 15 kilobytes/s on a 100mbps connection. I guess I need to leave about 99.9mbps for SSH??

I did change it, but it didn't affect upload speed anyway (still very fast). Perhaps the setting only affects outside users logging into the server by FTP. I'm logged in by SSH, and FTP-ing out.


EDIT: Adding part of tshark captured traffic (ip addresses partially obscured):

544 111.343171 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
545 117.486826 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
546 125.464960  xx.xx.94.90 -> xx.xx.195.90 TCP [TCP Previous segment lost] ssh
> csd-monitor [SYN, ACK] Seq=498204672 Ack=2219931860 Win=8192 [TCP CHECKSUM INC
547 129.774351 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
548 154.348760 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
549 203.497887 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
550 279.243718 xx.xx.195.90 -> xx.xx.230.39 SSH Encrypted response packet len=9
share|improve this question
Dumb question of my part. Is there something like 'ServerAliveInterval' configured on your ssh_config file? This could be used like a "heartbeat" to keep the ssh ongoing – nwildner Apr 3 '13 at 2:09
Does sound like bollocks to me. – Tom O'Connor Apr 3 '13 at 10:53
It's not bandwidth. Run tshark -w capture.pcap port 21 or port 22 & before you run the FTP, then log back in after the failure and run tshark -r capture.pcap to play back the actual traffic on those ports. Might give you some clue as to what's happening. – SmallClanger Apr 27 '13 at 1:07
Should I put a nohup in front of tshark? – Buttle Butkus Apr 27 '13 at 1:17
You can open more than one terminal, you know. – Michael Hampton Apr 28 '13 at 2:52

The solution appears to have been found, but I can't be sure. The server host's customer service is horrendous. But, for now, the problem is no longer occurring. I am able to transfer large files and not get booted from SSH terminal after 20-30s.

They changed the network duplex mode to FULL, from HALF.

Check out this wikipedia article on duplex mismatch:

According to the article, duplex mismatch causes a huge traffic jam on the network. The server host customer service previously blamed bandwidth, saying that the SSH connection was being dropped because the files I was FTP-ing out were too large. They said that I should pay for more bandwidth to fix the problem. That obviously would not have helped. No matter how large the bandwidth, duplex mismatch would have overwhelmed it. I'm still not entirely clear on why that would kill the terminal session, but probably the traffic jam due to the FTP transfer holds up SSH packets that keep the session alive. But it usually drops within 20-30 seconds, which seems a bit too soon for that.

I suggested to customer service that they screwed up some settings when they installed a 100 mbps port in December ( previously it was 10 mbps). I'm not sure if was occurring before that, since we rarely need to transfer files out of there by FTP. Here is their response:

As per your request we had upgraded this server port manually to 100 mbps on 29th Dec 2012. It was correctly installed. The network mods can be changed at any time using the command "mii-tool". Did you made any changes with your networking setting or did you restarted server forcefully? I see that server had restarted 9 days before. Was that a safe restart attempt? may be that recent restart attempt changed the setting.

Do you have any other server facing this same issue? then just run the following command and make sure your server is running Full duplex mode

* ethtool eth0 | grep -i duplex

share|improve this answer

Your Answer


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.