Why Windows 7 / PuTTY drop TCP connections even on very brief outages?

Question

I have a small local network that piggybacks on a captive WiFi, and I use ssh on OS X with -oServerAliveInterval=240 and PuTTY 0.62 on Windows 7 Professional for establishing connections to my Linode, Hetzner and other servers.

With PuTTY, I select Connection → Sending of null packets to keep session active to 240. The Enable TCP keepalives (SO_KEEPALIVE option) is off, as per defaults.

When my internet is temporarily down for about a minute (have to re-authenticate on the captive portal), PuTTY almost always loses all open ssh sessions that I have, and especially those where there was any kind of activity, but OpenSSH on OS X never loses any sessions as long as my internet is back up within about a minute or two, even if I actually try to type something in ssh, and see no reply for the whole 60 seconds or so, until my connection is active again. (So I know for sure that NAT states are always preserved.)

Can I stop Windows / PuTTY from preemptively discarding good connections?

It seems to me as if SO_KEEPALIVE or some such is actually on by default in Windows, and the timeout for detecting stale connections is way too small. I would like to increase it to something more than a couple of seconds, similarly to how OS X is immune to these brief temporary outages as long as the outage is only a couple of hundred seconds and is below the value of -oServerAliveInterval (times ServerAliveCountMax).

Solution

http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-timeout

---

It seems like TcpMaxDataRetransmissions (REG_DWORD) directly affects this. The value can be added to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters with regedit.exe (the key is missing by default, so you first have to add it in order to change it). When unset — it's 5. Add it, and set it at least to f (15), and reboot.

---

The default value of 5 seems quite inadequate for keeping connections during brief and temporary network outages; you'd get a timeout within a matter of a couple of seconds. I've added this TcpMaxDataRetransmissions key to the registry, and set its value to f (15), rebooted the machine, and after doing sysctl net.inet.ip.forwarding=0 on the router right prior to typing a character in PuTTY, got the character echoed back to me after enabling back the forwarding on my router after waiting 5 minutes (I tested it to determine that a value of 0x0000000c (12) makes the connection break up exactly 7 minutes after the first attempt at sending a packet during an outage). Prior to reboot, PuTTY would timeout the connection within a couple of seconds right away. Note that the reboot was required — at least on Windows 7 Professional, simply changing the registry has no effect on neither existing nor new connections! Nothing ever changes in Windows!

Whilst at it, might also add and set KeepAliveInterval to 60000 decimal (60 sec) from the default unset value of 1000 (1 sec), but it's not supposed to have any effect in my specific case as above, since TCP keepalives were not enabled.

Comments

[allquixotic]

Just writing in to say I have the same problem and to upvote... will be watching this question. I assume it has something to do with the network driver implementation on Windows.

[Eric Leschinski]

I've been using putty for 10 years now and haven been looking for a solution to this since the beginning. This pain point can only be mitigated, not solved. Putty requires a 100.00% reliable internet connection and 0.00% dropped packets. In the new world of always-spotty-internet everywhere, putty is becoming less and less useful as the years go by because it can only work for a few minutes at a time before you have your work interrupted, and have to restart putty, reconnect, then pick up where you left off, uncorrupt the corrupted files, and try to get your work done before the next outage.

[cnst]

@EricLeschinski, you are incorrect. This mitigation outlined in this question works just fine, I haven't had my IPv4 connections interrupted in a very, very long time. (Apart from cases where the whole IPv4 address changes, or I do a sleep etc -- for those cases, mosh is a better alternative.)