Super User is a question and answer site for computer enthusiasts and power users. 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
  1. I have a TCP connection (SSH session to some computer for example)
  2. Network suddenly goes down and drops all packets (disconnected cable, out of range).
  3. TCP resends packets again and again, retrying with increasing delays.
  4. I see the problem and plug the cable back (or restore network somehow).
  5. TCP connection finally successfully resends some packet and continues.

The problem is that I need to wait for a some timeout on point 5. I want to use my opened SSH session now and not wait for 5-10 seconds until it finds out that connection is working again.

How to force all TCP connections to resend data without delays in GNU/Linux?

share|improve this question

Do you know that the IP connection has been established at time (4)? With DHCP / WiFi / WPA / ARP / Zeroconf there is data-link renegotiation that could easily take 5 seconds between carrier on and ability to pass even one IP packet.

If this is so, The SSH session may not be the limitation, and forcing a TCP resend wouldn't help at all.


Dunno, I can't reproduce it. I had an open SSH connection between machine .2 and .3 with .3 printing the time to stdout every second. The two machines are running vanilla Ubuntu Lucid and connected through a boring WAP/Switch/Router. The machines are DHCP configured. I pulled the cable from machine .3 and waited a scientifically accurate (looked at clock) interval of 60 seconds. Here is the packet trace:

No.  Time        Source                Destination           Protocol Info
  18 8.479990            SSH      Encrypted response packet len=48
  19 8.480024            TCP      56670 > ssh [ACK] Seq=1 Ack=433 Win=1002 Len=0 TSV=2804876 TSER=44100246
  20 87.619215   AsustekC_f1:59:70     Broadcast             ARP      Who has  Tell
  21 87.619221   AsustekC_24:9c:85     AsustekC_f1:59:70     ARP is at 00:1a:92:24:9c:85
  22 87.619527            SSH      Encrypted response packet len=48
  23 87.619545            TCP      56670 > ssh [ACK] Seq=1 Ack=481 Win=1002 Len=0 TSV=2824661 TSER=44120031

It took about 200 microseconds for the session to resume. I used the standard Wireshark for the packet sniffing.

share|improve this answer
It is two computers connected with Ethernet cable with static IP addresses. There is also software bridge (brctl addbr br0). – Vi. Jun 9 '10 at 13:43
Tested with plain TCP (without SSH) and without bridge. The same result. – Vi. Jun 9 '10 at 15:10

Take a look at the following proc entries





The number of seconds a connection needs to be idle before TCP begins sending out keep-alive probes. This can be changed by performing the following command

echo 20 > /proc/sys/net/ipv4/tcp_keepalive_time.

The default value is 7200 seconds (2 hours).


The number of retries before closing a TCP connection

echo 45 > /proc/sys/net/ipv4/tcp_retries2

Not sure if this will really help when it comes to a SSH connection as this can really depend on link speed and SSH timeout configuration.

Cheers Chris

share|improve this answer
Not helps. I've set both tcp_keepalive_intvl and tcp_keepalive_time to 1, but whne I pull out the cable, pull it back, I still have to wait about 10 seconds before the connections goes well. – Vi. Jun 9 '10 at 13:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .