💾 Archived View for gemini.susa.net › putty_windows7.gmi captured on 2022-03-01 at 15:19:35. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

PuTTY, Windows 7, unreliable network

I've been having problems with SSH to servers in my home over powerline adapters. The sessions would drop periodically, perhaps every 20 minutes or so, but less often when the session was being used.

I had been making the assumption that something was getting messed up somewhere on the MAC layer, but I think I've been entirely wrong on that. It seems that, with unreliable connections, PuTTY is more or less compelled to drop the connection because otherwise the connection is vulnerable to MITM attack.

The problem seems to have disappeared with the following settings: -

PuTTY Configuration -> Connection

Sending of null packets, Seconds between keepalives: 180 (was 5)
Disable Nagle's algorithm: Unticked
Enable TCP keepalives: Ticked

Of these, I think it's the seconds between keepalives that was breaking things. With an unreliable connection, there may be times when the network seems 'down', and with very frequent keepalives the chances of the system deeming the connection broken is higher.

TCP keepalives may be more useful for ensuring that half-open connections are terminated than for keeping a connection alive.

And from null-packet keepalives documentation: -

Note that keepalives are not always helpful. They help if you have a firewall which drops your connection after an idle period; but if the network between you and the server suffers from breaks in connectivity then keepalives can actually make things worse.

Basically, without keepalives, a network can go down and back up without it ever being noticed. With keepalives, you kind of force the system to notice.

Windows Registry

There was also talk of a Windows registry value to help this: -

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
DWORD TcpMaxDataRetransmissions = 15

It's claimed that this makes Windows try longer to get TCP packets through. It defaults to 5, so the new value triples the time it takess. It seemed to make no difference to me, if anything it's more likely to make genuinely broken connections take longer to fail. I'll probably change this back to the default value of '5'.