Hi all,

I'm facing a certain strange issue when using putty client with a
proxy application that we develop. Our proxy works by setting up two
ssh connections on either side of it. So for example, if someone from
host A is trying to connect to host B, there will be two connections
made A->P and P->B (omitting the details of how the proxy inserts
itself into the path as they are irrelevant to the issue). The
existence of the two segments is transparent to A and B. The window
sizes and max packet sizes being negotiated on A->P segment are
duplicated on the P->B segment. When the P->B segment connection is
established -i.e when the shell channel request succeeds-, usually the
server sends back a window adjust which is relayed onto to A.
Ok, now onto the problem when the client is putty:
under normal circumstances, everything seems to be fine with the
shell, but if you ever send back large amount of CHANNEL_DATA from B
to A, the putty client never sends a window adjust and so the output
seems to hang after sometime as the server waits for the window to be
incremented. So doing a "cat" on a large text file for example will
"hang" the session after a few pages.

It seems there was a putty bug similar to this (putty ssh-window-
adjust) but apparently its been fixed so I don't know why putty
doesn't send back the window adjust unless its stuck in some loop
still processing the data. Other clients like the openssh client do
send back the window adjust and so are fine.

Any hints/feedback would be appreciated. I can send traces privately
if anyone wants to look at them. Tried putty version .58 onwards.

Thanks in advance!

On Wed, 01 Aug 2007 21:11:35 +0000, wet_undies wrote:

> Hi all,
>
> I'm facing a certain strange issue when using putty client with a proxy
> application that we develop. Our proxy works by setting up two ssh
> connections on either side of it. So for example, if someone from host A
> is trying to connect to host B, there will be two connections made A->P
> and P->B (omitting the details of how the proxy inserts itself into the
> path as they are irrelevant to the issue). The existence of the two
> segments is transparent to A and B. The window sizes and max packet
> sizes being negotiated on A->P segment are duplicated on the P->B
> segment. When the P->B segment connection is established -i.e when the
> shell channel request succeeds-, usually the server sends back a window
> adjust which is relayed onto to A. Ok, now onto the problem when the
> client is putty: under normal circumstances, everything seems to be fine
> with the shell, but if you ever send back large amount of CHANNEL_DATA
> from B to A, the putty client never sends a window adjust and so the
> output seems to hang after sometime as the server waits for the window
> to be incremented. So doing a "cat" on a large text file for example
> will "hang" the session after a few pages.
>
> It seems there was a putty bug similar to this (putty ssh-window-
> adjust) but apparently its been fixed so I don't know why putty doesn't
> send back the window adjust unless its stuck in some loop still
> processing the data. Other clients like the openssh client do send back
> the window adjust and so are fine.
>
> Any hints/feedback would be appreciated. I can send traces privately if
> anyone wants to look at them. Tried putty version .58 onwards.

Having undertaken something similar recently, my approach was to
make sure to exhaust the window space available every time, by sending as
many packets as necessary. This always elicits the necessary window
adjust packet from putty.

In article <1186002695.882346.224220@d55g2000hsg.googlegroups .com>,
wet_undies <hom.tanks@gmail.com> wrote:
>Ok, now onto the problem when the client is putty:
>under normal circumstances, everything seems to be fine with the
>shell, but if you ever send back large amount of CHANNEL_DATA from B
>to A, the putty client never sends a window adjust and so the output
>seems to hang after sometime as the server waits for the window to be
>incremented. So doing a "cat" on a large text file for example will
>"hang" the session after a few pages.
....
>Any hints/feedback would be appreciated. I can send traces privately
>if anyone wants to look at them. Tried putty version .58 onwards.

<putty@projects.tartarus.org> would certainly be interested. Improving
our window handling is something I'd like to work on, but enev now it
shouldn't be so bad that PuTTY stops sending WINDOW_ADJUST entirely.

--
Ben Harris

Hmmm, I was able to make the problem go away (so far) by manipulating
the window size on the server side connection to be half of that on
the client. The following shows what window size and max packet size
settings work as of now. Effectively, it makes the server think the
window is half of what putty has agreed to and so sends half as much
data in a packet. I didn't try out other settings to see at what point
it starts becoming a problem but just wanted to post the findings to
see if anyone might have some insight into this behaviour.

K.Jennings: it seems we get proper behaviour when we do opposite of
exhausting the window space. Again, too early to draw conclusion but
just an observation.
Ben: Thanks for replying! Have sent you the putty log of the original
issue.


Details:
=========
A: Putty 0.60
B: OpenSsh 4.2
P: Proxy

A->P:

SSH_MSG_CHANNEL_OPEN:- chnType:session initialWindow:16384
maxPacketSize:16384
SSH_MSG_CHANNEL_OPEN_CONFIRMATION:- chnType:session initialWindow:
16384 maxPacketSize:16384

P->B:
SSH_MSG_CHANNEL_OPEN:- chnType:session initialWindow:8192
maxPacketSize:8192
SSH_MSG_CHANNEL_OPEN_CONFIRMATION:- chnType:session initialWindow:0
maxPacketSize:32768

followed by

B->P
SSH_MSG_WINDOW_ADJUST
bytesToAdd: 8192
which is forwarded to client A
P->A
SSH_MSG_WINDOW_ADJUST
bytesToAdd: 8192


On Aug 2, 10:14 am, Ben Harris <bjhar...@chiark.greenend.org.uk>
wrote:
> In article <1186002695.882346.224...@d55g2000hsg.googlegroups .com>,
>
> wet_undies <hom.ta...@gmail.com> wrote:
> >Ok, now onto the problem when the client isputty:
> >under normal circumstances, everything seems to be fine with the
> >shell, but if you ever send back large amount of CHANNEL_DATA from B
> >to A, theputtyclient never sends awindowadjustand so the output
> >seems to hang after sometime as the server waits for thewindowto be
> >incremented. So doing a "cat" on a large text file for example will
> >"hang" the session after a few pages.
> ...
> >Any hints/feedback would be appreciated. I can send traces privately
> >if anyone wants to look at them. Triedputtyversion .58 onwards.
>
> <pu...@projects.tartarus.org> would certainly be interested. Improving
> ourwindowhandling is something I'd like to work on, but enev now it
> shouldn't be so bad thatPuTTYstops sending WINDOW_ADJUST entirely.
>
> --
> Ben Harris

In article <+1s*XMhRr@news.chiark.greenend.org.uk>,
Ben Harris <bjharris@chiark.greenend.org.uk> wrote:
>In article <1186002695.882346.224220@d55g2000hsg.googlegroups .com>,
>wet_undies <hom.tanks@gmail.com> wrote:
>>Ok, now onto the problem when the client is putty:
>>under normal circumstances, everything seems to be fine with the
>>shell, but if you ever send back large amount of CHANNEL_DATA from B
>>to A, the putty client never sends a window adjust and so the output
>>seems to hang after sometime as the server waits for the window to be
>>incremented. So doing a "cat" on a large text file for example will
>>"hang" the session after a few pages.
>...
>>Any hints/feedback would be appreciated. I can send traces privately
>>if anyone wants to look at them. Tried putty version .58 onwards.
>
><putty@projects.tartarus.org> would certainly be interested.

For those who might be interested, the problem turned out to be that the
proxy was sending more data than PuTTY's window permitted, which caused
an integer underflow in PuTTY such that it thought the server had a
_huge_ window available, so it didn't need to send any more
WINDOW_ADJUSTs. While this is obviously a bug in the proxy, it seemed
silly for PuTTY to respond like this, so it now copes more gracefully
with over-enthusiastic servers.

--
Ben Harris

In article <+1s*XMhRr@news.chiark.greenend.org.uk>,
Ben Harris <bjharris@chiark.greenend.org.uk> wrote:
>In article <1186002695.882346.224220@d55g2000hsg.googlegroups .com>,
>wet_undies <hom.tanks@gmail.com> wrote:
>>Ok, now onto the problem when the client is putty:
>>under normal circumstances, everything seems to be fine with the
>>shell, but if you ever send back large amount of CHANNEL_DATA from B
>>to A, the putty client never sends a window adjust and so the output
>>seems to hang after sometime as the server waits for the window to be
>>incremented. So doing a "cat" on a large text file for example will
>>"hang" the session after a few pages.
>...
>>Any hints/feedback would be appreciated. I can send traces privately
>>if anyone wants to look at them. Tried putty version .58 onwards.
>
><putty@projects.tartarus.org> would certainly be interested.

For those who might be interested, the problem turned out to be that the
proxy was sending more data than PuTTY's window permitted, which caused
an integer underflow in PuTTY such that it thought the server had a
_huge_ window available, so it didn't need to send any more
WINDOW_ADJUSTs. While this is obviously a bug in the proxy, it seemed
silly for PuTTY to respond like this, so it now copes more gracefully
with over-enthusiastic servers.

--
Ben Harris