PuTTY artifact ssh2-romsshell-badstringlen

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 | Privacy | Changes | Wishlist

summary: Embedded RomSShell server closes connection with "Bad string Length"
absent-in: 0.60
present-in: 0.61

We've had several reports from people connecting to embedded devices of the server abruptly terminating the connection:

Server sent disconnect message type 2 (protocol error): "Bad string Length".

In the cases we've investigated, the server has turned out to be an implementation of Allegro's "RomSShell", and the server is clearly buggy.

As part of the fix for flow-control in 0.61, PuTTY sometimes sends a special request type to the SSH server with the name "winadj@putty.projects.tartarus.org", to calibrate large data transfers.

The RomSShell server objects to this request on the grounds (as far as we can tell) that its name is 34 characters long; experiments by one of our correspondents indicate that RomSShell accepts a maximum of 31 characters. The SSH-2 standard clearly states a maximum length on request names, and it's 64 characters, not 31 or 32. So RomSShell is being unreasonable in rejecting a 34-character name.

From PuTTY 0.63 onwards, this can be worked around with the "Chokes on PuTTY's SSH-2 'winadj' requests" bug-compatibility mode. However, it's not currently automatically detected.

If anyone who runs into this has some channel to contact Allegro (a support contract or other clout), it would be helpful to point this out to them (we have no means of getting in contact). If the bug is fixed at source and the complete set of affected SSH version strings provided to us, we can automatically enable the workaround in PuTTY when appropriate (although from the patterns below, this doesn't look likely to be sensible).

Reported with the following servers / devices:


If you want to comment on this web site, see the Feedback page.
Audit trail for this artifact.
(last revision of this bug record was at 2022-09-11 23:46:37 +0100)