PuTTY semi-bug winadj-success

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

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
     "[email protected]"

                      [   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:

• E2E34FB668D4874FA28658B489F40BB0028F47DA@BP1XEUEX706-C.bp1.ad.bp.com
  Using "Portable PuTTY from the Xming project" (not our code)
  but also seen with 2008-12-01:r8355
  Server claims to be "SSH-2.0-OpenSSH_4.3" -- however, if that were really true I'd have expected many more reports, and looking at the OpenSSH 4.3/p1/p2 source code I can't see how this can happen; apparently the server is actually "boks_sshd" from foxt.com.
  Seems to happen readily -- a few "ls -ltr"s are sufficient to break it
  Session log shows this happening the very first time we send one of our "winadj" requests; there aren't any ambiguities with multiple outstanding requests or anything like that.
• FileZilla ticket #3452
  (but also reported with PSFTP 2008-03-28:r7934: E00B544DC95563489A6C43CCD571EDD304EF8AFB@somodd.som.umaryland.edu)
  Reported as failure shortly after 1Gbyte of a file transfer.
• OF31BAE29C.9F8D62FE-ON862574FF.00743D6C-852574FF.007508E8@notes.wachovia.com
  Again, server claims to be "SSH-2.0-OpenSSH_4.3"
  Again, shows up under light load ("ls -l" etc)
  Again, session log shows it happens on the first "winadj" we send.
• [email protected]
  Again, shows up with "ls -l" type activity.
  Server claims to be "SSH-2.0-OpenSSH_3.8.1p1" but is in fact boks_sshd 6.0.