3
  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?

Improve this question

2 Answers 2

Reset to default
1

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.

Update:

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    192.168.2.3           192.168.2.2           SSH      Encrypted response packet len=48
  19 8.480024    192.168.2.2           192.168.2.3           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 192.168.2.2?  Tell 192.168.2.3
  21 87.619221   AsustekC_24:9c:85     AsustekC_f1:59:70     ARP      192.168.2.2 is at 00:1a:92:24:9c:85
  22 87.619527   192.168.2.3           192.168.2.2           SSH      Encrypted response packet len=48
  23 87.619545   192.168.2.2           192.168.2.3           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.

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

Take a look at the following proc entries

/proc/sys/net/ipv4/

tcp_keepalive

tcp_retries

tcp_keepalive:

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

tcp_retries:

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

Improve this answer
1
  • 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, 2010 at 13:41

You must log in to answer this question.

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