dum de dum

[Bill Sommerfeld <sommerfeld%sun.com@localhost>]

Approved: eat-my-bits
Return-Path: <owner-ietf-ssh%netbsd.org@localhost>
X-Original-To: ietf-ssh%netbsd.org@localhost
Delivered-To: ietf-ssh%netbsd.org@localhost
Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7])
	by mail.netbsd.org (Postfix) with ESMTP id B3C4B63B147
	for <ietf-ssh%netbsd.org@localhost>; Fri, 21 Oct 2005 04:50:40 +0000 (UTC)
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA26839;
	Fri, 21 Oct 2005 00:50:39 -0400 (EDT)
From: der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>
Message-Id: <200510210450.AAA26839%Sparkle.Rodents.Montreal.QC.CA@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the zombie armies.
Date: Fri, 21 Oct 2005 00:26:29 -0400 (EDT)
To: ietf-ssh%netbsd.org@localhost
Subject: Who's at fault here?

I'm seeing some logged gripes when using my client to connect to
another implementation, and I think it's not my fault - but I want to
check before treating this as someone else's bug.

Specifically, here is what I'm seeing (logged on the cleartext side of
the encryption etc layer):

(394) In data (1):
(395)    0   34                                                4
(396) Out data (24):
(397)    0   5a 00 00 00 07 73 65 73  73 69 6f 6e 00 00 00 00  Z?session?
(398)   10   00 00 00 00 00 00 88 b8                           ??
(399) In data (17):
(400)    0   5b 00 00 00 00 00 00 00  00 00 00 00 00 00 00 80  [???
(401)   10   00                                                
(402) Out data (9):
(403)    0   5d 00 00 00 00 00 01 00  00                       ]??

As I read it:

- The first packet (server to me) is a USERAUTH_SUCCESS.

- The second (me to server) is a CHANNEL_OPEN, requesting a "session"
   channel, my number 0, initial window 0, max packet size 35000.

- The third (server to me) is a CHANNEL_OPEN_CONFIRMATION, both channel
   numbers 0, initial window 0, max packet size 32768.

- The fourth (me to server) is a CHANNEL_WINDOW_ADJUST, adding 65536
   bytes of window to this new channel.

The thing is, the implementation I'm talking to (which is bannering as
"SSH-1.99-OpenSSH_3.4 NetBSD_Secure_Shell-20020626") is logging
"Received window adjust for non-open channel 0." in response to this.
I've done enough experiments watching the logs for my end in one window
and the other end in the other to convince me that there is a direct
causal relationship between behaviour such as this from the client and
such messages being logged by the server.

But before I file a NetBSD problem report on this, I wanted to get
another pair of eyes confirming that the above trace does indeed look
perfectly reasonable and is not an example of what the server-logged
message seems to think it is.

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