RFC 4254, "The Secure Shell (SSH) Connection Protocol", January 2006

Note: This RFC has been updated by RFC 8308

Errata ID: 3878
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2014-02-02
Verifier Name: Stephen Farrell
Date Verified: 2015-05-12

Section 5.2 says:

   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller.  The window size is decremented by the amount of data
   sent.  Both parties MAY ignore all extra data sent after the allowed
   window is empty.

It should say:

   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller.  The window size is decremented by the length of the data
   sent, length field included.  Both parties MAY ignore all extra data
   sent after the allowed window is empty.

Notes:

This is the data transfer packet:

byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data

Since string's are defined by RFC4251 as being "stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string" it's unclear weather or not the uint32 length field contributes to the total or not. In my interoperability testing it seems that it does but it doesn't seem that this is all that clear from this RFC.

It is also unclear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size or not. A strict interpretation would suggest it does not since the RFC makes no mention of it.

Report New Errata