[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers] Re: lsh dying
From: |
Niels Möller |
Subject: |
[Savannah-hackers] Re: lsh dying |
Date: |
11 Sep 2001 13:39:35 +0200 |
Loic Dachary <address@hidden> writes:
> Sep 10 10:24:19 subversions lshd[31748]: io.c: accept on fd 4
> Sep 10 10:24:19 subversions lshd[31748]: Accepting connection from
> 195.149.37.160, port 42154
> Sep 10 10:24:19 subversions lshd[31748]: Initiating handshake with
> 195.149.37.160
> Sep 10 10:24:19 subversions lshd[31748]: io.c: Preparing fd 4 for reading and
> writing
> Sep 10 10:24:19 subversions lshd[31748]: Client version: SSH-2.0-lsh_1.1.5
> lsh - a free ssh Server version: SSH-1.99-lshd_1.2.1 lsh - a free ssh
> Sep 10 10:24:19 subversions lshd[31748]: Selected keyexchange algorithm:
> diffie-hellman-group1-sha1 with hostkey algorithm: ssh-dss
> Sep 10 10:24:19 subversions lshd[31748]: Selected bulk algorithms: (client to
> server, server to client) Encryption: (3des-cbc, 3des-cbc)
> Message authentication: (hmac-sha1, hmac-sha1) Compression:
> (none, none)
> Sep 10 10:24:19 subversions lshd[31748]: handle_dh_init
> Sep 10 10:24:19 subversions lshd[31748]: do_dsa_sign: Signing according to
> ssh-dss
Thanks for the info. Does it happen randomly, or is there any pattern?
One hypothesis is that the dsa_blob_write crashes in some unusual
case, e.g. if r and s are of different size.
Could you try dumping out the values of r and s in dsa signatures?
If you change a few debug() calls to trace(), you will get the info
with --trace, without enabling full packet dumps with --debug.
--- src/dsa.c 2001/06/11 23:06:03 1.28
+++ src/dsa.c 2001/09/11 11:35:16
@@ -435,7 +435,7 @@
mpz_fdiv_r(r, r, self->verifier->q);
- debug("generic_dsa_sign, r: %xn\n", r);
+ trace("generic_dsa_sign, r: %xn\n", r);
/* Compute hash */
dsa_hash(tmp, length, msg);
@@ -453,7 +453,7 @@
mpz_mul(s, s, k);
mpz_fdiv_r(s, s, self->verifier->q);
- debug("generic_dsa_sign, s: %xn\n", s);
+ trace("generic_dsa_sign, s: %xn\n", s);
mpz_clear(k);
mpz_clear(tmp);
And of course, a core dump from a crash would also be helpful.
/Niels