PuTTY wish two-way-keepalives

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: An alternative form of keepalive which is two-way
class: wish: This is a request for an enhancement.
difficulty: fun: Just needs tuits, and not many of them.
priority: low: We aren't sure whether to fix this or not.

Anecdotal evidence suggests that at least one type of router is not fooled by PuTTY's current SSH keepalive mechanism (sending SSH_MSG_IGNORE): it ignores them and disconnects idle sessions regardless. I asked the user in question to experiment with using repeat key exchanges as an alternative form of keepalive, and that turned out to work fine.

This leads me to suspect that the router has noticed that the SSH_MSG_IGNORE keepalives only transfer data in the client-to-server direction: although TCP packets must come back the other way carrying acks, no actual data is transferred down the TCP connection from server to client. Rekeys transfer real data in both directions, so they work better for this purpose. (However, they're very CPU-intensive compared to what a keepalive ought to be.)

It wouldn't be very difficult to rig up an alternative form of keepalive, at least in SSH-2, which requested an actual response from the server. The obvious approach would be to invent a spurious SSH_MSG_GLOBAL_REQUEST ID which no servers would understand, so that they would respond with SSH_MSG_REQUEST_FAILURE. Much like the OpenSSH "client alive" feature, in fact.

I envisage this being implemented as a checkbox with wording something along the lines of "Use two-way keepalives where available"; then we could implement it in SSH-2 immediately, and add it to other back end protocols if and when we thought up ways to do it. (For example, it's not entirely impossible that there might be some fiddly way to make it work in Telnet, perhaps by periodically sending IAC WILL followed by a non-existent option number; but I haven't tried it and can't be sure.)

If you want to comment on this web site, see the Feedback page.
Audit trail for this wish.
(last revision of this bug record was at 2005-03-10 11:55:27 +0000)