Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
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' < thingthen 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.