Mail Archives: cygwin/2005/08/17/19:22:43
On Wednesday, August 17, 2005 3:58 AM, Corinna Vinschen wrote:
> On Aug 16 16:50, Dave Kilzer wrote:
> > On Tue, Aug 16, 2005 at 09:55:58PM +0200, Corinna Vinschen wrote:
> > > BUT
> > >
> > > it will print annoying messages to the console, containing a text
as
> > > "res and ret = 0, nonblocking = 1".
> >
> > Actually, I never saw any of this output while using ssh.
>
> ...this isn't. Are you really sure? If my fix is really helping, you
> should really have seen this message. Did you, by any chance, use
your
> patched ssh version, accidentally? It would explain that ssh worked
> but the message hasn't been printed. Can you check again?
I checked twice again today that using the new-cygwin1.dll you provided
does NOT output any annoying messages to console (and works), but that
going back to the cygwin1-1.5.18-1.dll does NOT work. I also made sure
I was using ssh.exe from /usr/bin. Here's the md5sum and the version
string output:
$ md5sum `which ssh`.exe
81759ac33194fb1aa03e5731d06455df */usr/bin/ssh.exe
$ ssh -V
OpenSSH_4.1p1, OpenSSL 0.9.8 05 Jul 2005
Furthermore, I discovered today that using new-cygwin1.dll only works
when using OpenSSH in non-verbose mode ("ssh hostname"). When I try
using OpenSSH in verbose mode ("ssh -v hostname") with new-cygwin1.dll,
it fails with a new error message "Bad packet length 0" (real hostname
replaced with "hostname"; real IP address replaced with "1.2.3.4"; real
home directory replaced with "~"):
$ ssh -v hostname
OpenSSH_4.1p1, OpenSSL 0.9.8 05 Jul 2005
debug1: Connecting to hostname [1.2.3.4] port 22.
debug1: Connection established.
debug1: identity file ~/.ssh/identity type -1
debug1: identity file ~/.ssh/id_rsa type 1
debug1: identity file ~/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Received disconnect from 1.2.3.4: 2: Bad packet length 0.
Again, NONE of the testing above was done with my locally
patched/locally compiled version of OpenSSH.
--
To provide a different perspective, I went back to my old desktop PC
that is running cygwin-1.5.13-1 (cygwin1.dll dated 2005-Mar-01), then
tried various cygwin1.dll releases from 1.5.15 through 1.5.18, two
current snapshot releases, and new-cygwin1.dll to try to pinpoint where
the failure first started to occur. Here are the md5sum and version
info for OpenSSH on this PC (as distributed with Cygwin at the time):
$ md5sum `which ssh`.exe
7fe273419467243345643c263cfa4509 */usr/bin/ssh.exe
$ ssh -V
OpenSSH_3.9p1, OpenSSL 0.9.7f 22 Mar 2005
I ran both "ssh hostname" and "ssh -v hostname" to a single host, and
checked the version of cygwin1.dll via "cygcheck -s" to make sure I was
using the correct copy.
cygwin1.dll Vers Results of "ssh hostname" and "ssh -v hostname"
----------------
-------------------------------------------------
1.5.13-1 Both ssh commands worked
1.5.15-1 Both ssh commands worked
1.5.16-1 Both ssh commands worked
1.5.17-1 Both ssh commands worked
1.5.18-1 NEITHER ssh command worked (BOTH "Write
failed:")
2005-Jul-28-snap NEITHER ssh command worked (BOTH "Write
failed:")
2005-Aug-14-snap NEITHER ssh command worked (BOTH "Write
failed:")
new-cygwin1.dll Both ssh commands worked (*)
(*) I still did NOT see any annoying console output here.
Looking at these results, a change between 1.5.17-1 and 1.5.18-1 looks
like it may be the culprit. Does this jibe with the changes you made
for new-cygwin1.dll?
--
Between the annoying console output not appearing and the fact that one
of the original ways I was able to fix this issue was to compile
OpenSSH-4.1p1-2 with the "-DPACKET_DEBUG=1" cflag WITH NO CHANGES to
packet.c (please reread my original message; the second way I fixed it
was with a change to packet.c without that cflag), this problem smells a
lot like a compiler bug.
Did Cygwin switch from gcc-3.3.x to gcc-3.4.x between 1.5.17-1 and
1.5.18-1?
Dave
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -