PuTTY bug half-closed

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

summary: PuTTY doesn't permit half-closed connections
class: bug: This is clearly an actual problem we want fixed.
difficulty: tricky: Needs many tuits.
priority: medium: This should be fixed one day.
present-in: 0.58
fixed-in: r9280 5848c8cc3d5531233540cba33802a22fe6d49439 (0.63)

By and large, where there are full-duplex connections in PuTTY, it doesn't currently support the notion of a half-closed connection - that is, end-of-file has been indicated in one direction, but data is still flowing in the other direction. This applies to actual TCP sockets and also SSH channels.

What usually happens is that PuTTY abruptly closes a socket/channel as soon as it sees EOF in either direction.

I suspect this is leading to data loss in some circumstances (so may be a/the cause of portfwd-corrupt).

What probably needs to be done is to decouple EOFs in either direction, and to sprinkle use of shutdown() and EOF notifications such as SSH1_MSG_CHANNEL_CLOSE and SSH2_MSG_CHANNEL_EOF throughout the code. This is a noticeable amount of work.

SGT, 2011-08-31: This also affects Plink in some circumstances. For instance, if you do a command along the lines of

plink myhost 'cat > thing' < thing

then Plink can (intermittently, depending on the server's window behaviour) accidentally send the SSH2_MSG_CHANNEL_EOF before the rest of the data in the channel's outbuffer. This could be sort-of-fixed by setting the pending_close flag in ssh_special rather than immediately sending the EOF message, but that's only a partial fix since it would cause sending of CLOSE rather than EOF. I think it would be better to treat that as part of the full revamp described here, and fix it in a unified way.

While I'm here, another thing we would have to work out is when to break the rule about EOFs being independent in each direction. GUI PuTTY, for instance, cannot generate an EOF from client to server, since there's no UI action to cause one; for that case we'd have to adopt a rule that has more or less the effect of the current behaviour, in the assumption that that's what login sessions generally expect.

Another possibly relevant issue is this bug which I raised against OpenSSH last year. If our channel-closing behaviour changes so that the sending of EOF is decoupled from sending the first of the CLOSE messages which actually destroy the channel itself, it would make it more convenient to work around that ambiguous aspect of the ssh-connection protocol by waiting until we've seen replies to all our winadj requests before sending the actual CLOSE.

SGT, 2011-09-13: just committed r9279 and r9280, which should fix these issues throughout the code base. However, it's quite likely I've made a mistake or two somewhere, since it was quite a complicated fix.

If you want to comment on this web site, see the Feedback page.

Audit trail for this bug.

(last revision of this bug record was at 2017-04-28 16:52:45 +0100)