up vote 3 down vote favorite
share [g+] share [fb]

I need to create an ssh connection between two Linux machines running Centos v5 but the latency could be as high as 25 seconds. I find that if I test something approaching this configuration artificially by simulating 7 seconds or more round trip latency using:

tc qdisc add dev eth0 root netem delay 7s

When I try:

ssh -n -o ConnectTimeout=0 WilliamKF@centos5Machine whoami

It fails after about 1 min 23 sec with:

Connection closed by 10.35.50.114

Note that ConnectTimeout=0 means never timeout. Also, simulating a round trip latency of 6 seconds results in a successful ssh after about 1 min 32 sec.

Is there anything I can do to get ssh to work in the face of extremely high latency on Linux? Why does ssh fail at this threshold? When I run tcpdump, I see nothing obviously wrong, there are about 51 packets, which packets of tcpdump are helpful here? Success took only around 41 packets.

link|improve this question
100% accept rate
2  
Is there a chance that correcting the 30 second latency is a possibility? That is beyond ridiculously high. What happens when you ping 10.35.50.114. What does trace route show? – Everett Nov 19 '10 at 16:26
i'm thinking a ridiculous amount of proxying is in place....i agree with reeeeeediculous proxies, so i am interested in responding...give me some time to look about and check source code. – aking1012 Nov 19 '10 at 18:04
1  
it may require a recompiled ssh library...is this okay? – aking1012 Nov 19 '10 at 18:05
1  
Just so I understand. You have latency between your client, and some server while using SSH. You are simulating this latency bewteen your client, and another computer you have available to you? What I am saying is, latency that high would put your client, and the server you are trying to log into, approximately 60 times the circumference of the planet apart. That is a LOT (see UNGODLY) amount of latency. There is a problem that needs to be fixed between the two computers. Trying to program to correct for that large of a failure is really the wrong way to approach the problem. – Everett Nov 20 '10 at 5:36
1  
The reason is this: you are trying to allow for 25 to 30 seconds of latency for each part of the networking connect process. This doesn't just set it up so your application waits 25 to 30 seconds, you wait 25 to 30 seconds for transmission, and response, of EVERY packet. If ONE packet gets dropped in a connection based protocol, you wait for retransmit. You will NEVER see a successful connection with 30 second latency because you will likely overflow every buffer you have access to. – Everett Nov 20 '10 at 5:39
show 4 more comments
feedback

1 Answer

up vote 1 down vote accepted

Short answer, you will never wait long enough with a 30 second latency per packet.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

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