Subject: ssh channel window size: before or after compression?

From: "denis bider" <[email-masked]>
Date: Fri, 14 Feb 2003 00:04:30 +0100

Hello everyone,

there is a noble and widespread SSH2/SFTP implementation on the market
which happens to work quite nicely with servers such as OpenSSH, but
miraculously fails with our own server whenever it attempts to upload a
large, highly compressible file. The error that occurs is that the
client sends more data to the channel than allowed for by the window
size, which our implementation considers a gross violation of SSH2 flow
control, and therefore disconnects the offender without undue
hesitation.

After looking at the latest secsh-connect document, my theory is that
the Offending Application (tm) interprets channel window size to apply
to data AFTER rather than before compression. So it joyfully sends a 10k
compressed chunk of data thinking all is nice and dandy, but when on the
other end after decompression this balloons into 100k, our server frowns
and says no-no.

Now, given that SSH2 compression is defined in secsh-transport, whereas
channels and windows are all higher level structures defined in
secsh-connect, it appears very reasonable to assume that channel window
size applies to data that is sent INTO a channel, i.e. BEFORE
compression, rather than to packetized compressed data as it comes out
of the transport layer. However, this is nowhere explicitly stated in
secsh-connect, and apparently this is also not how a few other
implementations, including but not limited to Offending Application,
understand things to be. Otherwise, the Offending Application should
have a problem uploading that file not only to our server, but also e.g.
to OpenSSH - yet with OpenSSH it works just fine.

So, my question to the folks here gathered is: who is right? Should
channel window size be applied to data as it is being sent into a
channel, BEFORE compression (yay!), or should it be applied to data as
it comes out compressed from the SSH2 transport layer (yuck!)?

Further, assuming window size applies BEFORE compression, why don't
servers other than ours bounce the Offending Application as it
vehemently attempts to send more than it is supposed to?

I very much look forward to your enlightened replies.

Best regards,

denis

---

From: Jon Bright <[email-masked]>
Date: 14 Feb 2003 08:43:19 +0100

Hi,

Since the channels layer can't possibly know if/what kind of compression
the transport layer's using, my opinion would be that the only possible
way to interpret it is that window sizes refer to uncompressed data. 
Also, all packets are compressed, whereas window sizes refer only to
channel data.

> So, my question to the folks here gathered is: who is right? Should

...so my view on this would be that you are.

> vehemently attempts to send more than it is supposed to?

One possibility is that you're using a portable OpenSSH v3.1(?) or so on
Linux with the privsep stuff, where compression isn't supported, thereby
obviating the problem.  Check whether compression's actually negotiated
for your test connection...

-- 
Jon Bright
Lead Programmer, Silicon Circus Ltd.
http://www.siliconcircus.com/