Re: maximum size of packets from client to server

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> One thing I would like to see clarified here but haven't seen
>> mentioned is what level the max packet size applies at.
> I actually mentioned that in my third email as something else I'd
> like to see clarification on.

Sorry, I must have missed your mention.  Since people are quoting the
comments from their code, here's the relevant comment from mine:

/*
 * This value is what we put in the "maximum packet size" field of
 *  CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages we generate.
 *  This is documented as
 *	The 'maximum packet size' specifies the maximum size of an
 *	individual data packet that can be sent to the sender.
 *  There is disagreement over exactly what this means.  It seems to me
 *  that this means "the maximum size of a CHANNEL_DATA or
 *  CHANNEL_EXTENDED_DATA message", but at least two other
 *  implementations take it to mean "the maximum size of a CHANNEL_DATA
 *  or CHANNEL_EXTENDED_DATA data payload".  When I put
 *  SSH_MAX_PAYLOAD_LEN in here, I would relatively routinely get
 *  crashes in which the remote end overran my specified maximum size
 *  by 9 bytes (ie, the difference between the size of a CHANNEL_DATA
 *  packet and the size of its data payload).  While I still think my
 *  reading is right, the wording is now frozen (and thus won't change
 *  even if it turns out I'm right) and other implementations aren't
 *  going to change their deployed base overnight even if they agree
 *  with me today.  So we allow some slop.  It's tempting to produce
 *  nag messages if we detect a peer treating this value as a max data
 *  _payload_ size instead of a max data _packet_ size, in an attempt
 *  to get people to fix their other implementations, but for now I'm
 *  holding off on that; I'm going to try to get this nailed down on
 *  the WG list first.
 *
 * We take the opposite interpretation when handling maxsend values
 *  from incoming CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages,
 *  taking them as maximum data packet size rather than maximum data
 *  payload size.  This is not because we're twisted (though that might
 *  be a defensible position :), but because we're conservative; doing
 *  this causes us to use a lower value, making it harder to overrun
 *  other implementations.  (Besides, it's what the spec specifies. :)
 *  (Actually, we do this only if the max-packet value is >13;
 *  otherwise, when we subtract 13, the result would be zero or
 *  negative.  Anyone specifying a value that small *must* be treating
 *  it as a max payload size rather than a max total packet size - or
 *  severely buggy, I suppose.)
 *
 * 13 is the difference between a CHANNEL_EXTENDED_DATA packet size and
 *  its data payload size.  This is the largest overhead we have to
 *  deal with; for CHANNEL_DATA packets, the overhead is only 9, but
 *  there's only one value, so we have to deduct for the largest packet
 *  overhead.
 */
#define MAX_PACKET_SIZE_VALUE (SSH_MAX_PAYLOAD_LEN-13)

I think the data payload size is probably what the author of that part
of the spec had in mind, but it's not what the language actually says.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B