PuTTY semi-bug winadj-success

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: Bombing out with 'Received SSH_MSG_CHANNEL_SUCCESS for "winadj@putty.projects.tartarus.org"'
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
priority: high: This should be fixed in the next release.
absent-in: 0.60
present-in: 2008-03-28 2008-12-01
fixed-in: r9185 3a649ed4edf0248afdc4c67e44ef2cdd8f4d472a 2011-07-02 (0.61)

We've had a few reports of SSH connections bombing out with the following error message, reportedly under load:

PuTTY Fatal Error

(X)  Disconnected: Received SSH_MSG_CHANNEL_SUCCESS for
     "winadj@putty.projects.tartarus.org"

                      [   OK   ]

This message has only existed in PuTTY since the flow-control feature was implemented, which was after we released 0.60; so only people using development snapshots, or third-party code incorporating development code, should have seen this.

On the face of it, it looks like the SSH server -- which in all the cases positively identified so far is "boks_sshd" -- is incorrectly responding to our unilaterally-defined channel request message with SUCCESS, which it should never do since it's something we made up. (Our documentation mandates a FAILURE response, but that's only a restatement of the RFC 4254 requirement for a FAILURE response to requests that aren't understood -- we don't expect any server to specifically handle this message.)

The maintainers of boks_sshd, foxt.com, acknowledged this server issue (case 090916-090424). It was fixed in BoKS 6.5.4, released on June 2, 2010.

The obvious workaround for the behaviour of old versions of this server behaviour is to just ignore the protocol error, and quietly treat a (bogus) SUCCESS response to "winadj@putty" the same as a FAILURE response -- it won't do any harm, since all we're interested in is when the server replies; we don't actually care about the content. So we did that.

Reports:


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2017-04-28 16:52:45 +0100)