RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

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

Source of RFC: secsh (sec)

Errata ID: 3878

Status: Verified
Type: Editorial

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.

Status: Held for Document Update (1)

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

Source of RFC: secsh (sec)

Errata ID: 3877

Status: Held for Document Update
Type: Editorial

Reported By: Jim Wigginton
Date Reported: 2014-02-02
Held for Document Update by: Kathleen Moriarty
Date Held: 2014-07-01

Section 6.10 says:

6.10.  Returning Exit Status

   When the command running at the other end terminates, the following
   message can be sent to return the exit status of the command.
   Returning the status is RECOMMENDED.  No acknowledgement is sent for
   this message.  The channel needs to be closed with
   SSH_MSG_CHANNEL_CLOSE after this message.

   The client MAY ignore these messages.

It should say:

6.10.  Returning Exit Status

   When the command running at the other end terminates, the following
   message can be sent to return the exit status of the command.
   Returning the status is RECOMMENDED.  No acknowledgement is sent for
   this message.  The channel needs to be closed by the server with
   SSH_MSG_CHANNEL_CLOSE after this message.

   The client MAY ignore these messages.

Notes:

Even though it can arguably be inferred from the text as written I think it'd make it more clear if the RFC explicitly said that the server is the one that should be sending the SSH_MSG_CHANNEL_CLOSE message.

Report New Errata



Search RFCs
Advanced Search
×