From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 01:38:36 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q210cB5b002980; Thu, 1 Mar 2012 01:38:33 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q210c9wP002964 for ; Thu, 1 Mar 2012 01:38:09 +0100 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1TNjHP9023797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Feb 2012 18:45:20 -0500 Received: from beast.broked.org ([10.3.112.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1TNjGOq021306; Wed, 29 Feb 2012 18:45:17 -0500 Message-ID: <4F4EB832.9050000@redhat.com> Date: Wed, 29 Feb 2012 16:43:46 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: =?UTF-8?B?SGVucmlrIE5vcmRzdHLDtm0=?= Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> In-Reply-To: <1330424506.1025.13.camel@home.hno.se> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q210cB5b002980 On 02/28/2012 03:21 AM, Henrik Nordström wrote: > mÃ¥n 2012-02-27 klockan 20:58 -0700 skrev Steven Dake: >> 11.4. Reserved Messages >> >> An implementation MUST respond to all unrecognized messages with an >> SSH_MSG_UNIMPLEMENTED message in the order in which the messages were >> received. Such messages MUST be otherwise ignored. Later protocol >> versions may define other meanings for these message types. >> >> byte SSH_MSG_UNIMPLEMENTED >> uint32 packet sequence number of rejected message >> >> >> + case SSH_MSG_UNIMPLEMENTED: >> + LIBSSH2_FREE(session, data); >> + session->packAdd_state = libssh2_NB_state_idle; >> + return 0; >> + > > Err.. it's an error and needs to be dealt with. If not then the > application will not know that the request failed. > > Regards > Henrik > Possible but at the moment the error isn't captured by any API resulting in a packet leak when this happens. I am not quite sure how to return an error code in this condition, so not certain how to propose such a patch. Regards -steve _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 02:10:51 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q211AfbP022960; Thu, 1 Mar 2012 02:10:50 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q211AcCn022952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Mar 2012 02:10:38 +0100 Received: from home.hno.se (home.hno.se [IPv6:2001:470:df90::1]) (authenticated bits=128) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q210CbmN001362; Thu, 1 Mar 2012 00:12:38 GMT Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by home.hno.se (8.14.5/8.14.5) with ESMTP id q210CaoF017582; Thu, 1 Mar 2012 01:12:36 +0100 Message-ID: <1330560756.24673.161.camel@home.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: Steven Dake Date: Thu, 01 Mar 2012 01:12:36 +0100 In-Reply-To: <4F4EB832.9050000@redhat.com> References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on home.hno.se X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Thu, 01 Mar 2012 00:12:39 +0000 (UTC) Cc: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se ons 2012-02-29 klockan 16:43 -0700 skrev Steven Dake: > Possible but at the moment the error isn't captured by any API resulting > in a packet leak when this happens. It should already get picked up via _libssh2_packet_requirev by the one who sent the failing request. > I am not quite sure how to return an error code in this condition, so > not certain how to propose such a patch. Do you have any evidence of SSH_MSG_UNIMPLEMENTED piling up? If so, in response to what kind of requests? This is not the same case as keepalive with want_reply set. The keep-alive problem is libssh2_keepalive_send never trying to read the response to the request it sent. It's state machine needs to be extended to also read the reponse if want_reply is set. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 04:42:55 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q213gUuL028643; Thu, 1 Mar 2012 04:42:51 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q213gT3d028601 for ; Thu, 1 Mar 2012 04:42:29 +0100 Received: (qmail 14152 invoked by uid 501); 1 Mar 2012 03:42:27 -0000 Message-ID: <20120301034227.14151.qmail@stuge.se> Date: Thu, 1 Mar 2012 04:42:27 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Callback for channel data ready Mail-Followup-To: libssh2-devel@cool.haxx.se References: <20120229080800.13736.qmail@stuge.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hi Mitchell, Mitchell Hashimoto wrote: > > > but I was hoping perhaps there was a better way? > > > > Sorry not at this time. I think we want callbacks though, so feel > > free to discuss and send patches. :) > > Understood. Thanks. > > I haven't been using libssh2 long enough to feel comfortable enough > in suggesting API improvements, since I haven't quite immersed > myself in the "libssh2 way." There is no such thing.. libssh2 has evolved, and must continue to evolve. The libssh2 API can and should be expanded to become more useful, and the definition of useful should basically come from it's users. > But I agree that callbacks would be fantastic. So how would that work? //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 17:57:33 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21Gv47n014008; Thu, 1 Mar 2012 17:57:27 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21Gv1a8013876 for ; Thu, 1 Mar 2012 17:57:02 +0100 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q21GuwTn014587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 11:56:58 -0500 Received: from beast.broked.org ([10.3.112.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q21Guvcx018812; Thu, 1 Mar 2012 11:56:57 -0500 Message-ID: <4F4FA9FF.9040008@redhat.com> Date: Thu, 01 Mar 2012 09:55:27 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: =?UTF-8?B?SGVucmlrIE5vcmRzdHLDtm0=?= Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> In-Reply-To: <1330560756.24673.161.camel@home.hno.se> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q21Gv47n014008 On 02/29/2012 05:12 PM, Henrik Nordström wrote: > ons 2012-02-29 klockan 16:43 -0700 skrev Steven Dake: > >> Possible but at the moment the error isn't captured by any API resulting >> in a packet leak when this happens. > > It should already get picked up via _libssh2_packet_requirev by the one > who sent the failing request. > >> I am not quite sure how to return an error code in this condition, so >> not certain how to propose such a patch. > > Do you have any evidence of SSH_MSG_UNIMPLEMENTED piling up? If so, in > response to what kind of requests? > Not piling up. There appears to be 1 or 2 extra on the session when I close it. This was verified with the diagnostic patch I posted recently which prints packets on the session during session close. I was getting 1 or 2 3's and thousands of 82s in a 12 hour run. The 82s were in response to the keep alive, not sure what triggered the 3s. the 3's remain after i turned off want_reply in my keepalive send operations. Regards -steve > This is not the same case as keepalive with want_reply set. The > keep-alive problem is libssh2_keepalive_send never trying to read the > response to the request it sent. It's state machine needs to be extended > to also read the reponse if want_reply is set. > > Regards > Henrik > _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 18:07:22 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21H7IIr021481; Thu, 1 Mar 2012 18:07:21 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q21H7Ggm021466 for ; Thu, 1 Mar 2012 18:07:16 +0100 Received: (qmail 24926 invoked by uid 501); 1 Mar 2012 17:07:17 -0000 Message-ID: <20120301170717.24925.qmail@stuge.se> Date: Thu, 1 Mar 2012 18:07:17 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F4FA9FF.9040008@redhat.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Steven Dake wrote: > I was getting 1 or 2 3's and thousands of 82s in a 12 hour run. The 82s > were in response to the keep alive, not sure what triggered the 3s. So run with full tracing enabled and stop when you see a 3 packet. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 20:08:25 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21J88t8010102; Thu, 1 Mar 2012 20:08:22 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21J86VX010062 for ; Thu, 1 Mar 2012 20:08:07 +0100 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q21J7p1B015184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Mar 2012 14:08:03 -0500 Received: from beast.broked.org ([10.3.112.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q21IW0FO007792 for ; Thu, 1 Mar 2012 13:32:01 -0500 Message-ID: <4F4FC046.6050004@redhat.com> Date: Thu, 01 Mar 2012 11:30:30 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> In-Reply-To: <20120301170717.24925.qmail@stuge.se> Content-Type: multipart/mixed; boundary="------------090105020407080504030702" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se This is a multi-part message in MIME format. --------------090105020407080504030702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/01/2012 10:07 AM, Peter Stuge wrote: > Steven Dake wrote: >> I was getting 1 or 2 3's and thousands of 82s in a 12 hour run. The 82s >> were in response to the keep alive, not sure what triggered the 3s. > > So run with full tracing enabled and stop when you see a 3 packet. > > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel typescript attached --------------090105020407080504030702 Content-Type: application/octet-stream; name="typescript" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="typescript" U2NyaXB0IHN0YXJ0ZWQgb24gVGh1IDAxIE1hciAyMDEyIDExOjI4OjI3IEFNIE1TVAobXTA7 c2Rha2VAYmVhc3Q6L2hvbWUvc2Rha2UvcmVwb3MvcGFjZW1ha2VyLWNsb3VkL3NyYwcbWz8x MDM0aFtyb290QGJlYXN0IHNyY10jIC4vY2FwZS1zc2hkIGRlcC13cA0KTWFyIDAxIDExOjI4 OjM4IFs2MTgyXSBiZWFzdC5icm9rZWQub3JnICAgIHVua25vd246IE1BSU4gICAgIGluZm86 IGluc3RhbmNlX3N0YXRlX2RldGVjdDogCUluc3RhbmNlICdhc3N5LXdvcmRwcmVzcy1GMTYn IHdpdGggYWRkcmVzcyAnMTAuMC4wLjInIGNoYW5nZWQgdG8gUlVOTklORyBpbiAoNjU3MCBt cykuDQpNYXIgMDEgMTE6Mjg6MzggWzYxODJdIGJlYXN0LmJyb2tlZC5vcmcgICAgdW5rbm93 bjogTUFJTiAgIG5vdGljZTogdHJhbnNwb3J0X2Nvbm5lY3Q6IAlDb25uZWN0aW9uIGluIHBy b2dyZXNzIHRvIGFzc2VtYmx5ICdhc3N5LXdvcmRwcmVzcy1GMTYnDQpNYXIgMDEgMTE6Mjg6 NDAgWzYxODJdIGJlYXN0LmJyb2tlZC5vcmcgICAgdW5rbm93bjogTUFJTiAgICAgaW5mbzog aW5zdGFuY2Vfc3RhdGVfZGV0ZWN0OiAJSW5zdGFuY2UgJ2Fzc3ktd29yZHByZXNzLW15c3Fs LUYxNicgd2l0aCBhZGRyZXNzICcxMC4wLjAuMycgY2hhbmdlZCB0byBSVU5OSU5HIGluICg3 MDQ3IG1zKS4NCk1hciAwMSAxMToyODo0MCBbNjE4Ml0gYmVhc3QuYnJva2VkLm9yZyAgICB1 bmtub3duOiBNQUlOICAgbm90aWNlOiB0cmFuc3BvcnRfY29ubmVjdDogCUNvbm5lY3Rpb24g aW4gcHJvZ3Jlc3MgdG8gYXNzZW1ibHkgJ2Fzc3ktd29yZHByZXNzLW15c3FsLUYxNicNCk1h ciAwMSAxMToyODo1OCBbNjE4Ml0gYmVhc3QuYnJva2VkLm9yZyAgICB1bmtub3duOiBNQUlO ICAgbm90aWNlOiBjb25uZWN0X2V4ZWN1dGU6IAlDb25uZWN0ZWQgdG8gYXNzZW1ibHkgJ2Fz c3ktd29yZHByZXNzLW15c3FsLUYxNicNCltsaWJzc2gyXSAwLjYwOTgxMSBDb25uOiBTZXR0 aW5nIGJsb2NraW5nIG1vZGUgT0ZGDQpbbGlic3NoMl0gMC42MDk4NDYgVHJhbnNwb3J0OiBz ZXNzaW9uX3N0YXJ0dXAgZm9yIHNvY2tldCA5DQpbbGlic3NoMl0gMC42MDk4NTYgVHJhbnNw b3J0OiBTZW5kaW5nIEJhbm5lcjogU1NILTIuMC1saWJzc2gyXzEuNC4wDQpbbGlic3NoMl0g MC42MDk5MDAgU29ja2V0OiBTZW50IDIzLzIzIGJ5dGVzIGF0IDB4N2ZkNDUxMzRiMmVkKzAN CltsaWJzc2gyXSAwLjYwOTkxMSBTb2NrZXQ6IFJlY3ZlZCAxIGJ5dGVzIGJhbm5lcg0KW2xp YnNzaDJdIDAuNjA5OTE3IFNvY2tldDogUmVjdmVkIDEgYnl0ZXMgYmFubmVyDQpbbGlic3No Ml0gMC42MDk5MjYgU29ja2V0OiBSZWN2ZWQgMSBieXRlcyBiYW5uZXINCltsaWJzc2gyXSAw LjYwOTkzMSBTb2NrZXQ6IFJlY3ZlZCAxIGJ5dGVzIGJhbm5lcg0KW2xpYnNzaDJdIDAuNjA5 OTM3IFNvY2tldDogUmVjdmVkIDEgYnl0ZXMgYmFubmVyDQpbbGlic3NoMl0gMC42MDk5NDIg U29ja2V0OiBSZWN2ZWQgMSBieXRlcyBiYW5uZXINCltsaWJzc2gyXSAwLjYwOTk0NyBTb2Nr ZXQ6IFJlY3ZlZCAxIGJ5dGVzIGJhbm5lcg0KW2xpYnNzaDJdIDAuNjA5OTY5IFNvY2tldDog UmVjdmVkIDEgYnl0ZXMgYmFubmVyDQpbbGlic3NoMl0gMC42MDk5OTIgU29ja2V0OiBSZWN2 ZWQgMSBieXRlcyBiYW5uZXINCltsaWJzc2gyXSAwLjYwOTk5NiBTb2NrZXQ6IFJlY3ZlZCAx IGJ5dGVzIGJhbm5lcg0KW2xpYnNzaDJdIDAuNjEwMDAwIFNvY2tldDogUmVjdmVkIDEgYnl0 ZXMgYmFubmVyDQpbbGlic3NoMl0gMC42MTAwMDMgU29ja2V0OiBSZWN2ZWQgMSBieXRlcyBi YW5uZXINCltsaWJzc2gyXSAwLjYxMDAyMiBTb2NrZXQ6IFJlY3ZlZCAxIGJ5dGVzIGJhbm5l cg0KW2xpYnNzaDJdIDAuNjEwMDI2IFNvY2tldDogUmVjdmVkIDEgYnl0ZXMgYmFubmVyDQpb bGlic3NoMl0gMC42MTAwMzYgU29ja2V0OiBSZWN2ZWQgMSBieXRlcyBiYW5uZXINCltsaWJz c2gyXSAwLjYxMDA0MyBTb2NrZXQ6IFJlY3ZlZCAxIGJ5dGVzIGJhbm5lcg0KW2xpYnNzaDJd IDAuNjEwMDQ4IFNvY2tldDogUmVjdmVkIDEgYnl0ZXMgYmFubmVyDQpbbGlic3NoMl0gMC42 MTAwNTMgU29ja2V0OiBSZWN2ZWQgMSBieXRlcyBiYW5uZXINCltsaWJzc2gyXSAwLjYxMDA1 OCBTb2NrZXQ6IFJlY3ZlZCAxIGJ5dGVzIGJhbm5lcg0KW2xpYnNzaDJdIDAuNjEwMDY1IFNv Y2tldDogUmVjdmVkIDEgYnl0ZXMgYmFubmVyDQpbbGlic3NoMl0gMC42MTAwNzIgU29ja2V0 OiBSZWN2ZWQgMSBieXRlcyBiYW5uZXINCltsaWJzc2gyXSAwLjYxMDA3OCBUcmFuc3BvcnQ6 IFJlY2VpdmVkIEJhbm5lcjogU1NILTIuMC1PcGVuU1NIXzUuOA0KW2xpYnNzaDJdIDAuNjEw MzIwIEtleSBFeDogU2VudCBLRVg6IGRpZmZpZS1oZWxsbWFuLWdyb3VwMTQtc2hhMSxkaWZm aWUtaGVsbG1hbi1ncm91cC1leGNoYW5nZS1zaGExLGRpZmZpZS1oZWxsbWFuLWdyb3VwMS1z aGExDQpbbGlic3NoMl0gMC42MTAzMjggS2V5IEV4OiBTZW50IEhPU1RLRVk6IHNzaC1yc2Es c3NoLWRzcw0KW2xpYnNzaDJdIDAuNjEwMzMxIEtleSBFeDogU2VudCBDUllQVF9DUzogYWVz MTI4LWN0cixhZXMxOTItY3RyLGFlczI1Ni1jdHIsYWVzMjU2LWNiYyxyaWpuZGFlbC1jYmNA bHlzYXRvci5saXUuc2UsYWVzMTkyLWNiYyxhZXMxMjgtY2JjLGJsb3dmaXNoLWNiYyxhcmNm b3VyMTI4LGFyY2ZvdXIsY2FzdDEyOC1jYmMsM2Rlcy1jYmMNCltsaWJzc2gyXSAwLjYxMDMz NSBLZXkgRXg6IFNlbnQgQ1JZUFRfU0M6IGFlczEyOC1jdHIsYWVzMTkyLWN0cixhZXMyNTYt Y3RyLGFlczI1Ni1jYmMscmlqbmRhZWwtY2JjQGx5c2F0b3IubGl1LnNlLGFlczE5Mi1jYmMs YWVzMTI4LWNiYyxibG93ZmlzaC1jYmMsYXJjZm91cjEyOCxhcmNmb3VyLGNhc3QxMjgtY2Jj LDNkZXMtY2JjDQpbbGlic3NoMl0gMC42MTAzMzkgS2V5IEV4OiBTZW50IE1BQ19DUzogaG1h Yy1zaGExLGhtYWMtc2hhMS05NixobWFjLW1kNSxobWFjLW1kNS05NixobWFjLXJpcGVtZDE2 MCxobWFjLXJpcGVtZDE2MEBvcGVuc3NoLmNvbQ0KW2xpYnNzaDJdIDAuNjEwMzQzIEtleSBF eDogU2VudCBNQUNfU0M6IGhtYWMtc2hhMSxobWFjLXNoYTEtOTYsaG1hYy1tZDUsaG1hYy1t ZDUtOTYsaG1hYy1yaXBlbWQxNjAsaG1hYy1yaXBlbWQxNjBAb3BlbnNzaC5jb20NCltsaWJz c2gyXSAwLjYxMDM0NiBLZXkgRXg6IFNlbnQgQ09NUF9DUzogbm9uZQ0KW2xpYnNzaDJdIDAu NjEwMzQ5IEtleSBFeDogU2VudCBDT01QX1NDOiBub25lDQpbbGlic3NoMl0gMC42MTAzNTEg S2V5IEV4OiBTZW50IExBTkdfQ1M6IA0KW2xpYnNzaDJdIDAuNjEwMzU0IEtleSBFeDogU2Vu dCBMQU5HX1NDOiANCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3dyaXRlIHBsYWluICg2MzYgYnl0 ZXMpDQowMDAwOiAxNCAxOSAzMiA2MCAxNSBDQSBBNCBDMSAgMEEgOTIgQTkgQkQgMEQgODUg RkIgMUMgOiAuLjJgLi4uLi4uLi4uLi4uDQowMDEwOiA1MSAwMCAwMCAwMCA1OSA2NCA2OSA2 NiAgNjYgNjkgNjUgMkQgNjggNjUgNkMgNkMgOiBRLi4uWWRpZmZpZS1oZWxsDQowMDIwOiA2 RCA2MSA2RSAyRCA2NyA3MiA2RiA3NSAgNzAgMzEgMzQgMkQgNzMgNjggNjEgMzEgOiBtYW4t Z3JvdXAxNC1zaGExDQowMDMwOiAyQyA2NCA2OSA2NiA2NiA2OSA2NSAyRCAgNjggNjUgNkMg NkMgNkQgNjEgNkUgMkQgOiAsZGlmZmllLWhlbGxtYW4tDQowMDQwOiA2NyA3MiA2RiA3NSA3 MCAyRCA2NSA3OCAgNjMgNjggNjEgNkUgNjcgNjUgMkQgNzMgOiBncm91cC1leGNoYW5nZS1z DQowMDUwOiA2OCA2MSAzMSAyQyA2NCA2OSA2NiA2NiAgNjkgNjUgMkQgNjggNjUgNkMgNkMg NkQgOiBoYTEsZGlmZmllLWhlbGxtDQowMDYwOiA2MSA2RSAyRCA2NyA3MiA2RiA3NSA3MCAg MzEgMkQgNzMgNjggNjEgMzEgMDAgMDAgOiBhbi1ncm91cDEtc2hhMS4uDQowMDcwOiAwMCAw RiA3MyA3MyA2OCAyRCA3MiA3MyAgNjEgMkMgNzMgNzMgNjggMkQgNjQgNzMgOiAuLnNzaC1y c2Esc3NoLWRzDQowMDgwOiA3MyAwMCAwMCAwMCA5MiA2MSA2NSA3MyAgMzEgMzIgMzggMkQg NjMgNzQgNzIgMkMgOiBzLi4uLmFlczEyOC1jdHIsDQowMDkwOiA2MSA2NSA3MyAzMSAzOSAz MiAyRCA2MyAgNzQgNzIgMkMgNjEgNjUgNzMgMzIgMzUgOiBhZXMxOTItY3RyLGFlczI1DQow MGEwOiAzNiAyRCA2MyA3NCA3MiAyQyA2MSA2NSAgNzMgMzIgMzUgMzYgMkQgNjMgNjIgNjMg OiA2LWN0cixhZXMyNTYtY2JjDQowMGIwOiAyQyA3MiA2OSA2QSA2RSA2NCA2MSA2NSAgNkMg MkQgNjMgNjIgNjMgNDAgNkMgNzkgOiAscmlqbmRhZWwtY2JjQGx5DQowMGMwOiA3MyA2MSA3 NCA2RiA3MiAyRSA2QyA2OSAgNzUgMkUgNzMgNjUgMkMgNjEgNjUgNzMgOiBzYXRvci5saXUu c2UsYWVzDQowMGQwOiAzMSAzOSAzMiAyRCA2MyA2MiA2MyAyQyAgNjEgNjUgNzMgMzEgMzIg MzggMkQgNjMgOiAxOTItY2JjLGFlczEyOC1jDQowMGUwOiA2MiA2MyAyQyA2MiA2QyA2RiA3 NyA2NiAgNjkgNzMgNjggMkQgNjMgNjIgNjMgMkMgOiBiYyxibG93ZmlzaC1jYmMsDQowMGYw OiA2MSA3MiA2MyA2NiA2RiA3NSA3MiAzMSAgMzIgMzggMkMgNjEgNzIgNjMgNjYgNkYgOiBh cmNmb3VyMTI4LGFyY2ZvDQowMTAwOiA3NSA3MiAyQyA2MyA2MSA3MyA3NCAzMSAgMzIgMzgg MkQgNjMgNjIgNjMgMkMgMzMgOiB1cixjYXN0MTI4LWNiYywzDQowMTEwOiA2NCA2NSA3MyAy RCA2MyA2MiA2MyAwMCAgMDAgMDAgOTIgNjEgNjUgNzMgMzEgMzIgOiBkZXMtY2JjLi4uLmFl czEyDQowMTIwOiAzOCAyRCA2MyA3NCA3MiAyQyA2MSA2NSAgNzMgMzEgMzkgMzIgMkQgNjMg NzQgNzIgOiA4LWN0cixhZXMxOTItY3RyDQowMTMwOiAyQyA2MSA2NSA3MyAzMiAzNSAzNiAy RCAgNjMgNzQgNzIgMkMgNjEgNjUgNzMgMzIgOiAsYWVzMjU2LWN0cixhZXMyDQowMTQwOiAz NSAzNiAyRCA2MyA2MiA2MyAyQyA3MiAgNjkgNkEgNkUgNjQgNjEgNjUgNkMgMkQgOiA1Ni1j YmMscmlqbmRhZWwtDQowMTUwOiA2MyA2MiA2MyA0MCA2QyA3OSA3MyA2MSAgNzQgNkYgNzIg MkUgNkMgNjkgNzUgMkUgOiBjYmNAbHlzYXRvci5saXUuDQowMTYwOiA3MyA2NSAyQyA2MSA2 NSA3MyAzMSAzOSAgMzIgMkQgNjMgNjIgNjMgMkMgNjEgNjUgOiBzZSxhZXMxOTItY2JjLGFl DQowMTcwOiA3MyAzMSAzMiAzOCAyRCA2MyA2MiA2MyAgMkMgNjIgNkMgNkYgNzcgNjYgNjkg NzMgOiBzMTI4LWNiYyxibG93ZmlzDQowMTgwOiA2OCAyRCA2MyA2MiA2MyAyQyA2MSA3MiAg NjMgNjYgNkYgNzUgNzIgMzEgMzIgMzggOiBoLWNiYyxhcmNmb3VyMTI4DQowMTkwOiAyQyA2 MSA3MiA2MyA2NiA2RiA3NSA3MiAgMkMgNjMgNjEgNzMgNzQgMzEgMzIgMzggOiAsYXJjZm91 cixjYXN0MTI4DQowMWEwOiAyRCA2MyA2MiA2MyAyQyAzMyA2NCA2NSAgNzMgMkQgNjMgNjIg NjMgMDAgMDAgMDAgOiAtY2JjLDNkZXMtY2JjLi4uDQowMWIwOiA1NSA2OCA2RCA2MSA2MyAy RCA3MyA2OCAgNjEgMzEgMkMgNjggNkQgNjEgNjMgMkQgOiBVaG1hYy1zaGExLGhtYWMtDQow MWMwOiA3MyA2OCA2MSAzMSAyRCAzOSAzNiAyQyAgNjggNkQgNjEgNjMgMkQgNkQgNjQgMzUg OiBzaGExLTk2LGhtYWMtbWQ1DQowMWQwOiAyQyA2OCA2RCA2MSA2MyAyRCA2RCA2NCAgMzUg MkQgMzkgMzYgMkMgNjggNkQgNjEgOiAsaG1hYy1tZDUtOTYsaG1hDQowMWUwOiA2MyAyRCA3 MiA2OSA3MCA2NSA2RCA2NCAgMzEgMzYgMzAgMkMgNjggNkQgNjEgNjMgOiBjLXJpcGVtZDE2 MCxobWFjDQowMWYwOiAyRCA3MiA2OSA3MCA2NSA2RCA2NCAzMSAgMzYgMzAgNDAgNkYgNzAg NjUgNkUgNzMgOiAtcmlwZW1kMTYwQG9wZW5zDQowMjAwOiA3MyA2OCAyRSA2MyA2RiA2RCAw MCAwMCAgMDAgNTUgNjggNkQgNjEgNjMgMkQgNzMgOiBzaC5jb20uLi5VaG1hYy1zDQowMjEw OiA2OCA2MSAzMSAyQyA2OCA2RCA2MSA2MyAgMkQgNzMgNjggNjEgMzEgMkQgMzkgMzYgOiBo YTEsaG1hYy1zaGExLTk2DQowMjIwOiAyQyA2OCA2RCA2MSA2MyAyRCA2RCA2NCAgMzUgMkMg NjggNkQgNjEgNjMgMkQgNkQgOiAsaG1hYy1tZDUsaG1hYy1tDQowMjMwOiA2NCAzNSAyRCAz OSAzNiAyQyA2OCA2RCAgNjEgNjMgMkQgNzIgNjkgNzAgNjUgNkQgOiBkNS05NixobWFjLXJp cGVtDQowMjQwOiA2NCAzMSAzNiAzMCAyQyA2OCA2RCA2MSAgNjMgMkQgNzIgNjkgNzAgNjUg NkQgNjQgOiBkMTYwLGhtYWMtcmlwZW1kDQowMjUwOiAzMSAzNiAzMCA0MCA2RiA3MCA2NSA2 RSAgNzMgNzMgNjggMkUgNjMgNkYgNkQgMDAgOiAxNjBAb3BlbnNzaC5jb20uDQowMjYwOiAw MCAwMCAwNCA2RSA2RiA2RSA2NSAwMCAgMDAgMDAgMDQgNkUgNkYgNkUgNjUgMDAgOiAuLi5u b25lLi4uLm5vbmUuDQowMjcwOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgMDAgMDAgMDAg MDAgICAgICAgICAgICAgOiAuLi4uLi4uLi4uLi4NCltsaWJzc2gyXSAwLjYxMDUyNiBTb2Nr ZXQ6IFNlbnQgNjQ4LzY0OCBieXRlcyBhdCAweDljMDEyOA0KPT4gbGlic3NoMl90cmFuc3Bv cnRfd3JpdGUgc2VuZCgpICg2NDggYnl0ZXMpDQowMDAwOiAwMCAwMCAwMiA4NCAwNyAxNCAx OSAzMiAgNjAgMTUgQ0EgQTQgQzEgMEEgOTIgQTkgOiAuLi4uLi4uMmAuLi4uLi4uDQowMDEw OiBCRCAwRCA4NSBGQiAxQyA1MSAwMCAwMCAgMDAgNTkgNjQgNjkgNjYgNjYgNjkgNjUgOiAu Li4uLlEuLi5ZZGlmZmllDQowMDIwOiAyRCA2OCA2NSA2QyA2QyA2RCA2MSA2RSAgMkQgNjcg NzIgNkYgNzUgNzAgMzEgMzQgOiAtaGVsbG1hbi1ncm91cDE0DQowMDMwOiAyRCA3MyA2OCA2 MSAzMSAyQyA2NCA2OSAgNjYgNjYgNjkgNjUgMkQgNjggNjUgNkMgOiAtc2hhMSxkaWZmaWUt aGVsDQowMDQwOiA2QyA2RCA2MSA2RSAyRCA2NyA3MiA2RiAgNzUgNzAgMkQgNjUgNzggNjMg NjggNjEgOiBsbWFuLWdyb3VwLWV4Y2hhDQowMDUwOiA2RSA2NyA2NSAyRCA3MyA2OCA2MSAz MSAgMkMgNjQgNjkgNjYgNjYgNjkgNjUgMkQgOiBuZ2Utc2hhMSxkaWZmaWUtDQowMDYwOiA2 OCA2NSA2QyA2QyA2RCA2MSA2RSAyRCAgNjcgNzIgNkYgNzUgNzAgMzEgMkQgNzMgOiBoZWxs bWFuLWdyb3VwMS1zDQowMDcwOiA2OCA2MSAzMSAwMCAwMCAwMCAwRiA3MyAgNzMgNjggMkQg NzIgNzMgNjEgMkMgNzMgOiBoYTEuLi4uc3NoLXJzYSxzDQowMDgwOiA3MyA2OCAyRCA2NCA3 MyA3MyAwMCAwMCAgMDAgOTIgNjEgNjUgNzMgMzEgMzIgMzggOiBzaC1kc3MuLi4uYWVzMTI4 DQowMDkwOiAyRCA2MyA3NCA3MiAyQyA2MSA2NSA3MyAgMzEgMzkgMzIgMkQgNjMgNzQgNzIg MkMgOiAtY3RyLGFlczE5Mi1jdHIsDQowMGEwOiA2MSA2NSA3MyAzMiAzNSAzNiAyRCA2MyAg NzQgNzIgMkMgNjEgNjUgNzMgMzIgMzUgOiBhZXMyNTYtY3RyLGFlczI1DQowMGIwOiAzNiAy RCA2MyA2MiA2MyAyQyA3MiA2OSAgNkEgNkUgNjQgNjEgNjUgNkMgMkQgNjMgOiA2LWNiYyxy aWpuZGFlbC1jDQowMGMwOiA2MiA2MyA0MCA2QyA3OSA3MyA2MSA3NCAgNkYgNzIgMkUgNkMg NjkgNzUgMkUgNzMgOiBiY0BseXNhdG9yLmxpdS5zDQowMGQwOiA2NSAyQyA2MSA2NSA3MyAz MSAzOSAzMiAgMkQgNjMgNjIgNjMgMkMgNjEgNjUgNzMgOiBlLGFlczE5Mi1jYmMsYWVzDQow MGUwOiAzMSAzMiAzOCAyRCA2MyA2MiA2MyAyQyAgNjIgNkMgNkYgNzcgNjYgNjkgNzMgNjgg OiAxMjgtY2JjLGJsb3dmaXNoDQowMGYwOiAyRCA2MyA2MiA2MyAyQyA2MSA3MiA2MyAgNjYg NkYgNzUgNzIgMzEgMzIgMzggMkMgOiAtY2JjLGFyY2ZvdXIxMjgsDQowMTAwOiA2MSA3MiA2 MyA2NiA2RiA3NSA3MiAyQyAgNjMgNjEgNzMgNzQgMzEgMzIgMzggMkQgOiBhcmNmb3VyLGNh c3QxMjgtDQowMTEwOiA2MyA2MiA2MyAyQyAzMyA2NCA2NSA3MyAgMkQgNjMgNjIgNjMgMDAg MDAgMDAgOTIgOiBjYmMsM2Rlcy1jYmMuLi4uDQowMTIwOiA2MSA2NSA3MyAzMSAzMiAzOCAy RCA2MyAgNzQgNzIgMkMgNjEgNjUgNzMgMzEgMzkgOiBhZXMxMjgtY3RyLGFlczE5DQowMTMw OiAzMiAyRCA2MyA3NCA3MiAyQyA2MSA2NSAgNzMgMzIgMzUgMzYgMkQgNjMgNzQgNzIgOiAy LWN0cixhZXMyNTYtY3RyDQowMTQwOiAyQyA2MSA2NSA3MyAzMiAzNSAzNiAyRCAgNjMgNjIg NjMgMkMgNzIgNjkgNkEgNkUgOiAsYWVzMjU2LWNiYyxyaWpuDQowMTUwOiA2NCA2MSA2NSA2 QyAyRCA2MyA2MiA2MyAgNDAgNkMgNzkgNzMgNjEgNzQgNkYgNzIgOiBkYWVsLWNiY0BseXNh dG9yDQowMTYwOiAyRSA2QyA2OSA3NSAyRSA3MyA2NSAyQyAgNjEgNjUgNzMgMzEgMzkgMzIg MkQgNjMgOiAubGl1LnNlLGFlczE5Mi1jDQowMTcwOiA2MiA2MyAyQyA2MSA2NSA3MyAzMSAz MiAgMzggMkQgNjMgNjIgNjMgMkMgNjIgNkMgOiBiYyxhZXMxMjgtY2JjLGJsDQowMTgwOiA2 RiA3NyA2NiA2OSA3MyA2OCAyRCA2MyAgNjIgNjMgMkMgNjEgNzIgNjMgNjYgNkYgOiBvd2Zp c2gtY2JjLGFyY2ZvDQowMTkwOiA3NSA3MiAzMSAzMiAzOCAyQyA2MSA3MiAgNjMgNjYgNkYg NzUgNzIgMkMgNjMgNjEgOiB1cjEyOCxhcmNmb3VyLGNhDQowMWEwOiA3MyA3NCAzMSAzMiAz OCAyRCA2MyA2MiAgNjMgMkMgMzMgNjQgNjUgNzMgMkQgNjMgOiBzdDEyOC1jYmMsM2Rlcy1j DQowMWIwOiA2MiA2MyAwMCAwMCAwMCA1NSA2OCA2RCAgNjEgNjMgMkQgNzMgNjggNjEgMzEg MkMgOiBiYy4uLlVobWFjLXNoYTEsDQowMWMwOiA2OCA2RCA2MSA2MyAyRCA3MyA2OCA2MSAg MzEgMkQgMzkgMzYgMkMgNjggNkQgNjEgOiBobWFjLXNoYTEtOTYsaG1hDQowMWQwOiA2MyAy RCA2RCA2NCAzNSAyQyA2OCA2RCAgNjEgNjMgMkQgNkQgNjQgMzUgMkQgMzkgOiBjLW1kNSxo bWFjLW1kNS05DQowMWUwOiAzNiAyQyA2OCA2RCA2MSA2MyAyRCA3MiAgNjkgNzAgNjUgNkQg NjQgMzEgMzYgMzAgOiA2LGhtYWMtcmlwZW1kMTYwDQowMWYwOiAyQyA2OCA2RCA2MSA2MyAy RCA3MiA2OSAgNzAgNjUgNkQgNjQgMzEgMzYgMzAgNDAgOiAsaG1hYy1yaXBlbWQxNjBADQow MjAwOiA2RiA3MCA2NSA2RSA3MyA3MyA2OCAyRSAgNjMgNkYgNkQgMDAgMDAgMDAgNTUgNjgg OiBvcGVuc3NoLmNvbS4uLlVoDQowMjEwOiA2RCA2MSA2MyAyRCA3MyA2OCA2MSAzMSAgMkMg NjggNkQgNjEgNjMgMkQgNzMgNjggOiBtYWMtc2hhMSxobWFjLXNoDQowMjIwOiA2MSAzMSAy RCAzOSAzNiAyQyA2OCA2RCAgNjEgNjMgMkQgNkQgNjQgMzUgMkMgNjggOiBhMS05NixobWFj LW1kNSxoDQowMjMwOiA2RCA2MSA2MyAyRCA2RCA2NCAzNSAyRCAgMzkgMzYgMkMgNjggNkQg NjEgNjMgMkQgOiBtYWMtbWQ1LTk2LGhtYWMtDQowMjQwOiA3MiA2OSA3MCA2NSA2RCA2NCAz MSAzNiAgMzAgMkMgNjggNkQgNjEgNjMgMkQgNzIgOiByaXBlbWQxNjAsaG1hYy1yDQowMjUw OiA2OSA3MCA2NSA2RCA2NCAzMSAzNiAzMCAgNDAgNkYgNzAgNjUgNkUgNzMgNzMgNjggOiBp cGVtZDE2MEBvcGVuc3NoDQowMjYwOiAyRSA2MyA2RiA2RCAwMCAwMCAwMCAwNCAgNkUgNkYg NkUgNjUgMDAgMDAgMDAgMDQgOiAuY29tLi4uLm5vbmUuLi4uDQowMjcwOiA2RSA2RiA2RSA2 NSAwMCAwMCAwMCAwMCAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgOiBub25lLi4uLi4uLi4u Li4uDQowMjgwOiAwMCA1MiA5NCAzRSA0MCBBQSA0MiBDNCAgICAgICAgICAgICAgICAgICAg ICAgICAgOiAuUi4+QC5CLg0KW2xpYnNzaDJdIDAuNjEwNjg0IFRyYW5zcG9ydDogTG9va2lu ZyBmb3IgcGFja2V0IG9mIHR5cGU6IDIwDQpbbGlic3NoMl0gMC42NjA3OTUgU29ja2V0OiBS ZWN2ZWQgNzg0LzE2Mzg0IGJ5dGVzIHRvIDB4OWJjMGU4KzANCj0+IGxpYnNzaDJfdHJhbnNw b3J0X3JlYWQoKSByYXcgKDc4NCBieXRlcykNCjAwMDA6IDAwIDAwIDAzIDBDIDBBIDE0IDE3 IDgwICAwNiBDNiA5OCA2RiBBNCA4RiA0QyBGNCA6IC4uLi4uLi4uLi4uby4uTC4NCjAwMTA6 IEE2IDcwIDA3IEFCIDNCIDAxIDAwIDAwICAwMCA3RSA2NCA2OSA2NiA2NiA2OSA2NSA6IC5w Li47Li4uLn5kaWZmaWUNCjAwMjA6IDJEIDY4IDY1IDZDIDZDIDZEIDYxIDZFICAyRCA2NyA3 MiA2RiA3NSA3MCAyRCA2NSA6IC1oZWxsbWFuLWdyb3VwLWUNCjAwMzA6IDc4IDYzIDY4IDYx IDZFIDY3IDY1IDJEICA3MyA2OCA2MSAzMiAzNSAzNiAyQyA2NCA6IHhjaGFuZ2Utc2hhMjU2 LGQNCjAwNDA6IDY5IDY2IDY2IDY5IDY1IDJEIDY4IDY1ICA2QyA2QyA2RCA2MSA2RSAyRCA2 NyA3MiA6IGlmZmllLWhlbGxtYW4tZ3INCjAwNTA6IDZGIDc1IDcwIDJEIDY1IDc4IDYzIDY4 ICA2MSA2RSA2NyA2NSAyRCA3MyA2OCA2MSA6IG91cC1leGNoYW5nZS1zaGENCjAwNjA6IDMx IDJDIDY0IDY5IDY2IDY2IDY5IDY1ICAyRCA2OCA2NSA2QyA2QyA2RCA2MSA2RSA6IDEsZGlm ZmllLWhlbGxtYW4NCjAwNzA6IDJEIDY3IDcyIDZGIDc1IDcwIDMxIDM0ICAyRCA3MyA2OCA2 MSAzMSAyQyA2NCA2OSA6IC1ncm91cDE0LXNoYTEsZGkNCjAwODA6IDY2IDY2IDY5IDY1IDJE IDY4IDY1IDZDICA2QyA2RCA2MSA2RSAyRCA2NyA3MiA2RiA6IGZmaWUtaGVsbG1hbi1ncm8N CjAwOTA6IDc1IDcwIDMxIDJEIDczIDY4IDYxIDMxICAwMCAwMCAwMCAwRiA3MyA3MyA2OCAy RCA6IHVwMS1zaGExLi4uLnNzaC0NCjAwYTA6IDcyIDczIDYxIDJDIDczIDczIDY4IDJEICA2 NCA3MyA3MyAwMCAwMCAwMCA5RCA2MSA6IHJzYSxzc2gtZHNzLi4uLmENCjAwYjA6IDY1IDcz IDMxIDMyIDM4IDJEIDYzIDc0ICA3MiAyQyA2MSA2NSA3MyAzMSAzOSAzMiA6IGVzMTI4LWN0 cixhZXMxOTINCjAwYzA6IDJEIDYzIDc0IDcyIDJDIDYxIDY1IDczICAzMiAzNSAzNiAyRCA2 MyA3NCA3MiAyQyA6IC1jdHIsYWVzMjU2LWN0ciwNCjAwZDA6IDYxIDcyIDYzIDY2IDZGIDc1 IDcyIDMyICAzNSAzNiAyQyA2MSA3MiA2MyA2NiA2RiA6IGFyY2ZvdXIyNTYsYXJjZm8NCjAw ZTA6IDc1IDcyIDMxIDMyIDM4IDJDIDYxIDY1ICA3MyAzMSAzMiAzOCAyRCA2MyA2MiA2MyA6 IHVyMTI4LGFlczEyOC1jYmMNCjAwZjA6IDJDIDMzIDY0IDY1IDczIDJEIDYzIDYyICA2MyAy QyA2MiA2QyA2RiA3NyA2NiA2OSA6ICwzZGVzLWNiYyxibG93ZmkNCjAxMDA6IDczIDY4IDJE IDYzIDYyIDYzIDJDIDYzICA2MSA3MyA3NCAzMSAzMiAzOCAyRCA2MyA6IHNoLWNiYyxjYXN0 MTI4LWMNCjAxMTA6IDYyIDYzIDJDIDYxIDY1IDczIDMxIDM5ICAzMiAyRCA2MyA2MiA2MyAy QyA2MSA2NSA6IGJjLGFlczE5Mi1jYmMsYWUNCjAxMjA6IDczIDMyIDM1IDM2IDJEIDYzIDYy IDYzICAyQyA2MSA3MiA2MyA2NiA2RiA3NSA3MiA6IHMyNTYtY2JjLGFyY2ZvdXINCjAxMzA6 IDJDIDcyIDY5IDZBIDZFIDY0IDYxIDY1ICA2QyAyRCA2MyA2MiA2MyA0MCA2QyA3OSA6ICxy aWpuZGFlbC1jYmNAbHkNCjAxNDA6IDczIDYxIDc0IDZGIDcyIDJFIDZDIDY5ICA3NSAyRSA3 MyA2NSAwMCAwMCAwMCA5RCA6IHNhdG9yLmxpdS5zZS4uLi4NCjAxNTA6IDYxIDY1IDczIDMx IDMyIDM4IDJEIDYzICA3NCA3MiAyQyA2MSA2NSA3MyAzMSAzOSA6IGFlczEyOC1jdHIsYWVz MTkNCjAxNjA6IDMyIDJEIDYzIDc0IDcyIDJDIDYxIDY1ICA3MyAzMiAzNSAzNiAyRCA2MyA3 NCA3MiA6IDItY3RyLGFlczI1Ni1jdHINCjAxNzA6IDJDIDYxIDcyIDYzIDY2IDZGIDc1IDcy ICAzMiAzNSAzNiAyQyA2MSA3MiA2MyA2NiA6ICxhcmNmb3VyMjU2LGFyY2YNCjAxODA6IDZG IDc1IDcyIDMxIDMyIDM4IDJDIDYxICA2NSA3MyAzMSAzMiAzOCAyRCA2MyA2MiA6IG91cjEy OCxhZXMxMjgtY2INCjAxOTA6IDYzIDJDIDMzIDY0IDY1IDczIDJEIDYzICA2MiA2MyAyQyA2 MiA2QyA2RiA3NyA2NiA6IGMsM2Rlcy1jYmMsYmxvd2YNCjAxYTA6IDY5IDczIDY4IDJEIDYz IDYyIDYzIDJDICA2MyA2MSA3MyA3NCAzMSAzMiAzOCAyRCA6IGlzaC1jYmMsY2FzdDEyOC0N CjAxYjA6IDYzIDYyIDYzIDJDIDYxIDY1IDczIDMxICAzOSAzMiAyRCA2MyA2MiA2MyAyQyA2 MSA6IGNiYyxhZXMxOTItY2JjLGENCjAxYzA6IDY1IDczIDMyIDM1IDM2IDJEIDYzIDYyICA2 MyAyQyA2MSA3MiA2MyA2NiA2RiA3NSA6IGVzMjU2LWNiYyxhcmNmb3UNCjAxZDA6IDcyIDJD IDcyIDY5IDZBIDZFIDY0IDYxICA2NSA2QyAyRCA2MyA2MiA2MyA0MCA2QyA6IHIscmlqbmRh ZWwtY2JjQGwNCjAxZTA6IDc5IDczIDYxIDc0IDZGIDcyIDJFIDZDICA2OSA3NSAyRSA3MyA2 NSAwMCAwMCAwMCA6IHlzYXRvci5saXUuc2UuLi4NCjAxZjA6IDY5IDY4IDZEIDYxIDYzIDJE IDZEIDY0ICAzNSAyQyA2OCA2RCA2MSA2MyAyRCA3MyA6IGlobWFjLW1kNSxobWFjLXMNCjAy MDA6IDY4IDYxIDMxIDJDIDc1IDZEIDYxIDYzICAyRCAzNiAzNCA0MCA2RiA3MCA2NSA2RSA6 IGhhMSx1bWFjLTY0QG9wZW4NCjAyMTA6IDczIDczIDY4IDJFIDYzIDZGIDZEIDJDICA2OCA2 RCA2MSA2MyAyRCA3MiA2OSA3MCA6IHNzaC5jb20saG1hYy1yaXANCjAyMjA6IDY1IDZEIDY0 IDMxIDM2IDMwIDJDIDY4ICA2RCA2MSA2MyAyRCA3MiA2OSA3MCA2NSA6IGVtZDE2MCxobWFj LXJpcGUNCjAyMzA6IDZEIDY0IDMxIDM2IDMwIDQwIDZGIDcwICA2NSA2RSA3MyA3MyA2OCAy RSA2MyA2RiA6IG1kMTYwQG9wZW5zc2guY28NCjAyNDA6IDZEIDJDIDY4IDZEIDYxIDYzIDJE IDczICA2OCA2MSAzMSAyRCAzOSAzNiAyQyA2OCA6IG0saG1hYy1zaGExLTk2LGgNCjAyNTA6 IDZEIDYxIDYzIDJEIDZEIDY0IDM1IDJEICAzOSAzNiAwMCAwMCAwMCA2OSA2OCA2RCA6IG1h Yy1tZDUtOTYuLi5paG0NCjAyNjA6IDYxIDYzIDJEIDZEIDY0IDM1IDJDIDY4ICA2RCA2MSA2 MyAyRCA3MyA2OCA2MSAzMSA6IGFjLW1kNSxobWFjLXNoYTENCjAyNzA6IDJDIDc1IDZEIDYx IDYzIDJEIDM2IDM0ICA0MCA2RiA3MCA2NSA2RSA3MyA3MyA2OCA6ICx1bWFjLTY0QG9wZW5z c2gNCjAyODA6IDJFIDYzIDZGIDZEIDJDIDY4IDZEIDYxICA2MyAyRCA3MiA2OSA3MCA2NSA2 RCA2NCA6IC5jb20saG1hYy1yaXBlbWQNCjAyOTA6IDMxIDM2IDMwIDJDIDY4IDZEIDYxIDYz ICAyRCA3MiA2OSA3MCA2NSA2RCA2NCAzMSA6IDE2MCxobWFjLXJpcGVtZDENCjAyYTA6IDM2 IDMwIDQwIDZGIDcwIDY1IDZFIDczICA3MyA2OCAyRSA2MyA2RiA2RCAyQyA2OCA6IDYwQG9w ZW5zc2guY29tLGgNCjAyYjA6IDZEIDYxIDYzIDJEIDczIDY4IDYxIDMxICAyRCAzOSAzNiAy QyA2OCA2RCA2MSA2MyA6IG1hYy1zaGExLTk2LGhtYWMNCjAyYzA6IDJEIDZEIDY0IDM1IDJE IDM5IDM2IDAwICAwMCAwMCAxNSA2RSA2RiA2RSA2NSAyQyA6IC1tZDUtOTYuLi4ubm9uZSwN CjAyZDA6IDdBIDZDIDY5IDYyIDQwIDZGIDcwIDY1ICA2RSA3MyA3MyA2OCAyRSA2MyA2RiA2 RCA6IHpsaWJAb3BlbnNzaC5jb20NCjAyZTA6IDAwIDAwIDAwIDE1IDZFIDZGIDZFIDY1ICAy QyA3QSA2QyA2OSA2MiA0MCA2RiA3MCA6IC4uLi5ub25lLHpsaWJAb3ANCjAyZjA6IDY1IDZF IDczIDczIDY4IDJFIDYzIDZGICA2RCAwMCAwMCAwMCAwMCAwMCAwMCAwMCA6IGVuc3NoLmNv bS4uLi4uLi4NCjAzMDA6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCA6IC4uLi4uLi4uLi4uLi4uLi4NCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3Jl YWQoKSBwbGFpbiAoNzY5IGJ5dGVzKQ0KMDAwMDogMTQgMTcgODAgMDYgQzYgOTggNkYgQTQg IDhGIDRDIEY0IEE2IDcwIDA3IEFCIDNCIDogLi4uLi4uby4uTC4ucC4uOw0KMDAxMDogMDEg MDAgMDAgMDAgN0UgNjQgNjkgNjYgIDY2IDY5IDY1IDJEIDY4IDY1IDZDIDZDIDogLi4uLn5k aWZmaWUtaGVsbA0KMDAyMDogNkQgNjEgNkUgMkQgNjcgNzIgNkYgNzUgIDcwIDJEIDY1IDc4 IDYzIDY4IDYxIDZFIDogbWFuLWdyb3VwLWV4Y2hhbg0KMDAzMDogNjcgNjUgMkQgNzMgNjgg NjEgMzIgMzUgIDM2IDJDIDY0IDY5IDY2IDY2IDY5IDY1IDogZ2Utc2hhMjU2LGRpZmZpZQ0K MDA0MDogMkQgNjggNjUgNkMgNkMgNkQgNjEgNkUgIDJEIDY3IDcyIDZGIDc1IDcwIDJEIDY1 IDogLWhlbGxtYW4tZ3JvdXAtZQ0KMDA1MDogNzggNjMgNjggNjEgNkUgNjcgNjUgMkQgIDcz IDY4IDYxIDMxIDJDIDY0IDY5IDY2IDogeGNoYW5nZS1zaGExLGRpZg0KMDA2MDogNjYgNjkg NjUgMkQgNjggNjUgNkMgNkMgIDZEIDYxIDZFIDJEIDY3IDcyIDZGIDc1IDogZmllLWhlbGxt YW4tZ3JvdQ0KMDA3MDogNzAgMzEgMzQgMkQgNzMgNjggNjEgMzEgIDJDIDY0IDY5IDY2IDY2 IDY5IDY1IDJEIDogcDE0LXNoYTEsZGlmZmllLQ0KMDA4MDogNjggNjUgNkMgNkMgNkQgNjEg NkUgMkQgIDY3IDcyIDZGIDc1IDcwIDMxIDJEIDczIDogaGVsbG1hbi1ncm91cDEtcw0KMDA5 MDogNjggNjEgMzEgMDAgMDAgMDAgMEYgNzMgIDczIDY4IDJEIDcyIDczIDYxIDJDIDczIDog aGExLi4uLnNzaC1yc2Escw0KMDBhMDogNzMgNjggMkQgNjQgNzMgNzMgMDAgMDAgIDAwIDlE IDYxIDY1IDczIDMxIDMyIDM4IDogc2gtZHNzLi4uLmFlczEyOA0KMDBiMDogMkQgNjMgNzQg NzIgMkMgNjEgNjUgNzMgIDMxIDM5IDMyIDJEIDYzIDc0IDcyIDJDIDogLWN0cixhZXMxOTIt Y3RyLA0KMDBjMDogNjEgNjUgNzMgMzIgMzUgMzYgMkQgNjMgIDc0IDcyIDJDIDYxIDcyIDYz IDY2IDZGIDogYWVzMjU2LWN0cixhcmNmbw0KMDBkMDogNzUgNzIgMzIgMzUgMzYgMkMgNjEg NzIgIDYzIDY2IDZGIDc1IDcyIDMxIDMyIDM4IDogdXIyNTYsYXJjZm91cjEyOA0KMDBlMDog MkMgNjEgNjUgNzMgMzEgMzIgMzggMkQgIDYzIDYyIDYzIDJDIDMzIDY0IDY1IDczIDogLGFl czEyOC1jYmMsM2Rlcw0KMDBmMDogMkQgNjMgNjIgNjMgMkMgNjIgNkMgNkYgIDc3IDY2IDY5 IDczIDY4IDJEIDYzIDYyIDogLWNiYyxibG93ZmlzaC1jYg0KMDEwMDogNjMgMkMgNjMgNjEg NzMgNzQgMzEgMzIgIDM4IDJEIDYzIDYyIDYzIDJDIDYxIDY1IDogYyxjYXN0MTI4LWNiYyxh ZQ0KMDExMDogNzMgMzEgMzkgMzIgMkQgNjMgNjIgNjMgIDJDIDYxIDY1IDczIDMyIDM1IDM2 IDJEIDogczE5Mi1jYmMsYWVzMjU2LQ0KMDEyMDogNjMgNjIgNjMgMkMgNjEgNzIgNjMgNjYg IDZGIDc1IDcyIDJDIDcyIDY5IDZBIDZFIDogY2JjLGFyY2ZvdXIscmlqbg0KMDEzMDogNjQg NjEgNjUgNkMgMkQgNjMgNjIgNjMgIDQwIDZDIDc5IDczIDYxIDc0IDZGIDcyIDogZGFlbC1j YmNAbHlzYXRvcg0KMDE0MDogMkUgNkMgNjkgNzUgMkUgNzMgNjUgMDAgIDAwIDAwIDlEIDYx IDY1IDczIDMxIDMyIDogLmxpdS5zZS4uLi5hZXMxMg0KMDE1MDogMzggMkQgNjMgNzQgNzIg MkMgNjEgNjUgIDczIDMxIDM5IDMyIDJEIDYzIDc0IDcyIDogOC1jdHIsYWVzMTkyLWN0cg0K MDE2MDogMkMgNjEgNjUgNzMgMzIgMzUgMzYgMkQgIDYzIDc0IDcyIDJDIDYxIDcyIDYzIDY2 IDogLGFlczI1Ni1jdHIsYXJjZg0KMDE3MDogNkYgNzUgNzIgMzIgMzUgMzYgMkMgNjEgIDcy IDYzIDY2IDZGIDc1IDcyIDMxIDMyIDogb3VyMjU2LGFyY2ZvdXIxMg0KMDE4MDogMzggMkMg NjEgNjUgNzMgMzEgMzIgMzggIDJEIDYzIDYyIDYzIDJDIDMzIDY0IDY1IDogOCxhZXMxMjgt Y2JjLDNkZQ0KMDE5MDogNzMgMkQgNjMgNjIgNjMgMkMgNjIgNkMgIDZGIDc3IDY2IDY5IDcz IDY4IDJEIDYzIDogcy1jYmMsYmxvd2Zpc2gtYw0KMDFhMDogNjIgNjMgMkMgNjMgNjEgNzMg NzQgMzEgIDMyIDM4IDJEIDYzIDYyIDYzIDJDIDYxIDogYmMsY2FzdDEyOC1jYmMsYQ0KMDFi MDogNjUgNzMgMzEgMzkgMzIgMkQgNjMgNjIgIDYzIDJDIDYxIDY1IDczIDMyIDM1IDM2IDog ZXMxOTItY2JjLGFlczI1Ng0KMDFjMDogMkQgNjMgNjIgNjMgMkMgNjEgNzIgNjMgIDY2IDZG IDc1IDcyIDJDIDcyIDY5IDZBIDogLWNiYyxhcmNmb3VyLHJpag0KMDFkMDogNkUgNjQgNjEg NjUgNkMgMkQgNjMgNjIgIDYzIDQwIDZDIDc5IDczIDYxIDc0IDZGIDogbmRhZWwtY2JjQGx5 c2F0bw0KMDFlMDogNzIgMkUgNkMgNjkgNzUgMkUgNzMgNjUgIDAwIDAwIDAwIDY5IDY4IDZE IDYxIDYzIDogci5saXUuc2UuLi5paG1hYw0KMDFmMDogMkQgNkQgNjQgMzUgMkMgNjggNkQg NjEgIDYzIDJEIDczIDY4IDYxIDMxIDJDIDc1IDogLW1kNSxobWFjLXNoYTEsdQ0KMDIwMDog NkQgNjEgNjMgMkQgMzYgMzQgNDAgNkYgIDcwIDY1IDZFIDczIDczIDY4IDJFIDYzIDogbWFj LTY0QG9wZW5zc2guYw0KMDIxMDogNkYgNkQgMkMgNjggNkQgNjEgNjMgMkQgIDcyIDY5IDcw IDY1IDZEIDY0IDMxIDM2IDogb20saG1hYy1yaXBlbWQxNg0KMDIyMDogMzAgMkMgNjggNkQg NjEgNjMgMkQgNzIgIDY5IDcwIDY1IDZEIDY0IDMxIDM2IDMwIDogMCxobWFjLXJpcGVtZDE2 MA0KMDIzMDogNDAgNkYgNzAgNjUgNkUgNzMgNzMgNjggIDJFIDYzIDZGIDZEIDJDIDY4IDZE IDYxIDogQG9wZW5zc2guY29tLGhtYQ0KMDI0MDogNjMgMkQgNzMgNjggNjEgMzEgMkQgMzkg IDM2IDJDIDY4IDZEIDYxIDYzIDJEIDZEIDogYy1zaGExLTk2LGhtYWMtbQ0KMDI1MDogNjQg MzUgMkQgMzkgMzYgMDAgMDAgMDAgIDY5IDY4IDZEIDYxIDYzIDJEIDZEIDY0IDogZDUtOTYu Li5paG1hYy1tZA0KMDI2MDogMzUgMkMgNjggNkQgNjEgNjMgMkQgNzMgIDY4IDYxIDMxIDJD IDc1IDZEIDYxIDYzIDogNSxobWFjLXNoYTEsdW1hYw0KMDI3MDogMkQgMzYgMzQgNDAgNkYg NzAgNjUgNkUgIDczIDczIDY4IDJFIDYzIDZGIDZEIDJDIDogLTY0QG9wZW5zc2guY29tLA0K MDI4MDogNjggNkQgNjEgNjMgMkQgNzIgNjkgNzAgIDY1IDZEIDY0IDMxIDM2IDMwIDJDIDY4 IDogaG1hYy1yaXBlbWQxNjAsaA0KMDI5MDogNkQgNjEgNjMgMkQgNzIgNjkgNzAgNjUgIDZE IDY0IDMxIDM2IDMwIDQwIDZGIDcwIDogbWFjLXJpcGVtZDE2MEBvcA0KMDJhMDogNjUgNkUg NzMgNzMgNjggMkUgNjMgNkYgIDZEIDJDIDY4IDZEIDYxIDYzIDJEIDczIDogZW5zc2guY29t LGhtYWMtcw0KMDJiMDogNjggNjEgMzEgMkQgMzkgMzYgMkMgNjggIDZEIDYxIDYzIDJEIDZE IDY0IDM1IDJEIDogaGExLTk2LGhtYWMtbWQ1LQ0KMDJjMDogMzkgMzYgMDAgMDAgMDAgMTUg NkUgNkYgIDZFIDY1IDJDIDdBIDZDIDY5IDYyIDQwIDogOTYuLi4ubm9uZSx6bGliQA0KMDJk MDogNkYgNzAgNjUgNkUgNzMgNzMgNjggMkUgIDYzIDZGIDZEIDAwIDAwIDAwIDE1IDZFIDog b3BlbnNzaC5jb20uLi4ubg0KMDJlMDogNkYgNkUgNjUgMkMgN0EgNkMgNjkgNjIgIDQwIDZG IDcwIDY1IDZFIDczIDczIDY4IDogb25lLHpsaWJAb3BlbnNzaA0KMDJmMDogMkUgNjMgNkYg NkQgMDAgMDAgMDAgMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDogLmNvbS4uLi4uLi4u Li4uLg0KMDMwMDogMDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDogLg0KW2xpYnNzaDJdIDAuNjYxMTg5IFRyYW5zcG9ydDogUGFja2V0IHR5cGUg MjAgcmVjZWl2ZWQsIGxlbmd0aD03NjkNCltsaWJzc2gyXSAwLjY2MTE5NCBUcmFuc3BvcnQ6 IExvb2tpbmcgZm9yIHBhY2tldCBvZiB0eXBlOiAyMA0KW2xpYnNzaDJdIDAuNjYxMjE4IEtl eSBFeDogQWdyZWVkIG9uIEtFWCBtZXRob2Q6IGRpZmZpZS1oZWxsbWFuLWdyb3VwMTQtc2hh MQ0KW2xpYnNzaDJdIDAuNjYxMjIxIEtleSBFeDogQWdyZWVkIG9uIEhPU1RLRVkgbWV0aG9k OiBzc2gtcnNhDQpbbGlic3NoMl0gMC42NjEyMjQgS2V5IEV4OiBBZ3JlZWQgb24gQ1JZUFRf Q1MgbWV0aG9kOiBhZXMxMjgtY3RyDQpbbGlic3NoMl0gMC42NjEyMjcgS2V5IEV4OiBBZ3Jl ZWQgb24gQ1JZUFRfU0MgbWV0aG9kOiBhZXMxMjgtY3RyDQpbbGlic3NoMl0gMC42NjEyMzAg S2V5IEV4OiBBZ3JlZWQgb24gTUFDX0NTIG1ldGhvZDogaG1hYy1zaGExDQpbbGlic3NoMl0g MC42NjEyMzMgS2V5IEV4OiBBZ3JlZWQgb24gTUFDX1NDIG1ldGhvZDogaG1hYy1zaGExDQpb bGlic3NoMl0gMC42NjEyMzUgS2V5IEV4OiBBZ3JlZWQgb24gQ09NUF9DUyBtZXRob2Q6IG5v bmUNCltsaWJzc2gyXSAwLjY2MTIzOCBLZXkgRXg6IEFncmVlZCBvbiBDT01QX1NDIG1ldGhv ZDogbm9uZQ0KW2xpYnNzaDJdIDAuNjYxMjYxIEtleSBFeDogSW5pdGlhdGluZyBEaWZmaWUt SGVsbG1hbiBHcm91cDE0IEtleSBFeGNoYW5nZQ0KW2xpYnNzaDJdIDAuNjYzMDM4IEtleSBF eDogU2VuZGluZyBLRVggcGFja2V0IDMwDQo9PiBsaWJzc2gyX3RyYW5zcG9ydF93cml0ZSBw bGFpbiAoMjYyIGJ5dGVzKQ0KMDAwMDogMUUgMDAgMDAgMDEgMDEgMDAgQjcgMUQgIEQxIDdC IDk5IEI5IDVCIDlGIENEIDREIDogLi4uLi4uLi4uey4uWy4uTQ0KMDAxMDogRUUgRkQgRDcg NDAgQTggODUgRTMgMkIgIDdCIDZGIEUwIDVBIEU5IDg5IDA4IDNEIDogLi4uQC4uLit7by5a Li4uPQ0KMDAyMDogMUQgOEYgNzQgQTcgOTkgQzUgQTQgNDYgIDZDIEI3IDBEIDgyIDczIEFC IEI3IEE1IDogLi50Li4uLkZsLi4ucy4uLg0KMDAzMDogRDYgMTkgMzkgNjQgOTAgMTAgOTgg MzYgIDU2IEQ4IEU5IDVBIDc2IEZGIEFGIDYxIDogLi45ZC4uLjZWLi5adi4uYQ0KMDA0MDog OUUgQjAgRDEgNUEgRUMgNEMgNTYgMDEgIDREIEE0IEE5IDlDIDlGIDBEIDNGIDQ5IDogLi4u Wi5MVi5NLi4uLi4/SQ0KMDA1MDogOEUgNjMgRTIgMTkgNDYgMkYgNjIgODAgIDM2IDE3IDkx IEYyIDVCIDI5IDJCIDg4IDogLmMuLkYvYi42Li4uWykrLg0KMDA2MDogNDAgOTEgQzIgQ0Eg MDYgNkUgMEYgMTkgIDAwIDA1IEQ5IERBIEEzIEQwIDY2IDI5IDogQC4uLi5uLi4uLi4uLi5m KQ0KMDA3MDogM0UgODUgQzggNDcgOEIgMjMgMUIgMkIgIDg2IDhBIDQyIDgwIDJDIEZCIDVB IDY2IDogPi4uRy4jLisuLkIuLC5aZg0KMDA4MDogNzAgNDggRjMgNEMgQkIgQTkgQUEgNEMg IDk0IEFFIEU3IDZFIDVFIEU0IDk5IDFBIDogcEguTC4uLkwuLi5uXi4uLg0KMDA5MDogN0Yg RUIgNEMgMTUgM0QgQ0YgOTAgMzYgIDUzIEVDIDA2IDczIDRBIDE4IDAwIDY4IDogLi5MLj0u LjZTLi5zSi4uaA0KMDBhMDogNTQgQUMgODcgMTYgNEIgREQgMTkgQzYgIDA5IDY2IDM1IDZD IDIxIDI5IDFFIDk2IDogVC4uLksuLi4uZjVsISkuLg0KMDBiMDogMDYgQkUgODkgRTAgRUEg QzMgNzAgN0IgIEM0IDQzIEQ0IDk1IEVBIDNGIEM4IDZGIDogLi4uLi4ucHsuQy4uLj8ubw0K MDBjMDogOTcgQjkgODIgMjkgQjYgMEEgM0MgMDEgIDg0IDNCIEM4IDAxIDhGIEIzIDQ4IDVC IDogLi4uKS4uPC4uOy4uLi5IWw0KMDBkMDogMTAgQTggRTIgNDkgQTIgRjAgODMgNTUgIDVG IDg1IDRDIDM3IDAwIEIxIDg4IERBIDogLi4uSS4uLlVfLkw3Li4uLg0KMDBlMDogMUYgQUMg QUQgNTMgMzggMTkgNTQgNzkgIDkxIERDIDcwIDQ1IDY4IDg2IEVCIEM2IDogLi4uUzguVHku LnBFaC4uLg0KMDBmMDogQkYgRjUgREUgNTkgMkEgRTAgOTcgMzMgIDk1IDcyIDM0IDI0IDM4 IEY3IEMwIDExIDogLi4uWSouLjMucjQkOC4uLg0KMDEwMDogOTAgRjYgOEYgMzcgM0QgMkEg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogLi4uNz0qDQpbbGlic3NoMl0gMC42 NjMxMzYgU29ja2V0OiBTZW50IDI3Mi8yNzIgYnl0ZXMgYXQgMHg5YzAxMjgNCj0+IGxpYnNz aDJfdHJhbnNwb3J0X3dyaXRlIHNlbmQoKSAoMjcyIGJ5dGVzKQ0KMDAwMDogMDAgMDAgMDEg MEMgMDUgMUUgMDAgMDAgIDAxIDAxIDAwIEI3IDFEIEQxIDdCIDk5IDogLi4uLi4uLi4uLi4u Li57Lg0KMDAxMDogQjkgNUIgOUYgQ0QgNEQgRUUgRkQgRDcgIDQwIEE4IDg1IEUzIDJCIDdC IDZGIEUwIDogLlsuLk0uLi5ALi4uK3tvLg0KMDAyMDogNUEgRTkgODkgMDggM0QgMUQgOEYg NzQgIEE3IDk5IEM1IEE0IDQ2IDZDIEI3IDBEIDogWi4uLj0uLnQuLi4uRmwuLg0KMDAzMDog ODIgNzMgQUIgQjcgQTUgRDYgMTkgMzkgIDY0IDkwIDEwIDk4IDM2IDU2IEQ4IEU5IDogLnMu Li4uLjlkLi4uNlYuLg0KMDA0MDogNUEgNzYgRkYgQUYgNjEgOUUgQjAgRDEgIDVBIEVDIDRD IDU2IDAxIDREIEE0IEE5IDogWnYuLmEuLi5aLkxWLk0uLg0KMDA1MDogOUMgOUYgMEQgM0Yg NDkgOEUgNjMgRTIgIDE5IDQ2IDJGIDYyIDgwIDM2IDE3IDkxIDogLi4uP0kuYy4uRi9iLjYu Lg0KMDA2MDogRjIgNUIgMjkgMkIgODggNDAgOTEgQzIgIENBIDA2IDZFIDBGIDE5IDAwIDA1 IEQ5IDogLlspKy5ALi4uLm4uLi4uLg0KMDA3MDogREEgQTMgRDAgNjYgMjkgM0UgODUgQzgg IDQ3IDhCIDIzIDFCIDJCIDg2IDhBIDQyIDogLi4uZik+Li5HLiMuKy4uQg0KMDA4MDogODAg MkMgRkIgNUEgNjYgNzAgNDggRjMgIDRDIEJCIEE5IEFBIDRDIDk0IEFFIEU3IDogLiwuWmZw SC5MLi4uTC4uLg0KMDA5MDogNkUgNUUgRTQgOTkgMUEgN0YgRUIgNEMgIDE1IDNEIENGIDkw IDM2IDUzIEVDIDA2IDogbl4uLi4uLkwuPS4uNlMuLg0KMDBhMDogNzMgNEEgMTggMDAgNjgg NTQgQUMgODcgIDE2IDRCIEREIDE5IEM2IDA5IDY2IDM1IDogc0ouLmhULi4uSy4uLi5mNQ0K MDBiMDogNkMgMjEgMjkgMUUgOTYgMDYgQkUgODkgIEUwIEVBIEMzIDcwIDdCIEM0IDQzIEQ0 IDogbCEpLi4uLi4uLi5wey5DLg0KMDBjMDogOTUgRUEgM0YgQzggNkYgOTcgQjkgODIgIDI5 IEI2IDBBIDNDIDAxIDg0IDNCIEM4IDogLi4/Lm8uLi4pLi48Li47Lg0KMDBkMDogMDEgOEYg QjMgNDggNUIgMTAgQTggRTIgIDQ5IEEyIEYwIDgzIDU1IDVGIDg1IDRDIDogLi4uSFsuLi5J Li4uVV8uTA0KMDBlMDogMzcgMDAgQjEgODggREEgMUYgQUMgQUQgIDUzIDM4IDE5IDU0IDc5 IDkxIERDIDcwIDogNy4uLi4uLi5TOC5UeS4ucA0KMDBmMDogNDUgNjggODYgRUIgQzYgQkYg RjUgREUgIDU5IDJBIEUwIDk3IDMzIDk1IDcyIDM0IDogRWguLi4uLi5ZKi4uMy5yNA0KMDEw MDogMjQgMzggRjcgQzAgMTEgOTAgRjYgOEYgIDM3IDNEIDJBIDI1IEUwIDIyIEI3IEIwIDog JDguLi4uLi43PSolLiIuLg0KW2xpYnNzaDJdIDAuNjYzMjM1IFRyYW5zcG9ydDogTG9va2lu ZyBmb3IgcGFja2V0IG9mIHR5cGU6IDMxDQpbbGlic3NoMl0gMC43MTM1NDcgU29ja2V0OiBS ZWN2ZWQgODQ4LzE2Mzg0IGJ5dGVzIHRvIDB4OWJjMGU4KzANCj0+IGxpYnNzaDJfdHJhbnNw b3J0X3JlYWQoKSByYXcgKDg0OCBieXRlcykNCjAwMDA6IDAwIDAwIDAzIDNDIDA4IDFGIDAw IDAwICAwMSAxNyAwMCAwMCAwMCAwNyA3MyA3MyA6IC4uLjwuLi4uLi4uLi4uc3MNCjAwMTA6 IDY4IDJEIDcyIDczIDYxIDAwIDAwIDAwICAwMyAwMSAwMCAwMSAwMCAwMCAwMSAwMSA6IGgt cnNhLi4uLi4uLi4uLi4NCjAwMjA6IDAwIEQ3IDk2IEMwIDM2IDRBIDhEIEQ2ICAzMiA4MSA5 NCAzMyA0NiBCNiAzMiA3MyA6IC4uLi42Si4uMi4uM0YuMnMNCjAwMzA6IDM5IEFEIDAzIEZB IEI0IDlBIDE0IEU0ICA0RCA3RSAzRCBCNyA5OCA0QiBCQiBCOSA6IDkuLi4uLi4uTX49Li5L Li4NCjAwNDA6IEY1IDIwIDNDIDhBIERDIDkzIDZDIDM0ICBFNCAyNSAyNiBFMSBEMyA5QyA4 QyA1NyA6IC4gPC4uLmw0LiUmLi4uLlcNCjAwNTA6IEVGIENGIEM2IDA3IEQzIDZDIEM4IEM5 ICA2OSBFRSA2RSBDRCBFRSA2NCBERCAwMiA6IC4uLi4ubC4uaS5uLi5kLi4NCjAwNjA6IEUz IDVFIDFCIDlDIEE2IDlBIEY2IEIxICBEMCA2NiA0NyA2QSBGNCA5NyAyQSAwMyA6IC5eLi4u Li4uLmZHai4uKi4NCjAwNzA6IDM3IEY2IDE4IEQ0IEVCIDIyIDkzIDFFICBBOSBCNiAxMiA4 QyAwRSA3RCBGNyAzRSA6IDcuLi4uIi4uLi4uLi59Lj4NCjAwODA6IERGIDJGIDkwIDQzIDBG IDdGIEVFIEI0ICBEOSA5QSBDMCBDMiBDMyBEMCAxRiA5MCA6IC4vLkMuLi4uLi4uLi4uLi4N CjAwOTA6IDc5IEMwIDRCIDY4IDA3IEEwIDNCIEFFICBDQyBFNSBEOCA3NSAyMiA3MCBBRSBB QiA6IHkuS2guLjsuLi4udSJwLi4NCjAwYTA6IDhGIEMzIDA5IDlBIEY0IEUwIDNFIDhFICBD OCA0RSA4OSBCMCAwNCBCNyAzNSBGNCA6IC4uLi4uLj4uLk4uLi4uNS4NCjAwYjA6IEM2IENC IDdDIDgyIDM5IDMxIEUwIDdBICA2NiBEQiBCMiAyNiBFRCAxNiAyOCA0QyA6IC4ufC45MS56 Zi4uJi4uKEwNCjAwYzA6IDBGIEJDIEQ5IEMyIDdFIDUzIDBFIEVBICAwMyAzQiBEMyA5MiA1 MyBGMiA4QyBGOSA6IC4uLi5+Uy4uLjsuLlMuLi4NCjAwZDA6IEZFIEIwIEY5IDg0IEUzIDQx IDU2IEM0ICBGOCBGNSAzRiBCRCBBRSAwQiBBMiAyOCA6IC4uLi4uQVYuLi4/Li4uLigNCjAw ZTA6IDc0IEU1IDhCIEI1IEUyIEE2IDFFIEZEICA4OCAyMSBDNiBCQiA5RCA1RSA1RCA4QSA6 IHQuLi4uLi4uLiEuLi5eXS4NCjAwZjA6IDgzIDMzIDcyIDhCIDVFIDhFIDAwIEY0ICBGNiAy NCA0MSA0OCA1OCA4RiA5QyA4MCA6IC4zci5eLi4uLiRBSFguLi4NCjAxMDA6IDMzIDMyIDcy IDZDIDEyIEM3IERDIEY1ICA0MSAxQiAzQSBFRCAxNCA3RCA3NiA0NyA6IDMycmwuLi4uQS46 Li59dkcNCjAxMTA6IDM5IDRGIDdGIDU3IEQ3IDA1IEQ4IEE0ICAyOSAzOSBCOCAyQiA0MiBC MCAxRSAxMCA6IDlPLlcuLi4uKTkuK0IuLi4NCjAxMjA6IDU1IDAwIDAwIDAxIDAwIDM4IDVC IDc1ICA5QSA5NyA0MSA3MCA0RiA4RiAwRSAzNiA6IFUuLi4uOFt1Li5BcE8uLjYNCjAxMzA6 IDYxIDQyIDE1IDY0IDJCIDBBIEU0IEI1ICA3QSA0MCA1RCA2NCAzRCBGMyAyQSBGOSA6IGFC LmQrLi4uekBdZD0uKi4NCjAxNDA6IDY3IDVCIDQ2IDI2IEY1IDNCIEY3IEVGICBGMyBFMyAy QiBDMSA0NCA3QiA0RSBBNyA6IGdbRiYuOy4uLi4rLkR7Ti4NCjAxNTA6IDJGIEZDIDlDIDdD IDI4IDI5IDRDIDUwICA4OSBCNCA0QSA5QyBDMyA0MSA1RiA5QiA6IC8uLnwoKUxQLi5KLi5B Xy4NCjAxNjA6IEExIDRDIEM1IEFFIEUxIEJEIEI1IDZFICA3MyA2QyA3NiAxNCAzMyAxNiAz QSA4QSA6IC5MLi4uLi5uc2x2LjMuOi4NCjAxNzA6IDEyIDkxIDc1IDYwIDJBIEE3IDg4IDhB ICBBNCAyNiBFOSBDMSA2RiA3MSBFOCA5MiA6IC4udWAqLi4uLiYuLm9xLi4NCjAxODA6IEI1 IEZDIEFFIEM2IEUwIDg2IDk3IDNGICAxRSA2MiAyRCAzRCA4MiA2QSA2NyBGOSA6IC4uLi4u Li4/LmItPS5qZy4NCjAxOTA6IDc4IEM2IEE0IEM2IDRFIEJDIDM3IEZDICA4NyA3RSA5NSA2 RSBDQyAzNSBEQyBFQSA6IHguLi5OLjcuLn4ubi41Li4NCjAxYTA6IDNDIDU1IDk5IDFEIDk5 IDhFIEZDIDFEICA1QSBENSAyRCAyRSAzOCBBRCA2RCAyOCA6IDxVLi4uLi4uWi4tLjgubSgN CjAxYjA6IEUzIDBDIDI2IEY2IDdBIEZDIEE5IEY3ICBCRCA1RCA0RiA2NSBDQiA2MyA3NCBG QSA6IC4uJi56Li4uLl1PZS5jdC4NCjAxYzA6IDdCIDM0IDIyIEU5IEY4IDY0IDVEIEVBICA5 RCA4MSA4MyA4NiAwOCA4NSBCMCBBRiA6IHs0Ii4uZF0uLi4uLi4uLi4NCjAxZDA6IEJDIEZB IDczIEE3IDAzIDg1IDc3IEIxICBBOSBFNiBENSBBNSA1MSA1RCBCNiAwNCA6IC4ucy4uLncu Li4uLlFdLi4NCjAxZTA6IDE2IDc5IDJCIDdCIEE3IDQ1IEYwIDkwICA1MiBDMSAyOCA5RCBD MSBDNSA0NyAzQyA6IC55K3suRS4uUi4oLi4uRzwNCjAxZjA6IDM4IEFDIDEyIDVCIDU0IERF IEREIEFCICA1MSA1RSA3NCA3NSBEMyAzMiA5QSAxNyA6IDguLltULi4uUV50dS4yLi4NCjAy MDA6IDVEIDk4IDM5IDdGIDA3IEM0IDU0IEE4ICBGRSBDOCBEOSA3MSA0MyBFMiA1RCA3MCA6 IF0uOS4uLlQuLi4ucUMuXXANCjAyMTA6IDNCIERFIDAxIERFIDZDIDZCIDY3IDAzICBGMSA0 MSA2OSBFNyAzMiBBNSA4QiBFMyA6IDsuLi5sa2cuLkFpLjIuLi4NCjAyMjA6IDMwIEYxIEE0 IEJBIEZEIDAwIDAwIDAxICAwRiAwMCAwMCAwMCAwNyA3MyA3MyA2OCA6IDAuLi4uLi4uLi4u Li5zc2gNCjAyMzA6IDJEIDcyIDczIDYxIDAwIDAwIDAxIDAwICA1QyBBOSBDMSAzMSA0OSAz RCBFQiA5OCA6IC1yc2EuLi4uXC4uMUk9Li4NCjAyNDA6IDcyIDMxIDZEIEZCIEVBIDFBIERF IDE1ICBCQyBGMyA0NCBDMyA5OSBCOCA1QyA4OCA6IHIxbS4uLi4uLi5ELi4uXC4NCjAyNTA6 IDU2IDk1IDgyIDREIDQ4IEYyIEFBIDIwICBDRiA2MCAyOSBDRSA3NSBFMiA1OSAyOCA6IFYu Lk1ILi4gLmApLnUuWSgNCjAyNjA6IDk2IDQ2IDVCIDA2IDNCIDBCIDk5IDI1ICA5RCBCNyBG OCA5RSAzQyBBNiAyOSAwRCA6IC5GWy47Li4lLi4uLjwuKS4NCjAyNzA6IDU1IDQyIEJBIDRG IEMyIEU0IEU5IEJCICAwMSAxRiAwNiA0NiBDRiBGRCAxRSAzMSA6IFVCLk8uLi4uLi4uRi4u LjENCjAyODA6IEY1IDU5IEQ3IEJGIDQzIEI4IEYyIEVCICA0MyA1NSA2QiA0QiBCMyAwOSA0 RCA1NiA6IC5ZLi5DLi4uQ1VrSy4uTVYNCjAyOTA6IEVEIEEzIEM2IDI3IDE0IDRDIEVDIDI5 ICA5MCBCMyA1QyA0MCA3MCA4RSBDRiA5OCA6IC4uLicuTC4pLi5cQHAuLi4NCjAyYTA6IEJC IEFDIDhCIDQ4IDlEIDZDIDhEIDU3ICBDMCBFQyBFMiA3OSBDMyAwNSBEQiA2QyA6IC4uLkgu bC5XLi4ueS4uLmwNCjAyYjA6IDQzIDU2IEQ1IDg0IEUyIDRGIDBEIDM5ICA0RiA0QiAwMCBF MiBGMCAyMCA5MiA1NyA6IENWLi4uTy45T0suLi4gLlcNCjAyYzA6IEUzIDQzIDkyIDI4IDk3 IDkyIDE2IDEwICA3NCA1MyA2NiAzOCA3RSAxMSAzNSA5MCA6IC5DLiguLi4udFNmOH4uNS4N CjAyZDA6IEQyIENEIEE5IEI4IDNGIEE1IDFEIDEwICBENCA2NiBEOCBCNCBFNiA4MyBDRiA3 MiA6IC4uLi4/Li4uLmYuLi4uLnINCjAyZTA6IDUzIDYxIEI2IDdEIDQzIDRCIDlCIEEwICA0 NSA5MiA2NiA0MSBGNyA2MCA5OCBCMCA6IFNhLn1DSy4uRS5mQS5gLi4NCjAyZjA6IDAwIDI0 IDRCIDY0IDZBIDFCIDNGIDg0ICAzQyA0MiBCNyA0OSBBNSA2MSA4OSBFNiA6IC4kS2RqLj8u PEIuSS5hLi4NCjAzMDA6IEVFIDQzIEJCIDY0IEFBIDA2IDYwIDhBICBFNCA5QyA3RSA4OCAx RCAwNyBGRCBGNCA6IC5DLmQuLmAuLi5+Li4uLi4NCjAzMTA6IEZDIDY0IDJBIDdEIDI4IDcw IEVFIEQ5ICBEMiA5NiAwNCBCMiA5QyA1OCBDMSBDMiA6IC5kKn0ocC4uLi4uLi5YLi4NCjAz MjA6IDM3IDI4IERDIEVBIDNEIDE4IDFGIDk4ICBFMSA4MCBBRiAwRSA5NSAxQiA3QyA4RiA6 IDcoLi49Li4uLi4uLi4ufC4NCjAzMzA6IDE4IDE2IDY1IDI2IDQ5IDAyIEU2IDMyICAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCA6IC4uZSZJLi4yLi4uLi4uLi4NCjAzNDA6IDAwIDAwIDAw IDBDIDBBIDE1IDAwIDAwICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCA6IC4uLi4uLi4uLi4u Li4uLi4NCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3JlYWQoKSBwbGFpbiAoODE5IGJ5dGVzKQ0K MDAwMDogMUYgMDAgMDAgMDEgMTcgMDAgMDAgMDAgIDA3IDczIDczIDY4IDJEIDcyIDczIDYx IDogLi4uLi4uLi4uc3NoLXJzYQ0KMDAxMDogMDAgMDAgMDAgMDMgMDEgMDAgMDEgMDAgIDAw IDAxIDAxIDAwIEQ3IDk2IEMwIDM2IDogLi4uLi4uLi4uLi4uLi4uNg0KMDAyMDogNEEgOEQg RDYgMzIgODEgOTQgMzMgNDYgIEI2IDMyIDczIDM5IEFEIDAzIEZBIEI0IDogSi4uMi4uM0Yu MnM5Li4uLg0KMDAzMDogOUEgMTQgRTQgNEQgN0UgM0QgQjcgOTggIDRCIEJCIEI5IEY1IDIw IDNDIDhBIERDIDogLi4uTX49Li5LLi4uIDwuLg0KMDA0MDogOTMgNkMgMzQgRTQgMjUgMjYg RTEgRDMgIDlDIDhDIDU3IEVGIENGIEM2IDA3IEQzIDogLmw0LiUmLi4uLlcuLi4uLg0KMDA1 MDogNkMgQzggQzkgNjkgRUUgNkUgQ0QgRUUgIDY0IEREIDAyIEUzIDVFIDFCIDlDIEE2IDog bC4uaS5uLi5kLi4uXi4uLg0KMDA2MDogOUEgRjYgQjEgRDAgNjYgNDcgNkEgRjQgIDk3IDJB IDAzIDM3IEY2IDE4IEQ0IEVCIDogLi4uLmZHai4uKi43Li4uLg0KMDA3MDogMjIgOTMgMUUg QTkgQjYgMTIgOEMgMEUgIDdEIEY3IDNFIERGIDJGIDkwIDQzIDBGIDogIi4uLi4uLi59Lj4u Ly5DLg0KMDA4MDogN0YgRUUgQjQgRDkgOUEgQzAgQzIgQzMgIEQwIDFGIDkwIDc5IEMwIDRC IDY4IDA3IDogLi4uLi4uLi4uLi55LktoLg0KMDA5MDogQTAgM0IgQUUgQ0MgRTUgRDggNzUg MjIgIDcwIEFFIEFCIDhGIEMzIDA5IDlBIEY0IDogLjsuLi4udSJwLi4uLi4uLg0KMDBhMDog RTAgM0UgOEUgQzggNEUgODkgQjAgMDQgIEI3IDM1IEY0IEM2IENCIDdDIDgyIDM5IDogLj4u Lk4uLi4uNS4uLnwuOQ0KMDBiMDogMzEgRTAgN0EgNjYgREIgQjIgMjYgRUQgIDE2IDI4IDRD IDBGIEJDIEQ5IEMyIDdFIDogMS56Zi4uJi4uKEwuLi4ufg0KMDBjMDogNTMgMEUgRUEgMDMg M0IgRDMgOTIgNTMgIEYyIDhDIEY5IEZFIEIwIEY5IDg0IEUzIDogUy4uLjsuLlMuLi4uLi4u Lg0KMDBkMDogNDEgNTYgQzQgRjggRjUgM0YgQkQgQUUgIDBCIEEyIDI4IDc0IEU1IDhCIEI1 IEUyIDogQVYuLi4/Li4uLih0Li4uLg0KMDBlMDogQTYgMUUgRkQgODggMjEgQzYgQkIgOUQg IDVFIDVEIDhBIDgzIDMzIDcyIDhCIDVFIDogLi4uLiEuLi5eXS4uM3IuXg0KMDBmMDogOEUg MDAgRjQgRjYgMjQgNDEgNDggNTggIDhGIDlDIDgwIDMzIDMyIDcyIDZDIDEyIDogLi4uLiRB SFguLi4zMnJsLg0KMDEwMDogQzcgREMgRjUgNDEgMUIgM0EgRUQgMTQgIDdEIDc2IDQ3IDM5 IDRGIDdGIDU3IEQ3IDogLi4uQS46Li59dkc5Ty5XLg0KMDExMDogMDUgRDggQTQgMjkgMzkg QjggMkIgNDIgIEIwIDFFIDEwIDU1IDAwIDAwIDAxIDAwIDogLi4uKTkuK0IuLi5VLi4uLg0K MDEyMDogMzggNUIgNzUgOUEgOTcgNDEgNzAgNEYgIDhGIDBFIDM2IDYxIDQyIDE1IDY0IDJC IDogOFt1Li5BcE8uLjZhQi5kKw0KMDEzMDogMEEgRTQgQjUgN0EgNDAgNUQgNjQgM0QgIEYz IDJBIEY5IDY3IDVCIDQ2IDI2IEY1IDogLi4uekBdZD0uKi5nW0YmLg0KMDE0MDogM0IgRjcg RUYgRjMgRTMgMkIgQzEgNDQgIDdCIDRFIEE3IDJGIEZDIDlDIDdDIDI4IDogOy4uLi4rLkR7 Ti4vLi58KA0KMDE1MDogMjkgNEMgNTAgODkgQjQgNEEgOUMgQzMgIDQxIDVGIDlCIEExIDRD IEM1IEFFIEUxIDogKUxQLi5KLi5BXy4uTC4uLg0KMDE2MDogQkQgQjUgNkUgNzMgNkMgNzYg MTQgMzMgIDE2IDNBIDhBIDEyIDkxIDc1IDYwIDJBIDogLi5uc2x2LjMuOi4uLnVgKg0KMDE3 MDogQTcgODggOEEgQTQgMjYgRTkgQzEgNkYgIDcxIEU4IDkyIEI1IEZDIEFFIEM2IEUwIDog Li4uLiYuLm9xLi4uLi4uLg0KMDE4MDogODYgOTcgM0YgMUUgNjIgMkQgM0QgODIgIDZBIDY3 IEY5IDc4IEM2IEE0IEM2IDRFIDogLi4/LmItPS5qZy54Li4uTg0KMDE5MDogQkMgMzcgRkMg ODcgN0UgOTUgNkUgQ0MgIDM1IERDIEVBIDNDIDU1IDk5IDFEIDk5IDogLjcuLn4ubi41Li48 VS4uLg0KMDFhMDogOEUgRkMgMUQgNUEgRDUgMkQgMkUgMzggIEFEIDZEIDI4IEUzIDBDIDI2 IEY2IDdBIDogLi4uWi4tLjgubSguLiYueg0KMDFiMDogRkMgQTkgRjcgQkQgNUQgNEYgNjUg Q0IgIDYzIDc0IEZBIDdCIDM0IDIyIEU5IEY4IDogLi4uLl1PZS5jdC57NCIuLg0KMDFjMDog NjQgNUQgRUEgOUQgODEgODMgODYgMDggIDg1IEIwIEFGIEJDIEZBIDczIEE3IDAzIDogZF0u Li4uLi4uLi4uLnMuLg0KMDFkMDogODUgNzcgQjEgQTkgRTYgRDUgQTUgNTEgIDVEIEI2IDA0 IDE2IDc5IDJCIDdCIEE3IDogLncuLi4uLlFdLi4ueSt7Lg0KMDFlMDogNDUgRjAgOTAgNTIg QzEgMjggOUQgQzEgIEM1IDQ3IDNDIDM4IEFDIDEyIDVCIDU0IDogRS4uUi4oLi4uRzw4Li5b VA0KMDFmMDogREUgREQgQUIgNTEgNUUgNzQgNzUgRDMgIDMyIDlBIDE3IDVEIDk4IDM5IDdG IDA3IDogLi4uUV50dS4yLi5dLjkuLg0KMDIwMDogQzQgNTQgQTggRkUgQzggRDkgNzEgNDMg IEUyIDVEIDcwIDNCIERFIDAxIERFIDZDIDogLlQuLi4ucUMuXXA7Li4ubA0KMDIxMDogNkIg NjcgMDMgRjEgNDEgNjkgRTcgMzIgIEE1IDhCIEUzIDMwIEYxIEE0IEJBIEZEIDoga2cuLkFp LjIuLi4wLi4uLg0KMDIyMDogMDAgMDAgMDEgMEYgMDAgMDAgMDAgMDcgIDczIDczIDY4IDJE IDcyIDczIDYxIDAwIDogLi4uLi4uLi5zc2gtcnNhLg0KMDIzMDogMDAgMDEgMDAgNUMgQTkg QzEgMzEgNDkgIDNEIEVCIDk4IDcyIDMxIDZEIEZCIEVBIDogLi4uXC4uMUk9Li5yMW0uLg0K MDI0MDogMUEgREUgMTUgQkMgRjMgNDQgQzMgOTkgIEI4IDVDIDg4IDU2IDk1IDgyIDREIDQ4 IDogLi4uLi5ELi4uXC5WLi5NSA0KMDI1MDogRjIgQUEgMjAgQ0YgNjAgMjkgQ0UgNzUgIEUy IDU5IDI4IDk2IDQ2IDVCIDA2IDNCIDogLi4gLmApLnUuWSguRlsuOw0KMDI2MDogMEIgOTkg MjUgOUQgQjcgRjggOUUgM0MgIEE2IDI5IDBEIDU1IDQyIEJBIDRGIEMyIDogLi4lLi4uLjwu KS5VQi5PLg0KMDI3MDogRTQgRTkgQkIgMDEgMUYgMDYgNDYgQ0YgIEZEIDFFIDMxIEY1IDU5 IEQ3IEJGIDQzIDogLi4uLi4uRi4uLjEuWS4uQw0KMDI4MDogQjggRjIgRUIgNDMgNTUgNkIg NEIgQjMgIDA5IDREIDU2IEVEIEEzIEM2IDI3IDE0IDogLi4uQ1VrSy4uTVYuLi4nLg0KMDI5 MDogNEMgRUMgMjkgOTAgQjMgNUMgNDAgNzAgIDhFIENGIDk4IEJCIEFDIDhCIDQ4IDlEIDog TC4pLi5cQHAuLi4uLi5ILg0KMDJhMDogNkMgOEQgNTcgQzAgRUMgRTIgNzkgQzMgIDA1IERC IDZDIDQzIDU2IEQ1IDg0IEUyIDogbC5XLi4ueS4uLmxDVi4uLg0KMDJiMDogNEYgMEQgMzkg NEYgNEIgMDAgRTIgRjAgIDIwIDkyIDU3IEUzIDQzIDkyIDI4IDk3IDogTy45T0suLi4gLlcu Qy4oLg0KMDJjMDogOTIgMTYgMTAgNzQgNTMgNjYgMzggN0UgIDExIDM1IDkwIEQyIENEIEE5 IEI4IDNGIDogLi4udFNmOH4uNS4uLi4uPw0KMDJkMDogQTUgMUQgMTAgRDQgNjYgRDggQjQg RTYgIDgzIENGIDcyIDUzIDYxIEI2IDdEIDQzIDogLi4uLmYuLi4uLnJTYS59Qw0KMDJlMDog NEIgOUIgQTAgNDUgOTIgNjYgNDEgRjcgIDYwIDk4IEIwIDAwIDI0IDRCIDY0IDZBIDogSy4u RS5mQS5gLi4uJEtkag0KMDJmMDogMUIgM0YgODQgM0MgNDIgQjcgNDkgQTUgIDYxIDg5IEU2 IEVFIDQzIEJCIDY0IEFBIDogLj8uPEIuSS5hLi4uQy5kLg0KMDMwMDogMDYgNjAgOEEgRTQg OUMgN0UgODggMUQgIDA3IEZEIEY0IEZDIDY0IDJBIDdEIDI4IDogLmAuLi5+Li4uLi4uZCp9 KA0KMDMxMDogNzAgRUUgRDkgRDIgOTYgMDQgQjIgOUMgIDU4IEMxIEMyIDM3IDI4IERDIEVB IDNEIDogcC4uLi4uLi5YLi43KC4uPQ0KMDMyMDogMTggMUYgOTggRTEgODAgQUYgMEUgOTUg IDFCIDdDIDhGIDE4IDE2IDY1IDI2IDQ5IDogLi4uLi4uLi4ufC4uLmUmSQ0KMDMzMDogMDIg RTYgMzIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogLi4yDQpb bGlic3NoMl0gMC43MTM5MTcgVHJhbnNwb3J0OiBQYWNrZXQgdHlwZSAzMSByZWNlaXZlZCwg bGVuZ3RoPTgxOQ0KW2xpYnNzaDJdIDAuNzEzOTI2IFRyYW5zcG9ydDogTG9va2luZyBmb3Ig cGFja2V0IG9mIHR5cGU6IDMxDQpbbGlic3NoMl0gMC43MTM5NjYgS2V5IEV4OiBTZXJ2ZXIn cyBNRDUgRmluZ2VycHJpbnQ6IGVmOjgwOjk2OjUzOjFjOjFkOjlhOjE5OmRkOjBhOjA3Ojkx Ojk2OjI5OjBiOmQ4DQpbbGlic3NoMl0gMC43MTM5ODQgS2V5IEV4OiBTZXJ2ZXIncyBTSEEx IEZpbmdlcnByaW50OiA2ZDowMDpiZDozMTpkOTo4YToxNjowMjo0NToyNzowZDoyYzo5Yjo5 NjpmODpkNDpiNTozNDphNTo1YQ0KW2xpYnNzaDJdIDAuNzE2OTk1IEtleSBFeDogU2VuZGlu ZyBORVdLRVlTIG1lc3NhZ2UNCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3dyaXRlIHBsYWluICgx IGJ5dGVzKQ0KMDAwMDogMTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDogLg0KW2xpYnNzaDJdIDAuNzE3MDgxIFNvY2tldDogU2VudCAxNi8xNiBi eXRlcyBhdCAweDljMDEyOA0KPT4gbGlic3NoMl90cmFuc3BvcnRfd3JpdGUgc2VuZCgpICgx NiBieXRlcykNCjAwMDA6IDAwIDAwIDAwIDBDIDBBIDE1IDgxIDI1ICBBOSAyOCA3NyBCMiBB RCA2NyA2RSA0MCA6IC4uLi4uLi4lLih3Li5nbkANCltsaWJzc2gyXSAwLjcxNzA5OCBUcmFu c3BvcnQ6IExvb2tpbmcgZm9yIHBhY2tldCBvZiB0eXBlOiAyMQ0KPT4gbGlic3NoMl90cmFu c3BvcnRfcmVhZCgpIHBsYWluICgxIGJ5dGVzKQ0KMDAwMDogMTUgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogLg0KW2xpYnNzaDJdIDAuNzE3MTI0 IFRyYW5zcG9ydDogUGFja2V0IHR5cGUgMjEgcmVjZWl2ZWQsIGxlbmd0aD0xDQpbbGlic3No Ml0gMC43MTcxMzAgVHJhbnNwb3J0OiBMb29raW5nIGZvciBwYWNrZXQgb2YgdHlwZTogMjEN CltsaWJzc2gyXSAwLjcxNzE1MSBLZXkgRXg6IFJlY2VpdmVkIE5FV0tFWVMgbWVzc2FnZQ0K W2xpYnNzaDJdIDAuNzE3MTU2IEtleSBFeDogc2Vzc2lvbl9pZCBjYWxjdWxhdGVkDQpbbGli c3NoMl0gMC43MTcxOTYgS2V5IEV4OiBDbGllbnQgdG8gU2VydmVyIElWIGFuZCBLZXkgY2Fs Y3VsYXRlZA0KW2xpYnNzaDJdIDAuNzE3MjA3IEtleSBFeDogU2VydmVyIHRvIENsaWVudCBJ ViBhbmQgS2V5IGNhbGN1bGF0ZWQNCltsaWJzc2gyXSAwLjcxNzIxMyBLZXkgRXg6IENsaWVu dCB0byBTZXJ2ZXIgSE1BQyBLZXkgY2FsY3VsYXRlZA0KW2xpYnNzaDJdIDAuNzE3MjE4IEtl eSBFeDogU2VydmVyIHRvIENsaWVudCBITUFDIEtleSBjYWxjdWxhdGVkDQpbbGlic3NoMl0g MC43MTcyMjEgS2V5IEV4OiBDbGllbnQgdG8gU2VydmVyIGNvbXByZXNzaW9uIGluaXRpYWxp emVkDQpbbGlic3NoMl0gMC43MTcyMjQgS2V5IEV4OiBTZXJ2ZXIgdG8gQ2xpZW50IGNvbXBy ZXNzaW9uIGluaXRpYWxpemVkDQpbbGlic3NoMl0gMC43MTcyMzYgVHJhbnNwb3J0OiBSZXF1 ZXN0aW5nIHVzZXJhdXRoIHNlcnZpY2UNCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3dyaXRlIHBs YWluICgxNyBieXRlcykNCjAwMDA6IDA1IDAwIDAwIDAwIDBDIDczIDczIDY4ICAyRCA3NSA3 MyA2NSA3MiA2MSA3NSA3NCA6IC4uLi4uc3NoLXVzZXJhdXQNCjAwMTA6IDY4ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6IGgNCltsaWJzc2gyXSAw LjcxNzI4MSBTb2NrZXQ6IFNlbnQgNTIvNTIgYnl0ZXMgYXQgMHg5YzAxMjgNCj0+IGxpYnNz aDJfdHJhbnNwb3J0X3dyaXRlIHNlbmQoKSAoNTIgYnl0ZXMpDQowMDAwOiAxQyBBNSBEMSAy MCBCNCBGQiA0MSBBQiAgMzQgOUUgMTYgRkQgMjEgMUMgQUIgMTIgOiAuLi4gLi5BLjQuLi4h Li4uDQowMDEwOiBERSAzRiA0NiAwNSA2RiBCQiA0QiA4NSAgMzUgQ0MgMTkgMkMgQzYgMjcg MjggOEQgOiAuP0Yuby5LLjUuLiwuJyguDQowMDIwOiA4MiBFRSA1QiAxOSBCNyA5MiBFMyA0 MCAgQzMgQUYgRjggM0EgRjYgRTQgMjcgNjIgOiAuLlsuLi4uQC4uLjouLidiDQowMDMwOiAy NCA2OCBGMiBDNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOiAkaC4u DQpbbGlic3NoMl0gMC43MTcyOTkgVHJhbnNwb3J0OiBMb29raW5nIGZvciBwYWNrZXQgb2Yg dHlwZTogNg0KW2xpYnNzaDJdIDAuNzY3NDYxIFNvY2tldDogUmVjdmVkIDUyLzE2Mzg0IGJ5 dGVzIHRvIDB4OWJjMGU4KzANCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3JlYWQoKSByYXcgKDUy IGJ5dGVzKQ0KMDAwMDogM0QgNTQgQzcgMjMgMzYgNzAgMEIgQUEgIDc0IEU0IDJCIEYwIDYz IEQxIDlEIEI4IDogPVQuIzZwLi50LisuYy4uLg0KMDAxMDogRDYgRDUgNDMgN0QgOUIgMDQg MTggMDMgIDc5IDNDIEQ1IDNEIEYwIDA4IDE2IDExIDogLi5DfS4uLi55PC49Li4uLg0KMDAy MDogN0MgMkIgQUMgREQgMDMgQzMgN0UgMkMgIDEzIDcyIDA0IEM1IDEyIDBFIDQ2IEIzIDog fCsuLi4ufiwuci4uLi5GLg0KMDAzMDogRUUgQjQgODkgRjcgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDogLi4uLg0KPT4gbGlic3NoMl90cmFuc3BvcnRfcmVhZCgp IHBsYWluICgxNyBieXRlcykNCjAwMDA6IDA2IDAwIDAwIDAwIDBDIDczIDczIDY4ICAyRCA3 NSA3MyA2NSA3MiA2MSA3NSA3NCA6IC4uLi4uc3NoLXVzZXJhdXQNCjAwMTA6IDY4ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6IGgNCltsaWJzc2gy XSAwLjc2NzU3MyBUcmFuc3BvcnQ6IFBhY2tldCB0eXBlIDYgcmVjZWl2ZWQsIGxlbmd0aD0x Nw0KW2xpYnNzaDJdIDAuNzY3NTc5IFRyYW5zcG9ydDogTG9va2luZyBmb3IgcGFja2V0IG9m IHR5cGU6IDYNCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3dyaXRlIHBsYWluICgyNyBieXRlcykN CjAwMDA6IDUwIDAwIDAwIDAwIDE1IDZCIDY1IDY1ICA3MCA2MSA2QyA2OSA3NiA2NSA0MCA2 QyA6IFAuLi4ua2VlcGFsaXZlQGwNCjAwMTA6IDY5IDYyIDczIDczIDY4IDMyIDJFIDZGICA3 MiA2NyAwMCAgICAgICAgICAgICAgICA6IGlic3NoMi5vcmcuDQpbbGlic3NoMl0gMC43Njc2 MzUgU29ja2V0OiBTZW50IDY4LzY4IGJ5dGVzIGF0IDB4OWMwMTI4DQo9PiBsaWJzc2gyX3Ry YW5zcG9ydF93cml0ZSBzZW5kKCkgKDY4IGJ5dGVzKQ0KMDAwMDogREMgNEIgMDMgNEQgRDYg MjQgRkIgODYgIDg0IDgxIENFIDk2IENCIDczIDI4IEMzIDogLksuTS4kLi4uLi4uLnMoLg0K MDAxMDogNjIgMkYgNzcgMkIgMjggNDcgQjMgODUgIDU3IDgyIDgzIDg5IDQ4IDlBIDRCIDJD IDogYi93KyhHLi5XLi4uSC5LLA0KMDAyMDogRjcgQ0IgQTYgRUYgOTQgRTkgQUEgNUIgIENB IDdDIDRGIEI5IDQ5IDA5IDdCIEZDIDogLi4uLi4uLlsufE8uSS57Lg0KMDAzMDogREYgMjIg QzAgN0MgMEQgQTUgM0IgQ0YgIDcyIEM2IEUxIDk1IDBCIDIzIDY2IEFCIDogLiIufC4uOy5y Li4uLiNmLg0KMDA0MDogNzkgRTkgNDYgMTQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDogeS5GLg0KW2xpYnNzaDJdIDAuNzY3NjkwIFVzZXJhdXRoOiBMb2FkaW5n IHB1YmxpYyBrZXkgZmlsZTogL3Zhci9saWIvcGFjZW1ha2VyLWNsb3VkL2tleXMvYXNzeS13 b3JkcHJlc3MtbXlzcWwtRjE2LnB1Yg0KW2xpYnNzaDJdIDAuNzcxOTYyIFVzZXJhdXRoOiBB dHRlbXB0aW5nIHB1YmxpY2tleSBhdXRoZW50aWNhdGlvbg0KPT4gbGlic3NoMl90cmFuc3Bv cnRfd3JpdGUgcGxhaW4gKDMzNSBieXRlcykNCjAwMDA6IDMyIDAwIDAwIDAwIDA0IDcyIDZG IDZGICA3NCAwMCAwMCAwMCAwRSA3MyA3MyA2OCA6IDIuLi4ucm9vdC4uLi5zc2gNCjAwMTA6 IDJEIDYzIDZGIDZFIDZFIDY1IDYzIDc0ICA2OSA2RiA2RSAwMCAwMCAwMCAwOSA3MCA6IC1j b25uZWN0aW9uLi4uLnANCjAwMjA6IDc1IDYyIDZDIDY5IDYzIDZCIDY1IDc5ICAwMCAwMCAw MCAwMCAwNyA3MyA3MyA2OCA6IHVibGlja2V5Li4uLi5zc2gNCjAwMzA6IDJEIDcyIDczIDYx IDAwIDAwIDAxIDE3ICAwMCAwMCAwMCAwNyA3MyA3MyA2OCAyRCA6IC1yc2EuLi4uLi4uLnNz aC0NCjAwNDA6IDcyIDczIDYxIDAwIDAwIDAwIDAzIDAxICAwMCAwMSAwMCAwMCAwMSAwMSAw MCBBRCA6IHJzYS4uLi4uLi4uLi4uLi4NCjAwNTA6IDMyIEIwIDdGIDJEIDIwIDdBIDA5IDNC ICA4QiBDRSA2MiAzRCA0RiAzRCBFQyBENCA6IDIuLi0gei47Li5iPU89Li4NCjAwNjA6IEVD IDc4IEMzIDEyIEUyIEIzIDI5IEZGICBCNSA0MCAyRCA1NyAyMyBERiA0RiAxNCA6IC54Li4u LikuLkAtVyMuTy4NCjAwNzA6IDc4IDhGIDk2IEY0IDNCIDlGIDUwIEI2ICBERiBENSBDRiAy NiAzOSA5OSA3MCBEMiA6IHguLi47LlAuLi4uJjkucC4NCjAwODA6IDRCIDAzIDVDIENBIDBF IEQ5IEY0IDNGICA0QyA1NiA2OCBGMSAxRiBDNCA5MyAwOCA6IEsuXC4uLi4/TFZoLi4uLi4N CjAwOTA6IEM4IDcyIDFDIEVGIDRCIEREIDU4IDg4ICA1NSAxMyAwNCAyNiA0QyAwQiAyRCA3 OCA6IC5yLi5LLlguVS4uJkwuLXgNCjAwYTA6IEQwIEE1IDFGIDYwIDM0IEFGIEEyIEM3ICBE NCA3OCAzMSBBMSA5QyBBMiA5QyBGMSA6IC4uLmA0Li4uLngxLi4uLi4NCjAwYjA6IDg5IDRB IDA5IDg2IDhDIDA3IEVDIEM1ICAzRCA3MiAwMiBFOSBGQiA5NyBGMCBFNSA6IC5KLi4uLi4u PXIuLi4uLi4NCjAwYzA6IDA4IEIzIDE3IDQzIDk0IDk3IEU5IDQ2ICA4QiA1OSA3MiA0MCA4 MiA4NCA5NCAxQSA6IC4uLkMuLi5GLllyQC4uLi4NCjAwZDA6IEZEIDQxIEM0IDU3IEJBIEU2 IDEwIDE3ICAwNSA5QiA0NSAyMiA4NCA3NyBGMCA0NyA6IC5BLlcuLi4uLi5FIi53LkcNCjAw ZTA6IDQxIDQ2IDdGIDZCIDE3IDM5IDJGIDQzICA3QyAxQiBGQiA0OCBEQSA5MiBDRiA1MSA6 IEFGLmsuOS9DfC4uSC4uLlENCjAwZjA6IDREIDE1IEMzIDhDIEVGIEZDIDEyIEJBICAyMiBG MCAyOCA0NSAzRiBDOSA0NSA5MCA6IE0uLi4uLi4uIi4oRT8uRS4NCjAxMDA6IEM4IEQ1IDE3 IDNEIDUwIEEyIERCIEI3ICAwQyA2NCA0QiBBRCA3MiA5QiBEOSAxMCA6IC4uLj1QLi4uLmRL LnIuLi4NCjAxMTA6IDQ4IDUxIEQ4IENDIEI4IDEyIDEwIDVDICBCMCBGMSBGNCBDQyAzNyBD RSA0MCBCRiA6IEhRLi4uLi5cLi4uLjcuQC4NCjAxMjA6IDY2IDE5IEYyIDk4IEVFIEI1IDA4 IDU3ICA3QSBBQSAwOSBFOSBBNSBBMyAwNSBDQiA6IGYuLi4uLi5Xei4uLi4uLi4NCjAxMzA6 IEREIDQwIDlEIEYzIDY5IDUzIDkxIDUwICBGRiA4MyBGNCA1MCAxMyBDMCA0NSBDRiA6IC5A Li5pUy5QLi4uUC4uRS4NCjAxNDA6IEIzIDM3IERCIDUxIEIwIERFIDBEIDZFICA1MyBEQiA0 NyAyMyAxOSA4NyA3QiAgICA6IC43LlEuLi5uUy5HIy4uew0KW2xpYnNzaDJdIDAuNzcyMTA3 IFNvY2tldDogU2VudCAzNzIvMzcyIGJ5dGVzIGF0IDB4OWMwMTI4DQo9PiBsaWJzc2gyX3Ry YW5zcG9ydF93cml0ZSBzZW5kKCkgKDM3MiBieXRlcykNCjAwMDA6IDUzIDQxIDE2IDJBIDkz IDY1IEFDIDhEICAzOSBGNyA5OCAwOSA3MyBEQiA1MyA3OSA6IFNBLiouZS4uOS4uLnMuU3kN CjAwMTA6IDg3IEU4IDM3IDlEIDBDIDQ3IDNDIEY1ICBGQiBFNCA0NSAwRSA0NiA3QSA4QyA5 NyA6IC4uNy4uRzwuLi5FLkZ6Li4NCjAwMjA6IDhBIEI1IDFCIDBDIDMwIEFCIEEwIEExICBD RiA1QiBERiAxMyA1NCA3QyA5NyA2RiA6IC4uLi4wLi4uLlsuLlR8Lm8NCjAwMzA6IDBBIDIx IDA1IEUzIEE5IDk0IEJDIDc5ICBFRiAzOCA3OCBFRSAwNiAxMyA1MSAyNCA6IC4hLi4uLi55 Ljh4Li4uUSQNCjAwNDA6IDFCIDA4IEVFIEE0IDI4IDQ1IEUwIEVGICBCRSAwOSA0RSBERSA1 RSA5QyBFQSBERCA6IC4uLi4oRS4uLi5OLl4uLi4NCjAwNTA6IDc3IDE3IDFGIDMzIEE4IDE2 IDJBIDIxICAyNCBBRSAwOCAxMSA3OCBGMSBGMiAyMSA6IHcuLjMuLiohJC4uLnguLiENCjAw NjA6IEYwIDQyIDM4IENEIEYxIDU3IEY2IDI0ICBFRiA0QiAzRiA4RSBGRiA3MCBDNyAxQiA6 IC5COC4uVy4kLks/Li5wLi4NCjAwNzA6IEZDIEJFIEEwIEFDIDNEIEQzIDYyIEQ1ICAwNCAy MSBDQiBEQiBCQyBCQyBBRSBGNiA6IC4uLi49LmIuLiEuLi4uLi4NCjAwODA6IEZBIDU2IERF IEQ3IDYzIENDIDIyIEVEICBEMSAzQiA1NyA4QyA4QiA1OCAwQiA2NiA6IC5WLi5jLiIuLjtX Li5YLmYNCjAwOTA6IEJFIEZCIERFIEM3IDRGIDVEIDdDIENGICA1NiA0RCBDNCBDNyAxNiBE NiBGQSA0RSA6IC4uLi5PXXwuVk0uLi4uLk4NCjAwYTA6IEEyIDJGIEQ3IEE0IEJGIEQ5IDlC IEYzICAwMyAyQiAxMyA3NSA4QiAxNyBBMiBFMiA6IC4vLi4uLi4uLisudS4uLi4NCjAwYjA6 IDk2IEMzIEZEIDcxIEFDIDZBIDQxIDFBICA0QyBFMiBFNCAzQiAzRSA1RiBENSBENCA6IC4u LnEuakEuTC4uOz5fLi4NCjAwYzA6IDlGIDJGIEY1IEM2IDM0IDcxIEE0IEU3ICBGOSBBNCA5 RiA5RCBGRSBERCA2MyBBNyA6IC4vLi40cS4uLi4uLi4uYy4NCjAwZDA6IDY2IEQzIEM4IDkx IDVBIEE1IEVBIEM2ICBEMyA3MCBFMSA3NyAxQiAzQiA2MCAxRCA6IGYuLi5aLi4uLnAudy47 YC4NCjAwZTA6IEJBIEVCIDhBIDI0IEQyIERCIEE0IDc5ICA3RCBBQyA0RiAzNyA1NSBCMSAw QyAyMCA6IC4uLiQuLi55fS5PN1UuLiANCjAwZjA6IDBCIEJBIDI2IEJFIERCIEM2IEY5IDJF ICAyOCA2NSAyOCBFNyBEOCA3NCA2MyBBNSA6IC4uJi4uLi4uKGUoLi50Yy4NCjAxMDA6IDND IEYzIERCIDBEIDFEIDNGIDEyIDBGICAxRSA1QSAxNiAwOCA0QSA1RCA4QiA4MyA6IDwuLi4u Py4uLlouLkpdLi4NCjAxMTA6IDQ0IDVBIEY4IDA3IDAyIDNDIDExIDZGICBENyA1NiBGOCA1 OSBEMCBDNyBBQSAwQiA6IERaLi4uPC5vLlYuWS4uLi4NCjAxMjA6IDdFIDAwIDUxIDIwIDAx IEQ3IDNCIEREICAzMSAxRCA1MCAwQSBBRCBBMSA2NCBCQiA6IH4uUSAuLjsuMS5QLi4uZC4N CjAxMzA6IEQzIDI1IERBIDZGIDM0IDQ1IDA2IDU0ICA4NSBERSBCOCA4NiAzMiBBQiBDRiBF NCA6IC4lLm80RS5ULi4uLjIuLi4NCjAxNDA6IDAyIDQ3IDBFIDNGIDU5IDNCIDcwIDY2ICA5 RCBGNyAzNyBDQyA1MCBFOCBFMyA1OCA6IC5HLj9ZO3BmLi43LlAuLlgNCjAxNTA6IERDIDU1 IDA0IDIxIEQ5IEE2IERDIEEyICAxRSBDNSBFNCA5OSA1OCAwMiAzMCBDNiA6IC5VLiEuLi4u Li4uLlguMC4NCjAxNjA6IEQ5IDc1IDJDIEI2IERCIDI2IDZFIDExICA4QSA4NCA2NCA0MSBE RiBERCA4OSBEQiA6IC51LC4uJm4uLi5kQS4uLi4NCjAxNzA6IEI2IEVCIEFGIDNEICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6IC4uLj0NCltsaWJzc2gyXSAwLjc3 MjE5OCBUcmFuc3BvcnQ6IExvb2tpbmcgZm9yIHBhY2tldCBvZiB0eXBlOiA1Mg0KW2xpYnNz aDJdIDAuNzcyMjAxIFRyYW5zcG9ydDogTG9va2luZyBmb3IgcGFja2V0IG9mIHR5cGU6IDUx DQpbbGlic3NoMl0gMC43NzIyMDQgVHJhbnNwb3J0OiBMb29raW5nIGZvciBwYWNrZXQgb2Yg dHlwZTogNjANCltsaWJzc2gyXSAwLjc3MjIxMiBTb2NrZXQ6IFJlY3ZlZCAzNi8xNjM4NCBi eXRlcyB0byAweDliYzBlOCswDQo9PiBsaWJzc2gyX3RyYW5zcG9ydF9yZWFkKCkgcmF3ICgz NiBieXRlcykNCjAwMDA6IDkwIDBBIEIzIDFEIDJFIERCIDc3IEQ0ICA4QSA3MSBFOCA5QyBF NSBEQyBBOCBERiA6IC4uLi4uLncuLnEuLi4uLi4NCjAwMTA6IDI3IEE0IDc4IENGIDg5IDMx IEUzIEI5ICAyNiA2NSAwOSAyOCAxNiAxMSBFNyBDRCA6ICcueC4uMS4uJmUuKC4uLi4NCjAw MjA6IDk1IEZFIENDIENEICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6 IC4uLi4NCj0+IGxpYnNzaDJfdHJhbnNwb3J0X3JlYWQoKSBwbGFpbiAoNSBieXRlcykNCjAw MDA6IDAzIDAwIDAwIDAwIDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6 IC4uLi4uDQpbbGlic3NoMl0gMC43NzIyMzcgVHJhbnNwb3J0OiBQYWNrZXQgdHlwZSAzIHJl Y2VpdmVkLCBsZW5ndGg9NQ0KY2FwZS1zc2hkOiBwYWNrZXQuYzo1Mjc6IF9saWJzc2gyX3Bh Y2tldF9hZGQ6IEFzc2VydGlvbiBgMCcgZmFpbGVkLg0KQWJvcnRlZCAoY29yZSBkdW1wZWQp DQobXTA7c2Rha2VAYmVhc3Q6L2hvbWUvc2Rha2UvcmVwb3MvcGFjZW1ha2VyLWNsb3VkL3Ny Ywdbcm9vdEBiZWFzdCBzcmNdIyBleGl0DQpleGl0DQoKU2NyaXB0IGRvbmUgb24gVGh1IDAx IE1hciAyMDEyIDExOjI5OjA5IEFNIE1TVAo= --------------090105020407080504030702 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --------------090105020407080504030702-- From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 20:21:01 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21JKun4017889; Thu, 1 Mar 2012 20:21:01 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q21JKstC017885 for ; Thu, 1 Mar 2012 20:20:54 +0100 Received: (qmail 2889 invoked by uid 501); 1 Mar 2012 19:20:56 -0000 Message-ID: <20120301192056.2888.qmail@stuge.se> Date: Thu, 1 Mar 2012 20:20:55 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F4FC046.6050004@redhat.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Steven Dake wrote: > >> I was getting 1 or 2 3's and thousands of 82s in a 12 hour run. > >> The 82s were in response to the keep alive, not sure what > >> triggered the 3s. > > > > So run with full tracing enabled and stop when you see a 3 packet. I cut the start of the trace. > [libssh2] 0.717236 Transport: Requesting userauth service > => libssh2_transport_write plain (17 bytes) > 0000: 05 00 00 00 0C 73 73 68 2D 75 73 65 72 61 75 74 : .....ssh-useraut > 0010: 68 : h > [libssh2] 0.717281 Socket: Sent 52/52 bytes at 0x9c0128 > => libssh2_transport_write send() (52 bytes) > 0000: 1C A5 D1 20 B4 FB 41 AB 34 9E 16 FD 21 1C AB 12 : ... ..A.4...!... > 0010: DE 3F 46 05 6F BB 4B 85 35 CC 19 2C C6 27 28 8D : .?F.o.K.5..,.'(. > 0020: 82 EE 5B 19 B7 92 E3 40 C3 AF F8 3A F6 E4 27 62 : ..[....@...:..'b > 0030: 24 68 F2 C6 : $h.. > [libssh2] 0.717299 Transport: Looking for packet of type: 6 > [libssh2] 0.767461 Socket: Recved 52/16384 bytes to 0x9bc0e8+0 > => libssh2_transport_read() raw (52 bytes) > 0000: 3D 54 C7 23 36 70 0B AA 74 E4 2B F0 63 D1 9D B8 : =T.#6p..t.+.c... > 0010: D6 D5 43 7D 9B 04 18 03 79 3C D5 3D F0 08 16 11 : ..C}....y<.=.... > 0020: 7C 2B AC DD 03 C3 7E 2C 13 72 04 C5 12 0E 46 B3 : |+....~,.r....F. > 0030: EE B4 89 F7 : .... > => libssh2_transport_read() plain (17 bytes) > 0000: 06 00 00 00 0C 73 73 68 2D 75 73 65 72 61 75 74 : .....ssh-useraut > 0010: 68 : h > [libssh2] 0.767573 Transport: Packet type 6 received, length=17 > [libssh2] 0.767579 Transport: Looking for packet of type: 6 Up until here there's no surprise. > => libssh2_transport_write plain (27 bytes) > 0000: 50 00 00 00 15 6B 65 65 70 61 6C 69 76 65 40 6C : P....keepalive@l > 0010: 69 62 73 73 68 32 2E 6F 72 67 00 : ibssh2.org. > [libssh2] 0.767635 Socket: Sent 68/68 bytes at 0x9c0128 > => libssh2_transport_write send() (68 bytes) > 0000: DC 4B 03 4D D6 24 FB 86 84 81 CE 96 CB 73 28 C3 : .K.M.$.......s(. > 0010: 62 2F 77 2B 28 47 B3 85 57 82 83 89 48 9A 4B 2C : b/w+(G..W...H.K, > 0020: F7 CB A6 EF 94 E9 AA 5B CA 7C 4F B9 49 09 7B FC : .......[.|O.I.{. > 0030: DF 22 C0 7C 0D A5 3B CF 72 C6 E1 95 0B 23 66 AB : .".|..;.r....#f. > 0040: 79 E9 46 14 : y.F. Here, libssh2 sends a SSH_MSG_GLOBAL_REQUEST. "Note that both the client and server MAY send global requests at any time, and the receiver MUST respond appropriately." Taking apart the packet: 50 = SSH_MSG_GLOBAL_REQUEST request name = 21 bytes "keepalive@libssh2.org" want reply = 0 "The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is TRUE." So there should be no response, and libssh2 moves on. > [libssh2] 0.767690 Userauth: Loading public key file: /var/lib/pacemaker-cloud/keys/assy-wordpress-mysql-F16.pub > [libssh2] 0.771962 Userauth: Attempting publickey authentication > => libssh2_transport_write plain (335 bytes) > 0000: 32 00 00 00 04 72 6F 6F 74 00 00 00 0E 73 73 68 : 2....root....ssh > 0010: 2D 63 6F 6E 6E 65 63 74 69 6F 6E 00 00 00 09 70 : -connection....p > 0020: 75 62 6C 69 63 6B 65 79 00 00 00 00 07 73 73 68 : ublickey.....ssh > 0030: 2D 72 73 61 00 00 01 17 00 00 00 07 73 73 68 2D : -rsa........ssh- > 0040: 72 73 61 00 00 00 03 01 00 01 00 00 01 01 00 AD : rsa............. > 0050: 32 B0 7F 2D 20 7A 09 3B 8B CE 62 3D 4F 3D EC D4 : 2..- z.;..b=O=.. > 0060: EC 78 C3 12 E2 B3 29 FF B5 40 2D 57 23 DF 4F 14 : .x....)..@-W#.O. > 0070: 78 8F 96 F4 3B 9F 50 B6 DF D5 CF 26 39 99 70 D2 : x...;.P....&9.p. > 0080: 4B 03 5C CA 0E D9 F4 3F 4C 56 68 F1 1F C4 93 08 : K.\....?LVh..... > 0090: C8 72 1C EF 4B DD 58 88 55 13 04 26 4C 0B 2D 78 : .r..K.X.U..&L.-x > 00a0: D0 A5 1F 60 34 AF A2 C7 D4 78 31 A1 9C A2 9C F1 : ...`4....x1..... > 00b0: 89 4A 09 86 8C 07 EC C5 3D 72 02 E9 FB 97 F0 E5 : .J......=r...... > 00c0: 08 B3 17 43 94 97 E9 46 8B 59 72 40 82 84 94 1A : ...C...F.Yr@.... > 00d0: FD 41 C4 57 BA E6 10 17 05 9B 45 22 84 77 F0 47 : .A.W......E".w.G > 00e0: 41 46 7F 6B 17 39 2F 43 7C 1B FB 48 DA 92 CF 51 : AF.k.9/C|..H...Q > 00f0: 4D 15 C3 8C EF FC 12 BA 22 F0 28 45 3F C9 45 90 : M.......".(E?.E. > 0100: C8 D5 17 3D 50 A2 DB B7 0C 64 4B AD 72 9B D9 10 : ...=P....dK.r... > 0110: 48 51 D8 CC B8 12 10 5C B0 F1 F4 CC 37 CE 40 BF : HQ.....\....7.@. > 0120: 66 19 F2 98 EE B5 08 57 7A AA 09 E9 A5 A3 05 CB : f......Wz....... > 0130: DD 40 9D F3 69 53 91 50 FF 83 F4 50 13 C0 45 CF : .@..iS.P...P..E. > 0140: B3 37 DB 51 B0 DE 0D 6E 53 DB 47 23 19 87 7B : .7.Q...nS.G#..{ > [libssh2] 0.772107 Socket: Sent 372/372 bytes at 0x9c0128 > => libssh2_transport_write send() (372 bytes) > 0000: 53 41 16 2A 93 65 AC 8D 39 F7 98 09 73 DB 53 79 : SA.*.e..9...s.Sy > 0010: 87 E8 37 9D 0C 47 3C F5 FB E4 45 0E 46 7A 8C 97 : ..7..G<...E.Fz.. > 0020: 8A B5 1B 0C 30 AB A0 A1 CF 5B DF 13 54 7C 97 6F : ....0....[..T|.o > 0030: 0A 21 05 E3 A9 94 BC 79 EF 38 78 EE 06 13 51 24 : .!.....y.8x...Q$ > 0040: 1B 08 EE A4 28 45 E0 EF BE 09 4E DE 5E 9C EA DD : ....(E....N.^... > 0050: 77 17 1F 33 A8 16 2A 21 24 AE 08 11 78 F1 F2 21 : w..3..*!$...x..! > 0060: F0 42 38 CD F1 57 F6 24 EF 4B 3F 8E FF 70 C7 1B : .B8..W.$.K?..p.. > 0070: FC BE A0 AC 3D D3 62 D5 04 21 CB DB BC BC AE F6 : ....=.b..!...... > 0080: FA 56 DE D7 63 CC 22 ED D1 3B 57 8C 8B 58 0B 66 : .V..c."..;W..X.f > 0090: BE FB DE C7 4F 5D 7C CF 56 4D C4 C7 16 D6 FA 4E : ....O]|.VM.....N > 00a0: A2 2F D7 A4 BF D9 9B F3 03 2B 13 75 8B 17 A2 E2 : ./.......+.u.... > 00b0: 96 C3 FD 71 AC 6A 41 1A 4C E2 E4 3B 3E 5F D5 D4 : ...q.jA.L..;>_.. > 00c0: 9F 2F F5 C6 34 71 A4 E7 F9 A4 9F 9D FE DD 63 A7 : ./..4q........c. > 00d0: 66 D3 C8 91 5A A5 EA C6 D3 70 E1 77 1B 3B 60 1D : f...Z....p.w.;`. > 00e0: BA EB 8A 24 D2 DB A4 79 7D AC 4F 37 55 B1 0C 20 : ...$...y}.O7U.. > 00f0: 0B BA 26 BE DB C6 F9 2E 28 65 28 E7 D8 74 63 A5 : ..&.....(e(..tc. > 0100: 3C F3 DB 0D 1D 3F 12 0F 1E 5A 16 08 4A 5D 8B 83 : <....?...Z..J].. > 0110: 44 5A F8 07 02 3C 11 6F D7 56 F8 59 D0 C7 AA 0B : DZ...<.o.V.Y.... > 0120: 7E 00 51 20 01 D7 3B DD 31 1D 50 0A AD A1 64 BB : ~.Q ..;.1.P...d. > 0130: D3 25 DA 6F 34 45 06 54 85 DE B8 86 32 AB CF E4 : .%.o4E.T....2... > 0140: 02 47 0E 3F 59 3B 70 66 9D F7 37 CC 50 E8 E3 58 : .G.?Y;pf..7.P..X > 0150: DC 55 04 21 D9 A6 DC A2 1E C5 E4 99 58 02 30 C6 : .U.!........X.0. > 0160: D9 75 2C B6 DB 26 6E 11 8A 84 64 41 DF DD 89 DB : .u,..&n...dA.... > 0170: B6 EB AF 3D : ...= Then libssh2 sends SSH_MSG_USERAUTH_REQUEST.. > [libssh2] 0.772198 Transport: Looking for packet of type: 52 > [libssh2] 0.772201 Transport: Looking for packet of type: 51 > [libssh2] 0.772204 Transport: Looking for packet of type: 60 > [libssh2] 0.772212 Socket: Recved 36/16384 bytes to 0x9bc0e8+0 > => libssh2_transport_read() raw (36 bytes) > 0000: 90 0A B3 1D 2E DB 77 D4 8A 71 E8 9C E5 DC A8 DF : ......w..q...... > 0010: 27 A4 78 CF 89 31 E3 B9 26 65 09 28 16 11 E7 CD : '.x..1..&e.(.... > 0020: 95 FE CC CD : .... > => libssh2_transport_read() plain (5 bytes) > 0000: 03 00 00 00 04 : ..... > [libssh2] 0.772237 Transport: Packet type 3 received, length=5 ..and gets back SSH_MSG_UNIMPLEMENTED. It looks like your server has a problem. To debug further, you could add a wait for SSH_MSG_UNIMPLEMENTED after sending keepalive with want reply = 0, and see what happens. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 21:43:37 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21KhISJ018529; Thu, 1 Mar 2012 21:43:33 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21KhGrt018520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Mar 2012 21:43:17 +0100 Received: from home.hno.se (home.hno.se [IPv6:2001:470:df90::1]) (authenticated bits=128) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q21KhG96019579 for ; Thu, 1 Mar 2012 20:43:18 GMT Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by home.hno.se (8.14.5/8.14.5) with ESMTP id q21KhENA007671 for ; Thu, 1 Mar 2012 21:43:14 +0100 Message-ID: <1330634594.3159.8.camel@home.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Thu, 01 Mar 2012 21:43:14 +0100 In-Reply-To: <20120301192056.2888.qmail@stuge.se> References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on home.hno.se X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Thu, 01 Mar 2012 20:43:18 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se tor 2012-03-01 klockan 20:20 +0100 skrev Peter Stuge: > To debug further, you could add a wait for SSH_MSG_UNIMPLEMENTED > after sending keepalive with want reply = 0, and see what happens. Why isn't there sequence number in the debug output? Confuses things a bit. The SSH_MSG_UNIMPLEMENTED is in response to the packet with seqno 4 (fifth packet), which is the keep-alive sent before authentication. Note that SSH_MSG_UNIMPLEMENTED should be sent in response to unimplemented messages even if want_reply == 0. want_reply is a message specific flag, not part of transport. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 21:48:11 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21Km9aI022280; Thu, 1 Mar 2012 21:48:10 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21Km6Jo022176 for ; Thu, 1 Mar 2012 21:48:07 +0100 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q21Km2do013660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Mar 2012 15:48:02 -0500 Received: from beast.broked.org ([10.3.112.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q21Km1wv004208; Thu, 1 Mar 2012 15:48:02 -0500 Message-ID: <4F4FE027.4020704@redhat.com> Date: Thu, 01 Mar 2012 13:46:31 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> In-Reply-To: <1330634594.3159.8.camel@home.hno.se> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: =?ISO-8859-1?Q?Henrik_Nordstr=F6m?= X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q21Km9aI022280 On 03/01/2012 01:43 PM, Henrik Nordström wrote: > tor 2012-03-01 klockan 20:20 +0100 skrev Peter Stuge: > >> To debug further, you could add a wait for SSH_MSG_UNIMPLEMENTED >> after sending keepalive with want reply = 0, and see what happens. > > Why isn't there sequence number in the debug output? Confuses things a > bit. > > The SSH_MSG_UNIMPLEMENTED is in response to the packet with seqno 4 > (fifth packet), which is the keep-alive sent before authentication. > > Note that SSH_MSG_UNIMPLEMENTED should be sent in response to > unimplemented messages even if want_reply == 0. want_reply is a message > specific flag, not part of transport. > Thanks I'll give sending the keepalive until after auth finishes a go Regards -steve > Regards > Henrik > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 22:36:16 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21La3fu024255; Thu, 1 Mar 2012 22:36:13 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21La2Du024126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Mar 2012 22:36:02 +0100 Received: from home.hno.se (home.hno.se [IPv6:2001:470:df90::1]) (authenticated bits=128) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q21La2AW008157 for ; Thu, 1 Mar 2012 21:36:03 GMT Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by home.hno.se (8.14.5/8.14.5) with ESMTP id q21LZwJU013390 for ; Thu, 1 Mar 2012 22:35:58 +0100 Message-ID: <1330637758.3159.26.camel@home.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Thu, 01 Mar 2012 22:35:58 +0100 In-Reply-To: <4F4FE027.4020704@redhat.com> References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <4F4FE027.4020704@redhat.com> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on home.hno.se X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Thu, 01 Mar 2012 21:36:03 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Regarding the patch to ignore SSH_MSG_UNIMPLEMENETD. While the patch and reference to 4253 section 11.4 is clearly wrong for the reasons detaled befire I think it may still be applied but with a slight addition of debug messages alerting that the error was received. This because there currently is no clean way to map SSH_MSG_UNIMPLEMENTED back to the calling request. It's a kind of special beast which libssh2 isn't quite prepared to handle in it's current shape. We need to track sequence numbers a bit to handle this proper as it's the only way to know which packet failed in a chain of otherwise unanswered packets. Or perhaps we should handle SSH_MSG_UNIMPLEMENTED as a fatal error terminating the session? REgards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 22:39:02 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21Ld0nn026089; Thu, 1 Mar 2012 22:39:01 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q21Lcx4B026080 for ; Thu, 1 Mar 2012 22:38:59 +0100 Received: (qmail 13344 invoked by uid 501); 1 Mar 2012 21:39:00 -0000 Message-ID: <20120301213900.13343.qmail@stuge.se> Date: Thu, 1 Mar 2012 22:39:00 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1330634594.3159.8.camel@home.hno.se> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q21Ld0nn026089 Henrik Nordström wrote: > The SSH_MSG_UNIMPLEMENTED is in response to the packet with seqno 4 > (fifth packet), which is the keep-alive sent before authentication. > > Note that SSH_MSG_UNIMPLEMENTED should be sent in response to > unimplemented messages even if want_reply == 0. want_reply is a > message specific flag, not part of transport. I don't know. I think SSH_MSG_UNIMPLEMENTED would only be acceptable if the server does not implement SSH_MSG_GLOBAL_REQUEST at all. (It might not, it's only used for setup and cancelling of tcpip-forward. An easy way out for libssh2 could be to set want reply = 1 for keepalive and require either SSH_MSG_UNIMPLEMENTED, SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE in response - but if the global request is sent after something else has been sent, but before response has been received, there is still a problem. This might already be managed within libssh2 though, that keepalives are never sent in the middle of another request. I don't think an SSH client can allow itself to send a global request with want reply = 0 if it is not already sure that the server supports that particular request, unless the client adds some elaborate buffering of global requests it has sent and tries to track which ones have been answered by the server. Not what we want. I think want reply = 1 for keepalive would be fine, and isolates the problem to that part of the code. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 23:09:00 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21M8otw016022; Thu, 1 Mar 2012 23:08:59 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21M8m19015958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Mar 2012 23:08:49 +0100 Received: from home.hno.se (home.hno.se [IPv6:2001:470:df90::1]) (authenticated bits=128) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q21M8l1A032656 for ; Thu, 1 Mar 2012 22:08:50 GMT Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by home.hno.se (8.14.5/8.14.5) with ESMTP id q21M8khZ015769 for ; Thu, 1 Mar 2012 23:08:46 +0100 Message-ID: <1330639726.3159.46.camel@home.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Thu, 01 Mar 2012 23:08:46 +0100 In-Reply-To: <20120301213900.13343.qmail@stuge.se> References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on home.hno.se X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Thu, 01 Mar 2012 22:08:50 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se tor 2012-03-01 klockan 22:39 +0100 skrev Peter Stuge: > This > might already be managed within libssh2 though, that keepalives are > never sent in the middle of another request. In blocking mode keepalives are by default sent in the middle of other requests by _libssh2_wait_socket. And applications is very likely to do use libss2_keepalive_send in similar manner in non-blocking mode. Also be warned that libssh2_keepalive_send corrupts transport if only part of the keep-alive message can be sent. > I don't think an SSH client can allow itself to send a global request > with want reply = 0 if it is not already sure that the server > supports that particular request, unless the client adds some > elaborate buffering of global requests it has sent and tries to track > which ones have been answered by the server. Not what we want. You only need to track the sequence number of the pending packets you currently expect a response to. Getting UNIMPLEMENTED as response to a packet you are not expecting a response to can safely be ignored I think. It's not really about global requests as such. You may in theory see UNIMPLEMENTED as response to any packet. In this specific case it's seen because global channel requests (keep-alive) are sent before the connection protocol is activated. > I think want reply = 1 for keepalive would be fine, and isolates the > problem to that part of the code. Not really without also making keep-alives a round-trip blocking thing preventing any concurrent unanswered packets of any kind during the keep-alive probe, which I am sure is not fine. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 1 23:37:21 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q21MbFwj002125; Thu, 1 Mar 2012 23:37:20 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q21MbDdW002120 for ; Thu, 1 Mar 2012 23:37:14 +0100 Received: (qmail 17786 invoked by uid 501); 1 Mar 2012 22:37:15 -0000 Message-ID: <20120301223715.17785.qmail@stuge.se> Date: Thu, 1 Mar 2012 23:37:15 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <1330639726.3159.46.camel@home.hno.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1330639726.3159.46.camel@home.hno.se> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q21MbFwj002125 Henrik Nordström wrote: > > This might already be managed within libssh2 though, that > > keepalives are never sent in the middle of another request. > > In blocking mode keepalives are by default sent in the middle of other > requests by _libssh2_wait_socket. > > And applications is very likely to do use libss2_keepalive_send in > similar manner in non-blocking mode. I see. Then the code that receives packets must be changed to take care of those responses as well. > Also be warned that libssh2_keepalive_send corrupts transport if > only part of the keep-alive message can be sent. Good fun. > You only need to track the sequence number of the pending packets > you currently expect a response to. And all previous packets which have not yet been responded to. The problem is that sending anything with want reply = 0 means that no response is expected, yet there is one. > Getting UNIMPLEMENTED as response to a packet you are not expecting > a response to can safely be ignored I think. It depends on what the packet was, but all sent packets which could possibly return UNIMPL would have to be recorded, if UNIMPL sent by the server out of the blue can be distinguished from actual responses. If that does not matter, then simply ignoring UNIMPL always works too. > It's not really about global requests as such. You may in theory > see UNIMPLEMENTED as response to any packet. Sure, but not all packets have a want reply field. If want reply = 0 it will be not very nice for libssh2 to have to keep track of the packet anyway because maybe there will be a response. > In this specific case it's seen because global channel requests > (keep-alive) are sent before the connection protocol is activated. The keepalive is a global request, unrelated to any channel, it only lives inside the session. "Note that both the client and server MAY send global requests at any time" so it's fine to send it also before userauth is completed. > > I think want reply = 1 for keepalive would be fine, and isolates > > the problem to that part of the code. > > Not really without also making keep-alives a round-trip blocking > thing preventing any concurrent unanswered packets of any kind > during the keep-alive probe, I was hoping that they already were sent without other outstanding packets, but since they are not, the only other easy fix I can think of is to always ignore UNIMPLEMENTED in _libssh2_packet_requirev(). //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 03:27:26 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q222R45u009237; Fri, 2 Mar 2012 03:27:22 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q222R0qp008555 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Mar 2012 03:27:01 +0100 Received: by iahk25 with SMTP id k25so1981150iah.41 for ; Thu, 01 Mar 2012 18:26:55 -0800 (PST) Received-SPF: pass (google.com: domain of xmitchx@gmail.com designates 10.50.182.197 as permitted sender) client-ip=10.50.182.197; Authentication-Results: mr.google.com; spf=pass (google.com: domain of xmitchx@gmail.com designates 10.50.182.197 as permitted sender) smtp.mail=xmitchx@gmail.com; dkim=pass header.i=xmitchx@gmail.com Received: from mr.google.com ([10.50.182.197]) by 10.50.182.197 with SMTP id eg5mr252681igc.36.1330655215106 (num_hops = 1); Thu, 01 Mar 2012 18:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=sTVKbiq/qO0biPROoxEznamrnjiP3WPK2BAfRLK5Skc=; b=esuQwXqAUokSxML53jzlrBRDz+SBjGfOj93OcOPEe1PI7p0q0zd9DsK/H7Np4ONrNn 34ifx+r+r+XWDWt/KXoPCY2RA9nqCdFlSQLjCvPajNv7b+RseITgekuBCmneRXGvTNUV PaTbnMt9LGMv9LoLTjJSj7pWtUUh0VI70lonlJK7DlP2kIQGNOUceJKkj4Jzhiz29GT9 I+GxbQuxS6rERRNmNZL2OE7bvh5O2fDNukd7ThyBguzOPoaU4QeD0E7RTr3+J59UWiJv P7yoFhF63yU4McnOiovmq4JbqpoAfh26oZ895JUN1l50dVE2l9BYOT7dG1scjhFqbrF8 EDxg== Received: by 10.50.182.197 with SMTP id eg5mr215691igc.36.1330655215045; Thu, 01 Mar 2012 18:26:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Thu, 1 Mar 2012 18:26:34 -0800 (PST) In-Reply-To: <20120301034227.14151.qmail@stuge.se> References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> From: Mitchell Hashimoto Date: Thu, 1 Mar 2012 18:26:34 -0800 X-Google-Sender-Auth: wYlwIrXdWTbo0nbkM2tz4jM0omE Message-ID: Subject: Re: Callback for channel data ready To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1481090576==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============1481090576== Content-Type: multipart/alternative; boundary=14dae9340ac9694afc04ba394f52 --14dae9340ac9694afc04ba394f52 Content-Type: text/plain; charset=ISO-8859-1 Peter, On Wed, Feb 29, 2012 at 7:42 PM, Peter Stuge wrote: > Hi Mitchell, > > Mitchell Hashimoto wrote: > > > > but I was hoping perhaps there was a better way? > > > > > > Sorry not at this time. I think we want callbacks though, so feel > > > free to discuss and send patches. :) > > > > Understood. Thanks. > > > > I haven't been using libssh2 long enough to feel comfortable enough > > in suggesting API improvements, since I haven't quite immersed > > myself in the "libssh2 way." > > There is no such thing.. libssh2 has evolved, and must continue to > evolve. The libssh2 API can and should be expanded to become more > useful, and the definition of useful should basically come from it's > users. > > > > But I agree that callbacks would be fantastic. > > So how would that work? > Haha! I can appreciate that point of view. I suppose now that I think about it, a callback would be somewhat difficult, since the client controls the sockets. So even though ideally in my head libssh2 would tell me when I should read, I understand that is not really feasible. Instead, I believe it would be nice to do something like the following: int libssh2_session_ready_channels(LIBSSH2_SESSION *, LIBSSH2_CHANNEL **) Where this would return a LIBSSH2_ERROR_EAGAIN if the socket would block when nonblocking is on, and the return value would basically behave just like any other libssh2 call. It would return `0` when it was a success. Normal libssh2 behavior. If 0 is returned, then the second parameter is set to a pointer to a single channel that is ready to be read, or NULL if none are ready. This would allow this sort of behavior: int rc = 0; LIBSSH2_CHANNEL *channel = NULL; while ((rc = libssh2_session_ready_channels(sess, &channel)) == 0 && channel != NULL) { // Read from `channel` } Again, like I said, I don't know the internal structure of libssh2 or the feasibility of such a thing, but I can see looping through channels to become overwhelming. What do you think? Best, Mitchell > > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > --14dae9340ac9694afc04ba394f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peter,

On Wed, Feb 29, 2012 at 7:42 PM, P= eter Stuge <peter@st= uge.se> wrote:
Hi Mitchell,

Mitchell Hashimoto wrote:
> > > but I was hoping perhaps there was a better way?
> >
> > Sorry not at this time. I think we want callbacks though, so feel=
> > free to discuss and send patches. :)
>
> Understood. Thanks.
>
> I haven't been using libssh2 long enough to feel comfortable enoug= h
> in suggesting API improvements, since I haven't quite immersed
> myself in the "libssh2 way."

There is no such thing.. libssh2 has evolved, and must continue to evolve. The libssh2 API can and should be expanded to become more
useful, and the definition of useful should basically come from it's users.


> But I agree that callbacks would be fantastic.

So how would that work?

Haha! I c= an appreciate that point of view.

I suppose now th= at I think about it, a callback would be somewhat difficult, since the clie= nt controls the sockets. So even though ideally in my head libssh2 would te= ll me when I should read, I understand that is not really feasible.

Instead, I believe it would be nice to do something lik= e the following:

int libssh2_session_ready_channel= s(LIBSSH2_SESSION *, LIBSSH2_CHANNEL **)

Where thi= s would return a LIBSSH2_ERROR_EAGAIN if the socket would block when nonblo= cking is on, and the return value would basically behave just like any othe= r libssh2 call. It would return `0` when it was a success. Normal libssh2 b= ehavior. If 0 is returned, then the second parameter is set to a pointer to= a single channel that is ready to be read, or NULL if none are ready. This= would allow this sort of behavior:

int rc =3D 0;
LIBSSH2_CHANNEL *channel =3D NU= LL;
while ((rc =3D libssh2_session_ready_channels(sess, &chan= nel)) =3D=3D 0 && channel !=3D NULL) {
=A0 =A0 // Read fr= om `channel`
}

Again, like I said, I don't know the in= ternal structure of libssh2 or the=A0feasibility=A0of such a thing, but I c= an see looping through channels to become overwhelming.=A0

What do you think?

Best,
Mitchell
=A0


//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/li= bssh2-devel

--14dae9340ac9694afc04ba394f52-- --===============1481090576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============1481090576==-- From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 12:21:42 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22BLIw7001923; Fri, 2 Mar 2012 12:21:37 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22BLHhK001900 for ; Fri, 2 Mar 2012 12:21:18 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id 313F21F29F2 for ; Fri, 2 Mar 2012 12:21:18 +0100 (MET) Received: from localhost (it.got.cryptzone.com [172.24.4.4]) by krakatau.got.appgate.com (Postfix) with ESMTP id 0F980BD405F for ; Fri, 2 Mar 2012 12:21:18 +0100 (CET) Received: from 172.24.4.2 (SquirrelMail authenticated user tom) by localhost with HTTP; Fri, 2 Mar 2012 12:21:18 +0100 Message-ID: <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> In-Reply-To: References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> Date: Fri, 2 Mar 2012 12:21:18 +0100 Subject: Re: Callback for channel data ready From: "Tom Weber" To: "libssh2 development" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hi! These are my thoughts... > On Wed, Feb 29, 2012 at 7:42 PM, Peter Stuge wrote: >> > > Sorry not at this time. I think we want callbacks though, so feel >> > > free to discuss and send patches. :) Callbacks sound nice in theory, but I've had my share of them, wrestling with PuTTY and Symbian code, and particularly those two together, which have mostly incompatible callback schemes. The problem is that you as an application developer don't control the context in which the callback is called. 1) You might want to disconnect and free the session, but you can't do that since you have to return to a libssh2_session_ routine, which expects the session to be valid. 2) You might want to process the event later, and then you need an additional mechanism to save the event. 3) During which function call, and from which thread, can we count on the callback being called? We must know that exactly, to handle things like mutexes and resource ownership correctly. (Preferably the callback pointer should be provided at the function call and not saved, to make this more clear.) By the way, signals suffer from the same problems... >> There is no such thing.. libssh2 has evolved, and must continue to >> evolve. The libssh2 API can and should be expanded to become more >> useful, and the definition of useful should basically come from it's >> users. Agreed! :-) On Fri, March 2, 2012 03:26, Mitchell Hashimoto wrote: > Instead, I believe it would be nice to do something like the following: > > int libssh2_session_ready_channels(LIBSSH2_SESSION *, LIBSSH2_CHANNEL **) > > Where this would return a LIBSSH2_ERROR_EAGAIN if the socket would block > when nonblocking is on, and the return value would basically behave just > like any other libssh2 call. It would return `0` when it was a success. > Normal libssh2 behavior. If 0 is returned, then the second parameter is set > to a pointer to a single channel that is ready to be read, or NULL if none > are ready. I suppose that libssh2 maintains a queue of packets for various channels, and your proposed function would return the first item from the queue? Sounds good if you want to process all packets in order, but what if you want to skip some channels because their corresponding sockets are not ready to accept more data, and you want libssh2 to save the data for later, while blocking that channel? You might think, "why not save such data in a buffer instead?", but that's not the same thing. If you keep reading data which you can't send, libssh2 will adjust the window and accept more and more, and then you might run out of memory trying to buffer it all. > Again, like I said, I don't know the internal structure of libssh2 or > the feasibility of such a thing, but I can see looping through channels to > become overwhelming. Overwhelming? Well, the loop must be done in some way anyway inside the library. (I suppose that libssh2 maps from a channel ID to a struct pointer, and that might be a hash array lookup?) Again, see my point above about skipping channels which must be paused. One way would be to tell libssh2 that a particular channel shouldn't be checked. Another way would be to loop and check selectively. I'm quite happy with libssh2 as it is now, but I'd also like a nicer way to check a channel. Right now I have a helper routine which looks like this: static long _try_channel_read(... LIBSSH2_CHANNEL *channel) { long read_size; /* ugly kludge */ libssh2_session_set_blocking(session->ssh_session, 0); read_size = libssh2_channel_read(channel, session->io_buffer, session->io_buffer_capacity); ... /* ugly kludge */ libssh2_session_set_blocking(session->ssh_session, 1); return read_size; } -- Best regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 12:37:14 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Bb6Yu012366; Fri, 2 Mar 2012 12:37:14 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Bb4LA012306 for ; Fri, 2 Mar 2012 12:37:04 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id 7513B1F29F2 for ; Fri, 2 Mar 2012 12:37:05 +0100 (MET) Received: from localhost (it.got.cryptzone.com [172.24.4.4]) by krakatau.got.appgate.com (Postfix) with ESMTP id 4BCB2BD4054 for ; Fri, 2 Mar 2012 12:37:05 +0100 (CET) Received: from 172.24.4.2 (SquirrelMail authenticated user tom) by localhost with HTTP; Fri, 2 Mar 2012 12:37:05 +0100 Message-ID: <6aa7708e61ba11ccff5b7aa7f72d0250.squirrel@localhost> In-Reply-To: <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> Date: Fri, 2 Mar 2012 12:37:05 +0100 Subject: Re: Callback for channel data ready ++ From: "Tom Weber" To: "libssh2 development" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Fri, March 2, 2012 12:21, Tom Weber wrote: > The problem is that you as an application developer don't control the context > in which the callback is called. > > 1) You might want to disconnect and free the session, but you can't do that > since you have to return to a libssh2_session_ routine, which expects the > session to be valid. > > 2) You might want to process the event later, and then you need an additional > mechanism to save the event. > > 3) During which function call, and from which thread, can we count on the > callback being called? We must know that exactly, to handle things like > mutexes and resource ownership correctly. (Preferably the callback pointer > should be provided at the function call and not saved, to make this more > clear.) 4) It's often unclear which functions are safe to call from a callback. (This is point 3 in reverse.) For instance, if I receive channel data in a callback, is it safe to send a reply from within the callback? To send data back on another channel? To change some session parameter? To start a new channel? Etc... -- Best regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 13:41:10 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22CeuJr031883; Fri, 2 Mar 2012 13:41:08 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Ces82031839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2012 13:40:55 +0100 Received: from home.hno.se (home.hno.se [IPv6:2001:470:df90::1]) (authenticated bits=128) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q22Ces60026598 for ; Fri, 2 Mar 2012 12:40:55 GMT Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by home.hno.se (8.14.5/8.14.5) with ESMTP id q22CeqkM011036 for ; Fri, 2 Mar 2012 13:40:52 +0100 Message-ID: <1330692052.1807.52.camel@home.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Fri, 02 Mar 2012 13:40:52 +0100 In-Reply-To: <20120301223715.17785.qmail@stuge.se> References: <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <1330639726.3159.46.camel@home.hno.se> <20120301223715.17785.qmail@stuge.se> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on home.hno.se X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Fri, 02 Mar 2012 12:40:55 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se tor 2012-03-01 klockan 23:37 +0100 skrev Peter Stuge: > > You only need to track the sequence number of the pending packets > > you currently expect a response to. > > And all previous packets which have not yet been responded to. The > problem is that sending anything with want reply = 0 means that no > response is expected, yet there is one. I argue that it's perfectly fine to ignore the error response if you do not expect a response. Please put want_reply aside for now. That's unique to GLOBAL_REQUEST packets, not general flag for SSH packets. The only thing it adds to this discussion is to show that the same packet type may or may not expect a response depending on it's content. > > Getting UNIMPLEMENTED as response to a packet you are not expecting > > a response to can safely be ignored I think. > > It depends on what the packet was, but all sent packets which could > possibly return UNIMPL would have to be recorded, if UNIMPL sent by > the server out of the blue can be distinguished from actual > responses. UNIMPLEMENTED responses are identified by the sequence number of the packet they respond to. > If that does not matter, then simply ignoring UNIMPL always works > too. Not when you expect a response. For example the case just discussed with a want_reply keep-alive request sent before connection service is active would hang if implemented right and UNIMPLEMENTED is ignored. > > It's not really about global requests as such. You may in theory > > see UNIMPLEMENTED as response to any packet. > > Sure, but not all packets have a want reply field. If want reply = 0 > it will be not very nice for libssh2 to have to keep track of the > packet anyway because maybe there will be a response. Yes. Have never said anything along those lines. Only the opposite, there is no need to track packets to which you do not expect a response. > > In this specific case it's seen because global channel requests > > (keep-alive) are sent before the connection protocol is activated. > > The keepalive is a global request, unrelated to any channel, it only > lives inside the session. "Note that both the client and server MAY > send global requests at any time" so it's fine to send it also before > userauth is completed. No it's not. The connection protocol needs to be activated first (SSH_MSG_SERVICE_REQUEST "ssh-connection"). You can not use connection protocol messages without the connection protocol active. > I was hoping that they already were sent without other outstanding > packets, but since they are not, the only other easy fix I can think > of is to always ignore UNIMPLEMENTED in _libssh2_packet_requirev(). Yes and is why I proposed that for now we should ignore and warn. Long term we probably need to deal with them, which requires keeping track of the sequence number of packets one expects a response to so the error can be correctly routed up the stack to the application. This requires a bit of changes in transport api to indicate if responses are expected or not when sending a packet to transport. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 14:27:09 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22DQs5A012585; Fri, 2 Mar 2012 14:27:04 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22DQrLE012558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2012 14:26:53 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q22DQr0A012552 for ; Fri, 2 Mar 2012 14:26:53 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 2 Mar 2012 14:26:53 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Callback for channel data ready In-Reply-To: Message-ID: References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, 1 Mar 2012, Mitchell Hashimoto wrote: > Instead, I believe it would be nice to do something like the following: > > int libssh2_session_ready_channels(LIBSSH2_SESSION *, LIBSSH2_CHANNEL **) (just quickly popping in while still away on vacation) This looks like a way I would prefer (since it would avoid callbacks and it would allow users to a large extent keep using the existing API). Possibly it could be made to return more than one channel so that the application can select in which order to handle them. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 16:14:04 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22FDic8020995; Fri, 2 Mar 2012 16:14:00 +0100 Received: from nm25-vm0.bullet.mail.sp2.yahoo.com (nm25-vm0.bullet.mail.sp2.yahoo.com [98.139.91.228]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q22FDfJH020933 for ; Fri, 2 Mar 2012 16:13:41 +0100 Received: from [98.139.91.67] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 15:13:35 -0000 Received: from [98.139.91.6] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 15:13:34 -0000 Received: from [127.0.0.1] by omp1006.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 15:13:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 964491.23612.bm@omp1006.mail.sp2.yahoo.com Received: (qmail 1597 invoked by uid 60001); 2 Mar 2012 15:13:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330701214; bh=w2HsdWawEgoafT13eKXHGgTqtxZIyUH/6X7IscMrNaY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=hVFB0Pe0muZHd0hrLa4XCq2ediGs5e82k7/udcBZpkwzRp9QTQCAJHKjuqo/8fX7m9fjQyOOquCRhM2E4ZCvlczs20UTgghRaKgJs6rl6KEAuVOYf6Z/OZbLFrZ0pC5DDZRozub2aSYz0tuMcTroEeFCIywLvh/NaLXYIc/acCQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=yzUtEVROOCUR8scpo4WTIz++obqYw+zAQ9h4VksWjmWfsQApqHLJo3uYUWkvrg/GaAdv9dKwy2QgYgM3dvYqtWtu8dnTr86zVhhfRE8ghkLKidYfLk+u431oG6y1GSdvahKTw+hQ89qRNgG6hzICwVz7YX987juE+t8DN1pCUJ0=; X-YMail-OSG: MYqI._EVM1kcU.izRfkl8KvMHJ6BTIFuR_.8sU78B7f2NFF D2m2FBnIGUzhhTEbaZFxwPwRbExdZvE2wW0gHrN9gk174s0tblygOx.jdsLS s8GzWiCEczJe5_ILCoNfC3udhlcfllqYPLN4L0XTFK3rrXWZzc6DKriyPGHI YDR9utrTDuKCkhOfCN_.9hVqDMeN0sR.ZUSFIFYK_drugPo2bQQkpJw6s_k0 EjN8Ggp6LMZsOHZJyoOSfrjoVbbhoXxj2LMk0H0osFbvtJiW_kZ.9lf1i_y3 1K7_lbClN33JerVhwtWLj37VOsdvxD3huXZclJRvV8wMyzgZG33S9MP_taq2 Hd1HzISlRI292w.vybDx8JlYau.R2aqpTy9jAYGFTLPzb7I5e2Clp23vacTP yYZF6O2D1HU_Si9VE9C9edKHMjv1Ie65cxh_y0LUDGgLtpGeXTCI094zuILp SAA-- Received: from [173.9.132.155] by web113308.mail.gq1.yahoo.com via HTTP; Fri, 02 Mar 2012 07:13:34 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1330701214.90318.YahooMailClassic@web113308.mail.gq1.yahoo.com> Date: Fri, 2 Mar 2012 07:13:34 -0800 (PST) From: Lawson Subject: INVALID_SOCKET symbol conflict To: libssh2-devel@cool.haxx.se MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hi, I notice that nearly all the defines in libssh2.h use the LIBSSH2_ prefix, except for INVALID_SOCKET. It seems to be on purpose but I don't understand why. Is it a Windows thing? My issue is that I'm writing an application (on Linux) which includes headers from multiple libraries, and some of them also set this symbol to a conflicting value. Any enlightenment is appreciated, TIA. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 16:14:05 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22FE45S021312; Fri, 2 Mar 2012 16:14:05 +0100 Received: from nm7.bullet.mail.sp2.yahoo.com (nm7.bullet.mail.sp2.yahoo.com [98.139.91.77]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q22FDkM3020970 for ; Fri, 2 Mar 2012 16:13:46 +0100 Received: from [98.139.91.66] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 15:13:41 -0000 Received: from [98.139.91.58] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 15:13:41 -0000 Received: from [127.0.0.1] by omp1058.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 15:13:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 391409.58905.bm@omp1058.mail.sp2.yahoo.com Received: (qmail 598 invoked by uid 60001); 2 Mar 2012 15:13:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330701220; bh=w2HsdWawEgoafT13eKXHGgTqtxZIyUH/6X7IscMrNaY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=1hq2qBOPBE+SMRKUgohmN1Sc6GuprQOb2JZuFWXveetixokBXyDqKdmP1dCoOag4A34BgXIRCJR/7lD5aOyeYq5RmpQA4WRYBpUb7Szg9M/ecPB6+3Q9vMsqm83+OrKNbGg734tT0fQsjWRjStxCAIYjZX+ow2f0I1PbMSZ3Dlo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=FcZnlH7mW+CKSrUOW2R2sxyIWu2yS3RTL+vImVBZoa7RgauldQPFfDGC3Ql1whnwmRe/JT2ZIR4a6ltz+1T+iNUfEbkxb90fFQ/6fbJJUz3eWGTWI6Ex5EI/heyDLE/DrNe+GLd4Nl/O7eQoN8HM9zH03+1VUqB2EErT52FZTms=; X-YMail-OSG: lkCiaO4VM1m4EGzgxXn.xvWHanUuGORh6tFeDfga5FMDe.8 e_oSydnpcM_MaXfaEP9SSptMPuEy56zwvx25E00.7Jzv7GYxMPQZ6t8yU8bU 4GPQMGdgK_WDGXbjfENN7TtRhQGMZA3WCeprxopEGF7etyOhTW_ZaTnUEqU0 vZHkNMCnVxi2q_dV.lyvNjfwpzXR307MDQXKtBltfv.Y2kuHtFTXLAiPt85t 7YF0Umn9qN4WGPmmPz15lTL9RkWlitvCE8nEBxCUsIQNXWKhvzh1Smfk1NLj 7rG98XNvH7P21rxuf8EOX.4F89X3q.dR1A5fNP1mu4BYQEDiDHSpl6kAVzoY wfojtISHQIEqU4qo_rlsYFPKdstVA80b8zrBieTuxd0RUgCJ86KE1rCqpfu4 tYmiIJahh4GLJP83lTmCHlmZn7iTSz3C5KuUQ_YKdN9KLxLBgsveOSnJ2BgT sWA-- Received: from [173.9.132.155] by web113312.mail.gq1.yahoo.com via HTTP; Fri, 02 Mar 2012 07:13:40 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1330701220.91472.YahooMailClassic@web113312.mail.gq1.yahoo.com> Date: Fri, 2 Mar 2012 07:13:40 -0800 (PST) From: Lawson Subject: INVALID_SOCKET symbol conflict To: libssh2-devel@cool.haxx.se MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hi, I notice that nearly all the defines in libssh2.h use the LIBSSH2_ prefix, except for INVALID_SOCKET. It seems to be on purpose but I don't understand why. Is it a Windows thing? My issue is that I'm writing an application (on Linux) which includes headers from multiple libraries, and some of them also set this symbol to a conflicting value. Any enlightenment is appreciated, TIA. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 16:44:12 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Fi2id015999; Fri, 2 Mar 2012 16:44:11 +0100 Received: from mail-qw0-f47.google.com (mail-qw0-f47.google.com [209.85.216.47]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Fhxks015896 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Mar 2012 16:44:00 +0100 Received: by qadz30 with SMTP id z30so278016qad.20 for ; Fri, 02 Mar 2012 07:43:55 -0800 (PST) Received-SPF: pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.111.142 as permitted sender) client-ip=10.224.111.142; Authentication-Results: mr.google.com; spf=pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.111.142 as permitted sender) smtp.mail=alexander.lamaison@gmail.com; dkim=pass header.i=alexander.lamaison@gmail.com Received: from mr.google.com ([10.224.111.142]) by 10.224.111.142 with SMTP id s14mr6858592qap.78.1330703035384 (num_hops = 1); Fri, 02 Mar 2012 07:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=t5R0WqSF0d1s4SJzBWi0H5a7zUtqVKLxlYPytFVJOks=; b=nemHFQKS8t0NurCZ4ZuxWWdP7pKru/oTkwd4JFpxW0vGyDkY8aZGTak75LFl6QnxxN Z6ZeQt9WzwTC5bUEzmLuujTMwLUCe/yG9TZdP2Xrfo17rwj9ksOw46h3ZQLXKFpZ+FMz 5BQLy8MhgbMkDqoIW699NuZ1bBTeUV0mWVIn0KGDymJtS1LE0l49ilg2s6/OKoHsreJT Nihs1RCFL3YkWmP+LbGcHbbqbdRNWUNNNSj4lZaabNpifbxA/LVOOKqzuByZhz+yhEPR GHfIa/444LATasaL3pbhMmY3J/s+JCYPuSfx0BlN7d98nH5Lyuei/OpxJQMirx6AWz+R p0rQ== MIME-Version: 1.0 Received: by 10.224.111.142 with SMTP id s14mr5752295qap.78.1330703035344; Fri, 02 Mar 2012 07:43:55 -0800 (PST) Received: by 10.229.144.211 with HTTP; Fri, 2 Mar 2012 07:43:55 -0800 (PST) In-Reply-To: <1330701220.91472.YahooMailClassic@web113312.mail.gq1.yahoo.com> References: <1330701220.91472.YahooMailClassic@web113312.mail.gq1.yahoo.com> Date: Fri, 2 Mar 2012 15:43:55 +0000 X-Google-Sender-Auth: ovH-yhXcmHY9PdZokKafoTk-PBM Message-ID: Subject: Re: INVALID_SOCKET symbol conflict From: Alexander Lamaison To: libssh2 development X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q22Fhxks015896 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q22Fi2id015999 On 2 March 2012 15:13, Lawson wrote: > > I notice that nearly all the defines in libssh2.h use the LIBSSH2_ prefix, except for INVALID_SOCKET.  It seems to be on purpose but I don't understand why.  Is it a Windows thing? It is a Windows Winsock constant that represents the only value returned by socket() that is guaranteed not to be a valid socket handle. libssh2 defines it in the header for other platforms to help with portable programming. > My issue is that I'm writing an application (on Linux) which includes headers from multiple libraries, and some of them also set this symbol to a conflicting value. I believe the difference is because on some platforms sockets are signed ints and others they are unsigned ints. Can you give more details about the conflict. Error messages etc. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 17:12:46 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22GCeIN012144; Fri, 2 Mar 2012 17:12:46 +0100 Received: from nm17.bullet.mail.sp2.yahoo.com (nm17.bullet.mail.sp2.yahoo.com [98.139.91.87]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q22GCbFo012022 for ; Fri, 2 Mar 2012 17:12:37 +0100 Received: from [98.139.91.70] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 16:12:32 -0000 Received: from [72.30.22.203] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 16:12:32 -0000 Received: from [127.0.0.1] by omp1065.mail.sp2.yahoo.com with NNFMP; 02 Mar 2012 16:12:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 613664.53358.bm@omp1065.mail.sp2.yahoo.com Received: (qmail 35941 invoked by uid 60001); 2 Mar 2012 16:12:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1330704752; bh=x7EaesVlGnBrg6NE2orQzuYw30P85RPTHLPmYe1C3cU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4P/M+ftZNWEsHdeb04+PdSr1L5m629FQITyVNcSy+PuHdOLpCS0FnNxQXFAyJniIu1hmGDvmRus7t5sFw2vCi8EWRCeO32o0gJd1s8RUNF8VEf27LJFeBfOTX9BoatluU9r1gRLtGUjOKuw96po5ZO6E6zdym+rEi/NdL3X1LDI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wB3oR1p5gd+7A5K4/Xw9dXY+etAThTWiYYAnGVtktdbyTOzmmHmITptVSpkTWrPAI0ZPsPsqwms3/BGC5zB6gQyXTrHBdyje7NvfQ0Vb8GA1OJYvABX8CG8+XP4jPC52Kpv26EkjoAMuG+7xVlYkSuAAwXjQ/x8NCrKuQnjtT/0=; X-YMail-OSG: lCRbz6EVM1neL0o95ncRnGPlwjN.9_miDn0m2ocG9qNBUH9 f3SCXk6e8klCJLEFRK4noVtDo_HtY3K.oi0AECntYo9.a7LIBdEGemDgTKiW 1AxXVJ6evKY4ir9mC_6KUFrCthXR3oYRFJpwZMjTuE8wCvZbx_bU_uGImYbZ YncqCbFxyxHaMIEHoDpcMpT6NRNJnkLzzIzRiFeow72ekWR.MXMsbEzT4DCa oa4vGr13Cf4wOrEmBklYPYBMgNTL2QpeFkA9jdiN_qlo65wGxExvDF8urzfn 9yt3cgYXqOgeTBGL5FlzwetMAJHlBzMjl0wYu01GEwOkyuDZCfnbLvg_nOHr 6eQIsh2THx3v1p0bbrawHIyjl_LN0mBM7H96RCJ7kWd0MiAt4.LHg0msmjEC cnRsHQBDIqpTQmTHAgILWsv3XKZ4Y37J.n6_MrWDn748SgGA84uhkus6DDth Qq15RaRMufCpAZA4F_OpFvJ0qw2PyXDrIHdbM33eqpSU2ayK3ogoDcEAMIrM 0yttN05bT4MCp6LScq3Pb7GpV6Ol4n7e3zyLM88PxvekKsWs1NTTdHnokYip fanKyMeY54ezlJGTYHWLBWpdFUpW3mA-- Received: from [173.9.132.155] by web113315.mail.gq1.yahoo.com via HTTP; Fri, 02 Mar 2012 08:12:32 PST X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1330704752.32354.YahooMailClassic@web113315.mail.gq1.yahoo.com> Date: Fri, 2 Mar 2012 08:12:32 -0800 (PST) From: Lawson Subject: Re: INVALID_SOCKET symbol conflict To: libssh2 development In-Reply-To: MIME-Version: 1.0 X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q22GCbFo012022 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q22GCeIN012144 Hi, Thanks for the prompt reply. The compile warning is: In file included from /usr/local/include/libssh2/libssh2.h:140:1: warning: "INVALID_SOCKET" redefined In file included from /usr/local/include/snmp_pp/snmp_pp.h:71, from snmpThreadData.h:13, from snmpThreadData.cpp:4: /usr/local/include/snmp_pp/uxsnmp.h:49:1: warning: this is the location of the previous definition So the conflict is I end up with headers both from libssh2 and the snmp++ library (http://www.agentpp.com/snmp_pp3_x/snmp_pp3_x.html). Libssh2 defines it as: #define INVALID_SOCKET -1 and SNMP++ defines it as: #ifndef INVALID_SOCKET #define INVALID_SOCKET ((SnmpSocket)(~0)) // value for invalid socket #endif Note that the SNMP++ header has an #ifdef. If I make the libssh2 come first, then the ifdef will stop it from being redefined... but it will be the wrong value (and type) for SNMP++. I'm sure I can craft a workaround. Mostly I was perplexed at why two different libraries which are otherwise both disciplined about defining their constants with a namespace prefix both chose to define this one symbol like this, like it was some magical special symbol that everyone knew about. - matt --- On Fri, 3/2/12, Alexander Lamaison wrote: > From: Alexander Lamaison > Subject: Re: INVALID_SOCKET symbol conflict > To: "libssh2 development" > Date: Friday, March 2, 2012, 7:43 AM > On 2 March 2012 15:13, Lawson > wrote: > > > > I notice that nearly all the defines in libssh2.h use > the LIBSSH2_ prefix, except for INVALID_SOCKET.  It seems > to be on purpose but I don't understand why.  Is it a > Windows thing? > > It is a Windows Winsock constant that represents the only > value > returned by socket() that is guaranteed not to be a valid > socket > handle.  libssh2 defines it in the header for other > platforms to help > with portable programming. > > > My issue is that I'm writing an application (on Linux) > which includes headers from multiple libraries, and some of > them also set this symbol to a conflicting value. > > I believe the difference is because on some platforms > sockets are > signed ints and others they are unsigned ints.  Can you > give more > details about the conflict.  Error messages etc. > > Alex > > -- > Easy SFTP for Windows Explorer (http://www.swish-sftp.org) > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 17:26:40 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22GQTFi025855; Fri, 2 Mar 2012 17:26:39 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q22GQR3w025810 for ; Fri, 2 Mar 2012 17:26:27 +0100 Received: (qmail 8218 invoked by uid 501); 2 Mar 2012 16:26:26 -0000 Message-ID: <20120302162626.8217.qmail@stuge.se> Date: Fri, 2 Mar 2012 17:26:26 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: INVALID_SOCKET symbol conflict Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1330701214.90318.YahooMailClassic@web113308.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1330701214.90318.YahooMailClassic@web113308.mail.gq1.yahoo.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Lawson wrote: > I notice that nearly all the defines in libssh2.h use the LIBSSH2_ > prefix, except for INVALID_SOCKET. It seems to be on purpose but I > don't understand why. Is it a Windows thing? Yep. > My issue is that I'm writing an application (on Linux) which > includes headers from multiple libraries, and some of them also set > this symbol to a conflicting value. They can't work on Windows then. The fix is of course to use LIBSSH2_INVALID_SOCKET. Please send a git patch which does the change, including the neccessary autoconf goo. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 17:27:55 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22GRrS8027176; Fri, 2 Mar 2012 17:27:55 +0100 Received: from mail-qy0-f170.google.com (mail-qy0-f170.google.com [209.85.216.170]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22GRphM027084 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Mar 2012 17:27:52 +0100 Received: by qcmt36 with SMTP id t36so793805qcm.15 for ; Fri, 02 Mar 2012 08:27:47 -0800 (PST) Received-SPF: pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.105.203 as permitted sender) client-ip=10.224.105.203; Authentication-Results: mr.google.com; spf=pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.105.203 as permitted sender) smtp.mail=alexander.lamaison@gmail.com; dkim=pass header.i=alexander.lamaison@gmail.com Received: from mr.google.com ([10.224.105.203]) by 10.224.105.203 with SMTP id u11mr6897348qao.77.1330705667273 (num_hops = 1); Fri, 02 Mar 2012 08:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=1r/aF/yFJJBtpX9WyvgDdWcyjRkbKQTlhN5PlhrRMP8=; b=cwh2lA1RrC5h9ATePrmDt1WfbFvu7N2RdgmRIVY9FaJ7XapYMlEbQxS8qVymWr+1Yb I4g7uubVIqCoZ4MM52GiHMmcJfv7UYFDSoBIjkuBOf+yZ5OmoJ+9BsE9SPlXDyT0puuD AyMe90puc9nxXT8d50sq7cgg7M/dGgeAZMl1JQWiUveMpYKICKHaldf3yneJ/F4vfaFH ZSCyCx07UX1VryspZGkG/R33ccC+Cx6OQJAeJRe65iaadRokppd7I42NqsbRvvnQpoF5 yh85UVMo/8zth+4wvZQY0WwTdeRlW1nHi5bdLrwIqbQdfYkByxJGW3aCf72lNqBBLbEs 2IqA== MIME-Version: 1.0 Received: by 10.224.105.203 with SMTP id u11mr5801284qao.77.1330705665724; Fri, 02 Mar 2012 08:27:45 -0800 (PST) Received: by 10.229.144.211 with HTTP; Fri, 2 Mar 2012 08:27:45 -0800 (PST) In-Reply-To: <1330704752.32354.YahooMailClassic@web113315.mail.gq1.yahoo.com> References: <1330704752.32354.YahooMailClassic@web113315.mail.gq1.yahoo.com> Date: Fri, 2 Mar 2012 16:27:45 +0000 X-Google-Sender-Auth: qGleLdiuMpPAWXcZmDYZtUdrRdg Message-ID: Subject: Re: INVALID_SOCKET symbol conflict From: Alexander Lamaison To: libssh2 development X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q22GRphM027084 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q22GRrS8027176 On 2 March 2012 16:12, Lawson wrote: > Hi, > > Thanks for the prompt reply.  The compile warning is: > > In file included from /usr/local/include/libssh2/libssh2.h:140:1: warning: "INVALID_SOCKET" redefined > In file included from /usr/local/include/snmp_pp/snmp_pp.h:71, >                 from snmpThreadData.h:13, >                 from snmpThreadData.cpp:4: > > /usr/local/include/snmp_pp/uxsnmp.h:49:1: warning: this is the location of the previous definition > > So the conflict is I end up with headers both from libssh2 and the snmp++ library (http://www.agentpp.com/snmp_pp3_x/snmp_pp3_x.html). > > Libssh2 defines it as: > > #define INVALID_SOCKET -1 > > and SNMP++ defines it as: > #ifndef INVALID_SOCKET > #define INVALID_SOCKET ((SnmpSocket)(~0)) // value for invalid socket > #endif I believe that both these values actually result in the same thing: an int-size chunk of memory with all bits set. > Note that the SNMP++ header has an #ifdef. One way to deal with this is to do the same thing so whichever one comes first wins. > Mostly I was perplexed at why two different libraries which are otherwise both disciplined about defining their constants with a namespace prefix both chose to define this one symbol like this, like it was some magical special symbol that everyone  knew about. I guess it *is* a magical special symbol everyone knows about ... if you come from the Windows world. My personal preference would be to declare our own constant, something like LIBSSH2_INVALID_SOCKET that is INVALID_SOCKET on windows and -1 elsewhere. Then we use that in the libssh2 source code rather than co-opting INVALID_SOCKET. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 17:30:06 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22GU4Nr029479; Fri, 2 Mar 2012 17:30:06 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q22GU3r9029394 for ; Fri, 2 Mar 2012 17:30:03 +0100 Received: (qmail 8586 invoked by uid 501); 2 Mar 2012 16:30:04 -0000 Message-ID: <20120302163004.8585.qmail@stuge.se> Date: Fri, 2 Mar 2012 17:30:04 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: INVALID_SOCKET symbol conflict Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1330704752.32354.YahooMailClassic@web113315.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1330704752.32354.YahooMailClassic@web113315.mail.gq1.yahoo.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hi, *please* don't double post! Thanks. Lawson wrote: > I'm sure I can craft a workaround. Please send a proper fix instead. > Mostly I was perplexed at why two different libraries which are > otherwise both disciplined about defining their constants with a > namespace prefix both chose to define this one symbol like this, > like it was some magical special symbol that everyone knew about. Yes, that's exactly right. But it can of course be wrapped for non-Windows and arguably this is the good way. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 17:32:04 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22GW1bV031018; Fri, 2 Mar 2012 17:32:04 +0100 Received: from mail-qy0-f170.google.com (mail-qy0-f170.google.com [209.85.216.170]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22GVxF2030918 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Mar 2012 17:32:00 +0100 Received: by qcmt36 with SMTP id t36so795966qcm.15 for ; Fri, 02 Mar 2012 08:31:55 -0800 (PST) Received-SPF: pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.105.203 as permitted sender) client-ip=10.224.105.203; Authentication-Results: mr.google.com; spf=pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.105.203 as permitted sender) smtp.mail=alexander.lamaison@gmail.com; dkim=pass header.i=alexander.lamaison@gmail.com Received: from mr.google.com ([10.224.105.203]) by 10.224.105.203 with SMTP id u11mr6901101qao.77.1330705915272 (num_hops = 1); Fri, 02 Mar 2012 08:31:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=rHm7a1qy+JpNQEoM7FhWuYNe2b2ZU4s/FlQmmmOh1hY=; b=fwS7Z+ddIhIOz+ZbD1i04iPhrBv5rSzJ5Zx6K4MNF8DSaA5j0YyAqOSOIb88N6cUl7 6S3bxwR5yjGimcJNQ8/I2ydHNIPRpk8fxvhmtsi2AECenfVKTslO21jRZBI2/o0whNaC tKoH5dGaOhqNoiXuLmFtztuvy38xaPzxBW2TycAi0TAIi/yMZriiCk1FlVLGheV7grmY n8SHk0DL6t3kvytI1x80731NslJMSA3Arck521HDs46+yScQneVwUf38WSnHCOXrQqji AI/pmvkh1q8HK5zZt2D25aAapEKZsrfhT6w547OhFDp0BtpQr5RlaH4eeHtnddY7UjCM 7hvA== MIME-Version: 1.0 Received: by 10.224.105.203 with SMTP id u11mr5804305qao.77.1330705915195; Fri, 02 Mar 2012 08:31:55 -0800 (PST) Received: by 10.229.144.211 with HTTP; Fri, 2 Mar 2012 08:31:55 -0800 (PST) In-Reply-To: <20120302162626.8217.qmail@stuge.se> References: <1330701214.90318.YahooMailClassic@web113308.mail.gq1.yahoo.com> <20120302162626.8217.qmail@stuge.se> Date: Fri, 2 Mar 2012 16:31:55 +0000 X-Google-Sender-Auth: a5BvZIP_HctNVEDe5g6SdQF988Q Message-ID: Subject: Re: INVALID_SOCKET symbol conflict From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 2 March 2012 16:26, Peter Stuge wrote: > The fix is of course to use LIBSSH2_INVALID_SOCKET. Please send a > git patch which does the change, including the neccessary autoconf > goo. This wouldn't need autoconf to get involved. Just #ifdef WIN32 const int LIBSSH2_INVALID_SOCKET = INVALID_SOCKET; #else const unsigned int LIBSSH2_INVALID_SOCKET = -1; #endif ... or something of that ilk. Alex _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 17:38:56 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Gco17003845; Fri, 2 Mar 2012 17:38:55 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q22GcmAD003834 for ; Fri, 2 Mar 2012 17:38:48 +0100 Received: (qmail 9390 invoked by uid 501); 2 Mar 2012 16:38:49 -0000 Message-ID: <20120302163849.9389.qmail@stuge.se> Date: Fri, 2 Mar 2012 17:38:49 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: INVALID_SOCKET symbol conflict Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1330701214.90318.YahooMailClassic@web113308.mail.gq1.yahoo.com> <20120302162626.8217.qmail@stuge.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Alexander Lamaison wrote: > > The fix is of course to use LIBSSH2_INVALID_SOCKET. Please send a > > git patch which does the change, including the neccessary autoconf > > goo. > > This wouldn't need autoconf to get involved. Just > #ifdef WIN32 > const int LIBSSH2_INVALID_SOCKET = INVALID_SOCKET; > #else > const unsigned int LIBSSH2_INVALID_SOCKET = -1; > #endif > > ... or something of that ilk. Yep. Actually this was already done in libssh2.h so I just pushed a commit to fix up the name. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 18:40:21 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22He2ee019757; Fri, 2 Mar 2012 18:40:19 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Hdx4e019293 for ; Fri, 2 Mar 2012 18:40:00 +0100 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q22HdxsK021894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Mar 2012 12:39:59 -0500 Received: from beast.broked.org ([10.3.112.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q22Hdwem024217 for ; Fri, 2 Mar 2012 12:39:58 -0500 Message-ID: <4F510594.4000605@redhat.com> Date: Fri, 02 Mar 2012 10:38:28 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> In-Reply-To: <20120301213900.13343.qmail@stuge.se> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q22He2ee019757 On 03/01/2012 02:39 PM, Peter Stuge wrote: > Henrik Nordström wrote: >> The SSH_MSG_UNIMPLEMENTED is in response to the packet with seqno 4 >> (fifth packet), which is the keep-alive sent before authentication. >> >> Note that SSH_MSG_UNIMPLEMENTED should be sent in response to >> unimplemented messages even if want_reply == 0. want_reply is a >> message specific flag, not part of transport. > > I don't know. I think SSH_MSG_UNIMPLEMENTED would only be acceptable > if the server does not implement SSH_MSG_GLOBAL_REQUEST at all. > (It might not, it's only used for setup and cancelling of > tcpip-forward. > > An easy way out for libssh2 could be to set want reply = 1 for Note that I am not using keepalive with want reply set. Ie the code does the following: libssh2_keepalive_config(trans_ssh->session, 0, KEEPALIVE_TIMEOUT); I made this change to stop getting the 82 packets which were causing the leaks. I am not in favor of asserting the lib when packet 3 is received. There are probably many conditions under which the error packet 3 could be received with different ssh daemons (I am using openssh for the server atm). I'd prefer it be rejected silently (or given back to the api caller) over an assertion. > keepalive and require either SSH_MSG_UNIMPLEMENTED, > SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE in response - but > if the global request is sent after something else has been sent, but > before response has been received, there is still a problem. This > might already be managed within libssh2 though, that keepalives are > never sent in the middle of another request. > > I don't think an SSH client can allow itself to send a global request > with want reply = 0 if it is not already sure that the server > supports that particular request, unless the client adds some > elaborate buffering of global requests it has sent and tries to track > which ones have been answered by the server. Not what we want. > > I think want reply = 1 for keepalive would be fine, and isolates the > problem to that part of the code. > > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 18:43:07 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Hh6UE021464; Fri, 2 Mar 2012 18:43:06 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Hh34G021445 for ; Fri, 2 Mar 2012 18:43:04 +0100 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q22Hh4RD023324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Mar 2012 12:43:04 -0500 Received: from beast.broked.org ([10.3.112.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q22Hh2Kb028449 for ; Fri, 2 Mar 2012 12:43:03 -0500 Message-ID: <4F51064D.3050005@redhat.com> Date: Fri, 02 Mar 2012 10:41:33 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <1330639726.3159.46.camel@home.hno.se> <20120301223715.17785.qmail@stuge.se> In-Reply-To: <20120301223715.17785.qmail@stuge.se> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q22Hh6UE021464 On 03/01/2012 03:37 PM, Peter Stuge wrote: > Henrik Nordström wrote: >>> This might already be managed within libssh2 though, that >>> keepalives are never sent in the middle of another request. >> >> In blocking mode keepalives are by default sent in the middle of other >> requests by _libssh2_wait_socket. >> >> And applications is very likely to do use libss2_keepalive_send in >> similar manner in non-blocking mode. > > I see. Then the code that receives packets must be changed to take > care of those responses as well. > > >> Also be warned that libssh2_keepalive_send corrupts transport if >> only part of the keep-alive message can be sent. > > Good fun. > To address this in my code which is nonblocking, should I avoid sending keepalive_send while a channel operation is in progress? Currently the nonblocking app sends the keepalive based upon a timer set by the return from the previous keepalive_send. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 19:40:15 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22IdxXL029394; Fri, 2 Mar 2012 19:40:12 +0100 Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Idv9h029364 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Mar 2012 19:39:58 +0100 Received: by yenl9 with SMTP id l9so917497yen.41 for ; Fri, 02 Mar 2012 10:39:53 -0800 (PST) Received-SPF: pass (google.com: domain of xmitchx@gmail.com designates 10.50.186.161 as permitted sender) client-ip=10.50.186.161; Authentication-Results: mr.google.com; spf=pass (google.com: domain of xmitchx@gmail.com designates 10.50.186.161 as permitted sender) smtp.mail=xmitchx@gmail.com; dkim=pass header.i=xmitchx@gmail.com Received: from mr.google.com ([10.50.186.161]) by 10.50.186.161 with SMTP id fl1mr2741571igc.44.1330713592873 (num_hops = 1); Fri, 02 Mar 2012 10:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=YbHGlKqfNktHWvodc5GIt+LYRxoyvwM9b3A+PIiyUWo=; b=dRNeGOAZ/G3T3JJgYpAPWrsHjgW8eVej88RoMB2zd0ah9VO0CJ4gNKLgOjWDtXUH61 HScki99RlxDMVRQ+2p5IxdPO4gFAHw96AakdkzYElX7zpeick2XNrRuXqMsxbb5Ropkk CH0OqsoWP/WowWDezUzY/1uzsG+qvU22ATEDwgfV7eFu8IlnPd+NZm73jpWmJPoX7zjk ddiz13XiWywGKaIxNy86EasWpvjo70TMtd/MssLrIRBrbJadiZzQl+y5WjB80ZU1a8hk Rr7T+z+F42Ht6Q85liL+j2nlKt1lDW07sJnIommFDxuEOPBEXyP0pbHaCg6Si2cSzDvf nA7w== Received: by 10.50.186.161 with SMTP id fl1mr2283466igc.44.1330713592807; Fri, 02 Mar 2012 10:39:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Fri, 2 Mar 2012 10:39:32 -0800 (PST) In-Reply-To: <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> From: Mitchell Hashimoto Date: Fri, 2 Mar 2012 10:39:32 -0800 X-Google-Sender-Auth: 8HgtR1yoeSF7gAoh4EKI3qVpZhA Message-ID: Subject: Re: Callback for channel data ready To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0493680163==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0493680163== Content-Type: multipart/alternative; boundary=14dae9340447ff412504ba46e62b --14dae9340447ff412504ba46e62b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 2, 2012 at 3:21 AM, Tom Weber wrote: > > Hi! > > These are my thoughts... > > > On Wed, Feb 29, 2012 at 7:42 PM, Peter Stuge wrote: > >> > > Sorry not at this time. I think we want callbacks though, so feel > >> > > free to discuss and send patches. :) > > Callbacks sound nice in theory, but I've had my share of them, wrestling > with > PuTTY and Symbian code, and particularly those two together, which have > mostly > incompatible callback schemes. > > The problem is that you as an application developer don't control the > context > in which the callback is called. > > 1) You might want to disconnect and free the session, but you can't do that > since you have to return to a libssh2_session_ routine, which expects the > session to be valid. > > 2) You might want to process the event later, and then you need an > additional > mechanism to save the event. > > 3) During which function call, and from which thread, can we count on the > callback being called? We must know that exactly, to handle things like > mutexes and resource ownership correctly. (Preferably the callback pointer > should be provided at the function call and not saved, to make this more > clear.) > > By the way, signals suffer from the same problems... > Agreed, I'd like to stay away from callbacks now. It complicates many details. > > >> There is no such thing.. libssh2 has evolved, and must continue to > >> evolve. The libssh2 API can and should be expanded to become more > >> useful, and the definition of useful should basically come from it's > >> users. > > Agreed! :-) > > On Fri, March 2, 2012 03:26, Mitchell Hashimoto wrote: > > Instead, I believe it would be nice to do something like the following: > > > > int libssh2_session_ready_channels(LIBSSH2_SESSION *, LIBSSH2_CHANNEL **) > > > > Where this would return a LIBSSH2_ERROR_EAGAIN if the socket would block > > when nonblocking is on, and the return value would basically behave just > > like any other libssh2 call. It would return `0` when it was a success. > > Normal libssh2 behavior. If 0 is returned, then the second parameter is > set > > to a pointer to a single channel that is ready to be read, or NULL if > none > > are ready. > > I suppose that libssh2 maintains a queue of packets for various channels, > and > your proposed function would return the first item from the queue? Sounds > good > if you want to process all packets in order, but what if you want to skip > some > channels because their corresponding sockets are not ready to accept more > data, and you want libssh2 to save the data for later, while blocking that > channel? > > You might think, "why not save such data in a buffer instead?", but that's > not > the same thing. If you keep reading data which you can't send, libssh2 will > adjust the window and accept more and more, and then you might run out of > memory trying to buffer it all. > Hm, my thought process behind the API was this would allow libssh2 to simply read the next SSH packet off the wire and return that channel. If libssh2 were to return a list of ready channels, would it buffer these all somewhere? Does libssh2 already do this internally (which would make this easy)? I'm not against the idea, I think it would be useful, I'm only thinking about the implementation. Best, Mitchell > > > Again, like I said, I don't know the internal structure of libssh2 or > > the feasibility of such a thing, but I can see looping through channels > to > > become overwhelming. > > Overwhelming? Well, the loop must be done in some way anyway inside the > library. (I suppose that libssh2 maps from a channel ID to a struct > pointer, > and that might be a hash array lookup?) > > Again, see my point above about skipping channels which must be paused. One > way would be to tell libssh2 that a particular channel shouldn't be > checked. > Another way would be to loop and check selectively. > > I'm quite happy with libssh2 as it is now, but I'd also like a nicer way to > check a channel. Right now I have a helper routine which looks like this: > > static long _try_channel_read(... LIBSSH2_CHANNEL *channel) > { > long read_size; > > /* ugly kludge */ > libssh2_session_set_blocking(session->ssh_session, 0); > > read_size = libssh2_channel_read(channel, > session->io_buffer, > session->io_buffer_capacity); > ... > > /* ugly kludge */ > libssh2_session_set_blocking(session->ssh_session, 1); > > return read_size; > } > > -- > Best regards, > Tom Weber > Cryptzone Group AB > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > --14dae9340447ff412504ba46e62b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 2, 2012 at 3:21 AM, Tom Weber <tom.weber@cryptz= one.com> wrote:

Hi!

These are my thoughts...

> On Wed, Feb 29, 2012 at 7:42 PM, Peter Stuge <peter@stuge.se> wrote:
>> > > Sorry not at this time. I think = we want callbacks though, so feel
>> > > free to discuss and send patches. :)

Callbacks sound nice in theory, but I've had my share of them, wr= estling with
PuTTY and Symbian code, and particularly those two together, which have mos= tly
incompatible callback schemes.

The problem is that you as an application developer don't control the c= ontext
in which the callback is called.

1) You might want to disconnect and free the session, but you can't do = that
since you have to return to a libssh2_session_ routine, which expects the session to be valid.

2) You might want to process the event later, and then you need an addition= al
mechanism to save the event.

3) During which function call, and from which thread, can we count on the callback being called? We must know that exactly, to handle things like
mutexes and resource ownership correctly. (Preferably the callback pointer<= br> should be provided at the function call and not saved, to make this more clear.)

By the way, signals suffer from the same problems...
<= br>
Agreed, I'd like to stay away from callbacks now. It comp= licates many details.
=A0

>> There is no such thing.. libssh2 has evolved, and must continue to=
>> evolve. The libssh2 API can and should be expanded to become more<= br> >> useful, and the definition of useful should basically come from it= 's
>> users.

Agreed! :-)

On Fri, March 2, 2012 03:26, Mitchell Hashimoto wrote:
> Instead, I believe it would be nice to do something like the following= :
>
> int libssh2_session_ready_channels(LIBSSH2_SESSION *, LIBSSH2_CHANNEL = **)
>
> Where this would return a LIBSSH2_ERROR_EAGAIN if the socket would blo= ck
> when nonblocking is on, and the return value would basically behave ju= st
> like any other libssh2 call. It would return `0` when it was a success= .
> Normal libssh2 behavior. If 0 is returned, then the second parameter i= s set
> to a pointer to a single channel that is ready to be read, or NULL if = none
> are ready.

I suppose that libssh2 maintains a queue of packets for various chann= els, and
your proposed function would return the first item from the queue? Sounds g= ood
if you want to process all packets in order, but what if you want to skip s= ome
channels because their corresponding sockets are not ready to accept more data, and you want libssh2 to save the data for later, while blocking that<= br> channel?

You might think, "why not save such data in a buffer instead?", b= ut that's not
the same thing. If you keep reading data which you can't send, libssh2 = will
adjust the window and accept more and more, and then you might run out of memory trying to buffer it all.

Hm, my = thought process behind the API was this would allow libssh2 to simply read = the next SSH packet off the wire and return that channel.=A0

If libssh2 were to return a list of ready channels, would it buf= fer these all somewhere? Does libssh2 already do this internally (which wou= ld make this easy)?

I'm not against the idea, = I think it would be useful, I'm only thinking about the implementation.= =A0

Best,
Mitchell
=A0

> Again, like I said, I don't know the internal structure of libssh2= or
> the feasibility of such a thing, but I can see looping through channel= s to
> become overwhelming.

Overwhelming? Well, the loop must be done in some way anyway inside t= he
library. (I suppose that libssh2 maps from a channel ID to a struct pointer= ,
and that might be a hash array lookup?)

Again, see my point above about skipping channels which must be paused. One=
way would be to tell libssh2 that a particular channel shouldn't be che= cked.
Another way would be to loop and check selectively.

I'm quite happy with libssh2 as it is now, but I'd also like a nice= r way to
check a channel. Right now I have a helper routine which looks like this:
static long _try_channel_read(... LIBSSH2_CHANNEL *channel)
{
=A0 =A0long read_size;

=A0 =A0/* ugly kludge */
=A0 =A0libssh2_session_set_blocking(session->ssh_session, 0);

=A0 =A0read_size =3D libssh2_channel_read(channel,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 se= ssion->io_buffer,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 se= ssion->io_buffer_capacity);
=A0 =A0...

=A0 =A0/* ugly kludge */
=A0 =A0libssh2_session_set_blocking(session->ssh_session, 1);

=A0 =A0return read_size;
}

--
Best regards,
Tom Weber
Cryptzone Group AB

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/li= bssh2-devel

--14dae9340447ff412504ba46e62b-- --===============0493680163== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0493680163==-- From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 19:58:02 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Ivm27014238; Fri, 2 Mar 2012 19:58:00 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22IvjNu014225 for ; Fri, 2 Mar 2012 19:57:46 +0100 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q22IvkMc008146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Mar 2012 13:57:46 -0500 Received: from beast.broked.org ([10.3.112.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q22IvjU4012201 for ; Fri, 2 Mar 2012 13:57:45 -0500 Message-ID: <4F5117CF.6000000@redhat.com> Date: Fri, 02 Mar 2012 11:56:15 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <1330639726.3159.46.camel@home.hno.se> <20120301223715.17785.qmail@stuge.se> <4F51064D.3050005@redhat.com> In-Reply-To: <4F51064D.3050005@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q22Ivm27014238 On 03/02/2012 10:41 AM, Steven Dake wrote: > On 03/01/2012 03:37 PM, Peter Stuge wrote: >> Henrik Nordström wrote: >>>> This might already be managed within libssh2 though, that >>>> keepalives are never sent in the middle of another request. >>> >>> In blocking mode keepalives are by default sent in the middle of other >>> requests by _libssh2_wait_socket. >>> >>> And applications is very likely to do use libss2_keepalive_send in >>> similar manner in non-blocking mode. >> >> I see. Then the code that receives packets must be changed to take >> care of those responses as well. >> >> >>> Also be warned that libssh2_keepalive_send corrupts transport if >>> only part of the keep-alive message can be sent. >> >> Good fun. >> > > To address this in my code which is nonblocking, should I avoid sending > keepalive_send while a channel operation is in progress? Currently the > nonblocking app sends the keepalive based upon a timer set by the return > from the previous keepalive_send. > > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel Short note, I put my libbsh2_keepalive_config code after the key setup and no longer receive the MSG UNIMPLEMENTED packet. As a result, this is user error. Hope others find this information helpful when developing their own apps. Even after properly registering with keepalive_config, the keepalive messages still return MSG_REQUEST_FAILURE if want reply is set. Regards -steve _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 20:01:39 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22J1cBx017669; Fri, 2 Mar 2012 20:01:39 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q22J1ZXI017643 for ; Fri, 2 Mar 2012 20:01:35 +0100 Received: (qmail 20201 invoked by uid 501); 2 Mar 2012 19:01:36 -0000 Message-ID: <20120302190136.20200.qmail@stuge.se> Date: Fri, 2 Mar 2012 20:01:36 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Callback for channel data ready Mail-Followup-To: libssh2-devel@cool.haxx.se References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Mitchell Hashimoto wrote: > I'd like to stay away from callbacks now. It complicates many details. It's not so bad, libssh2 is not thread safe anyway, so there would not be many problems. > If libssh2 were to return a list of ready channels, would it buffer these > all somewhere? Does libssh2 already do this internally (which would make > this easy)? It does already. If you're in blocking mode and call _channel_read() on one channel, but a packet for another channel comes in, libssh2 has to deal. I'm with Daniel about supporting multiple channels. Taking it a little bit further I think it might not be a bad idea to model the API after select() and poll(), meaning that the caller provides a list of currently interesting channels, and libssh2 returns saying what action there is to take. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 2 20:43:53 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22Jhkko016760; Fri, 2 Mar 2012 20:43:52 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22JhiqG016753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2012 20:43:44 +0100 Received: from [IPv6:2001:16d8:ff00:548::2] (cl-1353.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:548::2]) (authenticated bits=0) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q22JhhLU015722 for ; Fri, 2 Mar 2012 19:43:45 GMT Message-ID: <1330717430.2427.9.camel@hlaptop.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Fri, 02 Mar 2012 20:43:50 +0100 In-Reply-To: <4F51064D.3050005@redhat.com> References: <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <1330639726.3159.46.camel@home.hno.se> <20120301223715.17785.qmail@stuge.se> <4F51064D.3050005@redhat.com> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Fri, 02 Mar 2012 19:43:45 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se fre 2012-03-02 klockan 10:41 -0700 skrev Steven Dake: > To address this in my code which is nonblocking, should I avoid sending > keepalive_send while a channel operation is in progress? Currently the > nonblocking app sends the keepalive based upon a timer set by the return > from the previous keepalive_send. You don't need to worry that much about it. The UNIMPLEMENTED thing is a small bug. But * Don't call libssh2_keepalive_send() until authentication have finished and the connection protocol is active. It's not valid to use before. * Don't enable want_reply in libssh2_keepalive_config(). It's not really implemented yet in libssh2 keepalive probes. * Also do not cal libss2_keepalive_send() if you have written a lot of data to several channels fast, or if you otherwise suspect there is a risk that the keep-alive probe can not be immediately queued by the transport socket. I would advice to only call it while otherwise idle. This avoids all other issues. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 3 00:11:38 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22NBDbM030329; Sat, 3 Mar 2012 00:11:34 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q22NBA5O030184 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 3 Mar 2012 00:11:11 +0100 Received: by iahk25 with SMTP id k25so3513956iah.41 for ; Fri, 02 Mar 2012 15:11:05 -0800 (PST) Received-SPF: pass (google.com: domain of xmitchx@gmail.com designates 10.42.174.71 as permitted sender) client-ip=10.42.174.71; Authentication-Results: mr.google.com; spf=pass (google.com: domain of xmitchx@gmail.com designates 10.42.174.71 as permitted sender) smtp.mail=xmitchx@gmail.com; dkim=pass header.i=xmitchx@gmail.com Received: from mr.google.com ([10.42.174.71]) by 10.42.174.71 with SMTP id u7mr8036601icz.44.1330729865295 (num_hops = 1); Fri, 02 Mar 2012 15:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=c5pjvioKEnbvLM9ll28PAA6k1U0kwz6pDrYuvUnU38o=; b=tGh9IjEj2cyzMgva/SIMJ/T43BPjF+k2lRS7S3qUOWFYFl5V5Dvnpy4thkGCQ3Bns4 A3ztJn2RGHyUOpHUCGMs2wedc6QtYA9Ykh0AOBTNrx5IYGSULE47MMPKwIwaBsCQb2XL mr+dnvIfCnO/vgU4eD+IFXY2z15jVEN1huVwVWcIB8bfcapejx+ahSC/pfAJsQeBgBwh 312ZRHVOWZJj1G/1lZWENm2iX/Ujw+f8jS09XBMygGK9CRjAZIEUAD6zlKbgFKXgwjky vpjh3x+EHIrw2DHncGMClH/kZoGCKjUAJu8/ORdku4CNj0a+pNIjJ278kEcmy9aBXrPf PXXQ== Received: by 10.42.174.71 with SMTP id u7mr6592944icz.44.1330729865217; Fri, 02 Mar 2012 15:11:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Fri, 2 Mar 2012 15:10:45 -0800 (PST) In-Reply-To: <20120302190136.20200.qmail@stuge.se> References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> From: Mitchell Hashimoto Date: Fri, 2 Mar 2012 15:10:45 -0800 X-Google-Sender-Auth: Y0-NB-8bSpN6rOBSi_8BgUznzLg Message-ID: Subject: Re: Callback for channel data ready To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0698309293==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0698309293== Content-Type: multipart/alternative; boundary=90e6ba6e8edee8883904ba4ab05d --90e6ba6e8edee8883904ba4ab05d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 2, 2012 at 11:01 AM, Peter Stuge wrote: > Mitchell Hashimoto wrote: > > I'd like to stay away from callbacks now. It complicates many details. > > It's not so bad, libssh2 is not thread safe anyway, so there would > not be many problems. > > > > If libssh2 were to return a list of ready channels, would it buffer these > > all somewhere? Does libssh2 already do this internally (which would make > > this easy)? > > It does already. If you're in blocking mode and call _channel_read() > on one channel, but a packet for another channel comes in, libssh2 > has to deal. > Ah perfect. > > I'm with Daniel about supporting multiple channels. Taking it a > little bit further I think it might not be a bad idea to model the > API after select() and poll(), meaning that the caller provides a > list of currently interesting channels, and libssh2 returns saying > what action there is to take. > > I agree that a `select()` would be nice but of course it can't be modeled like the `select` syscall since I think channel IDs increase monotonically, correct? Because of that, marking a bitmap of the ready channels would quickly grow out of control for SSH sessions that are held open for a long amount of time. Perhaps instead a kqueue-like interface would be appropriate where you constuct an opaque `channel_group` like structure that contains the channels you care about. Channel IDs are simply numbers, so libssh2 can do some sort of efficient search/sort in order to quickly check if channel X (which it has received a packet for) is in the channel group. This could be efficiently implemented, although of course now the complexity is rising. Or, perhaps simpler, the API can be something like the following: int libssh2_session_channel_ready(LIBSSH2_SESSION *, LIBSSH2_CHANNEL **buffer, int size) Where `size` is the maximum size of the `buffer`, and the API would return the number of channels that are ready to be read, and the `buffer` would be an array of ready channels. This would be pretty easy to implement from an API perspective, but puts more of a burden of performance onto the client. Mitchell > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > --90e6ba6e8edee8883904ba4ab05d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 2, 2012 at 11:01 AM, Peter S= tuge <peter@stuge.se= > wrote:
Mitchell Hashimoto wrote:
> I'd like to stay away from callbacks now. It complicates many deta= ils.

It's not so bad, libssh2 is not thread safe anyway, so there woul= d
not be many problems.


> If libssh2 were to return a list of ready channels, would it buffer th= ese
> all somewhere? Does libssh2 already do this internally (which would ma= ke
> this easy)?

It does already. If you're in blocking mode and call _channel_rea= d()
on one channel, but a packet for another channel comes in, libssh2
has to deal.

Ah perfect.
=A0<= /div>

I'm with Daniel about supporting multiple channels. Taking it a
little bit further I think it might not be a bad idea to model the
API after select() and poll(), meaning that the caller provides a
list of currently interesting channels, and libssh2 returns saying
what action there is to take.

<= br>
I agree that a `select()` would be nice but of course it can&= #39;t be modeled like the `select` syscall since I think channel IDs increa= se monotonically, correct? Because of that, marking a bitmap of the ready c= hannels would quickly grow out of control for SSH sessions that are held op= en for a long amount of time.

Perhaps instead a kqueue-like interface would be approp= riate where you constuct an opaque `channel_group` like structure that cont= ains the channels you care about. Channel IDs are simply numbers, so libssh= 2 can do some sort of efficient search/sort in order to quickly check if ch= annel X (which it has received a packet for) is in the channel group. This = could be efficiently implemented, although of course now the complexity is = rising.

Or, perhaps simpler, the API can be something like the = following:

int libssh2_session_channel_ready(LIBSS= H2_SESSION *, LIBSSH2_CHANNEL **buffer, int size)

Where `size` is the maximum size of the `buffer`, and the API would return = the number of channels that are ready to be read, and the `buffer` would be= an array of ready channels. This would be pretty easy to implement from an= API perspective, but puts more of a burden of performance onto the client.=

Mitchell
=A0

//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/li= bssh2-devel

--90e6ba6e8edee8883904ba4ab05d-- --===============0698309293== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0698309293==-- From libssh2-devel-bounces@cool.haxx.se Sun Mar 4 23:34:16 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q24MXtqt008136; Sun, 4 Mar 2012 23:34:12 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q24MXsOx008108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 4 Mar 2012 23:33:54 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q24MXsi5008104 for ; Sun, 4 Mar 2012 23:33:54 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 4 Mar 2012 23:33:54 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Timestamp patch for _libssh2_debug() In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Wed, 29 Feb 2012, Tom Weber wrote: > The timestamps generated by _libssh2_debug() measure time since a quite > arbitrary point in time. It's the first time the function was called, > rounded down to the previous whole second. So if gettimeofday() returned > 1000000.123456 the first time, the time 1000000.000000 is taken as the > reference. So if the next call occurs at gettimeofday() 1000000.456789, > _libssh2_debug() would print 0.456789 as timestamp, instead of 0.333333 > which is the actual time difference. This caused some confusion as my > application mixes these printouts with similar ones with proper calculation, > so the time could seem to jump up and down by as much as a second in the > logs. > > My patch saves also the second fraction at the first call, and makes a > proper calculation using carry. Excellent. Can you please resubmit the patch made with diff -u instead or even directly with git? That makes it much easier for us to apply and even to review the change inlined. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 5 20:03:33 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q25J3Fsv015745; Mon, 5 Mar 2012 20:03:29 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q25J2SbA015206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Mar 2012 20:02:28 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q25J2SsJ015199 for ; Mon, 5 Mar 2012 20:02:28 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 5 Mar 2012 20:02:28 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] Follow RFC4253 section 11.4 In-Reply-To: <4F510594.4000605@redhat.com> Message-ID: References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Fri, 2 Mar 2012, Steven Dake wrote: > I made this change to stop getting the 82 packets which were causing the > leaks. > > I am not in favor of asserting the lib when packet 3 is received. There are > probably many conditions under which the error packet 3 could be received > with different ssh daemons (I am using openssh for the server atm). I'd > prefer it be rejected silently (or given back to the api caller) over an > assertion. Hey! I've not really caught up the backs and forths of this discussion. Is there an outcome or patch suggested or where do we stand on the leak thing? -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 5 20:05:37 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q25J5ZBo018349; Mon, 5 Mar 2012 20:05:36 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q25J5YPr018334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Mar 2012 20:05:34 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q25J5XW5018330; Mon, 5 Mar 2012 20:05:33 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 5 Mar 2012 20:05:33 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] Add tracing to print packets left on session at libssh2_session_free In-Reply-To: <1330281762-20255-1-git-send-email-sdake@redhat.com> Message-ID: References: <1330281762-20255-1-git-send-email-sdake@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sun, 26 Feb 2012, Steven Dake wrote: Thanks, merged and pushed! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 02:51:16 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q261onPi002244; Tue, 6 Mar 2012 02:51:10 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q261okwe002216 for ; Tue, 6 Mar 2012 02:50:47 +0100 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q261ok4a007277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 20:50:47 -0500 Received: from beast.broked.org ([10.3.112.16]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q261ojBl013198; Mon, 5 Mar 2012 20:50:46 -0500 Message-ID: <4F556D11.2000609@redhat.com> Date: Mon, 05 Mar 2012 18:49:05 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Daniel Stenberg X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 03/05/2012 12:02 PM, Daniel Stenberg wrote: > On Fri, 2 Mar 2012, Steven Dake wrote: > >> I made this change to stop getting the 82 packets which were causing >> the leaks. >> >> I am not in favor of asserting the lib when packet 3 is received. >> There are probably many conditions under which the error packet 3 >> could be received with different ssh daemons (I am using openssh for >> the server atm). I'd prefer it be rejected silently (or given back to >> the api caller) over an assertion. > > Hey! > > I've not really caught up the backs and forths of this discussion. Is > there an outcome or patch suggested or where do we stand on the leak thing? > Packet type MSG_UNIMPLEMENTED will be leaked if a keepalive_config is sent before authorization is done (My code was doing this previously as I thought keepalive should be done immediately after opening the session). Packet type MSG_REQUEST_FAILURE will be leaked every time a keepalive is sent when the keepalive_config was set with want_reply (2nd parameter) set to 1. This was the cause of the massive leaking that occurred. I just set that second parameter to 0 and there are no more leaks. Neither of these message types is handled appropriately, so they will always be leaked. I think there was some discussion about keeping track of request/response packets to map unimplemented and request failure responses back to the requesting API. I have no suggestions on that point, but there were some other discussions in the thread if your interested. Regards -steve _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 05:40:09 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q263E8LW012521; Tue, 6 Mar 2012 04:14:21 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q263DpAf011384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Mar 2012 04:13:51 +0100 Received: from home.hno.se (home.hno.se [IPv6:2001:470:df90::1]) (authenticated bits=128) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q263DoaO020079 for ; Tue, 6 Mar 2012 03:13:51 GMT Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by home.hno.se (8.14.5/8.14.5) with ESMTP id q263DnY5022148 for ; Tue, 6 Mar 2012 04:13:49 +0100 Message-ID: <1331003629.4659.8.camel@home.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Tue, 06 Mar 2012 04:13:49 +0100 In-Reply-To: <4F556D11.2000609@redhat.com> References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> <4F556D11.2000609@redhat.com> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on home.hno.se X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Tue, 06 Mar 2012 03:13:51 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q263E8LW012521 mÃ¥n 2012-03-05 klockan 18:49 -0700 skrev Steven Dake: > I think there was some discussion about keeping track of > request/response packets to map unimplemented and request failure > responses back to the requesting API. I have no suggestions on that > point, but there were some other discussions in the thread if your > interested. Yes, but that discussion is for future. For now we need your patch but with corrected comments and description. It's the wrong thing, but much better than doing nothing. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 06:14:34 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q265ECYX026449; Tue, 6 Mar 2012 06:14:31 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q265E5t4026349 for ; Tue, 6 Mar 2012 06:14:05 +0100 Received: (qmail 29733 invoked by uid 501); 6 Mar 2012 05:14:05 -0000 Message-ID: <20120306051405.29732.qmail@stuge.se> Date: Tue, 6 Mar 2012 06:14:05 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 Mail-Followup-To: libssh2-devel@cool.haxx.se References: <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> <4F556D11.2000609@redhat.com> <1331003629.4659.8.camel@home.hno.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1331003629.4659.8.camel@home.hno.se> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q265ECYX026449 Henrik Nordström wrote: > For now we need your patch but with corrected comments and description. > It's the wrong thing, but much better than doing nothing. Hm? I think doing the wrong thing isn't such a good idea? If we want to assist library users (I do) I think what we could do is return an error for _keepalive_send() until it's safe to send one. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 07:48:57 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q266mdU1002950; Tue, 6 Mar 2012 07:48:53 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q266ma89002903 for ; Tue, 6 Mar 2012 07:48:37 +0100 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q266mU5o003235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Mar 2012 01:48:30 -0500 Received: from beast.broked.org ([10.3.112.16]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q266mTvA008546; Tue, 6 Mar 2012 01:48:30 -0500 Message-ID: <4F55B2D9.7070101@redhat.com> Date: Mon, 05 Mar 2012 23:46:49 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <1330401523-8188-1-git-send-email-sdake@redhat.com> <1330424506.1025.13.camel@home.hno.se> <4F4EB832.9050000@redhat.com> <1330560756.24673.161.camel@home.hno.se> <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> <4F556D11.2000609@redhat.com> In-Reply-To: <4F556D11.2000609@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Daniel Stenberg X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 03/05/2012 06:49 PM, Steven Dake wrote: > On 03/05/2012 12:02 PM, Daniel Stenberg wrote: >> On Fri, 2 Mar 2012, Steven Dake wrote: >> >>> I made this change to stop getting the 82 packets which were causing >>> the leaks. >>> >>> I am not in favor of asserting the lib when packet 3 is received. >>> There are probably many conditions under which the error packet 3 >>> could be received with different ssh daemons (I am using openssh for >>> the server atm). I'd prefer it be rejected silently (or given back to >>> the api caller) over an assertion. >> >> Hey! >> >> I've not really caught up the backs and forths of this discussion. Is >> there an outcome or patch suggested or where do we stand on the leak thing? >> > > Packet type MSG_UNIMPLEMENTED will be leaked if a keepalive_config is > sent before authorization is done (My code was doing this previously as > I thought keepalive should be done immediately after opening the session). > > Packet type MSG_REQUEST_FAILURE will be leaked every time a keepalive is > sent when the keepalive_config was set with want_reply (2nd parameter) > set to 1. This was the cause of the massive leaking that occurred. I > just set that second parameter to 0 and there are no more leaks. > > Neither of these message types is handled appropriately, so they will > always be leaked. > > I think there was some discussion about keeping track of > request/response packets to map unimplemented and request failure > responses back to the requesting API. I have no suggestions on that > point, but there were some other discussions in the thread if your > interested. > > Regards > -steve > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel I looked about adding a return code for libssh2_keepalive_config for the following two errors: 1) authorization not yet completed 2) want reply is not supported by the library I found that the prototype is: void libssh2_keepalive_config(LIBSSH2_SESSION *session, int want_reply, unsigned interval); As a result, making a change here would break the ABI in a non-backward-compatible way (changing the void return to int... How to proceed here? Regards -steve _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 07:54:02 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q265cfxU011548; Tue, 6 Mar 2012 06:38:54 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q265cbL8011521 for ; Tue, 6 Mar 2012 06:38:38 +0100 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q265cb6w004365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 00:38:37 -0500 Received: from beast.broked.org ([10.3.112.16]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q265caDi028959 for ; Tue, 6 Mar 2012 00:38:37 -0500 Message-ID: <4F55A278.2060007@redhat.com> Date: Mon, 05 Mar 2012 22:36:56 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Follow RFC4253 section 11.4 References: <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> <4F556D11.2000609@redhat.com> <1331003629.4659.8.camel@home.hno.se> <20120306051405.29732.qmail@stuge.se> In-Reply-To: <20120306051405.29732.qmail@stuge.se> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q265cfxU011548 On 03/05/2012 10:14 PM, Peter Stuge wrote: > Henrik Nordström wrote: >> For now we need your patch but with corrected comments and description. >> It's the wrong thing, but much better than doing nothing. > > Hm? I think doing the wrong thing isn't such a good idea? > > If we want to assist library users (I do) I think what we could do is > return an error for _keepalive_send() until it's safe to send one. > > It is keepalive_config which triggers the want_replys (keepalive_send doesn't take a want reply parameter) Plus man page description - I tend to agree. Regards -steve > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 18:37:08 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267Zp5T009371; Tue, 6 Mar 2012 08:35:54 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267Zjsx009168 for ; Tue, 6 Mar 2012 08:35:46 +0100 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q267Ze0r009376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 02:35:40 -0500 Received: from beast.broked.org.com ([10.3.112.16]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q267ZdXn025617; Tue, 6 Mar 2012 02:35:40 -0500 From: Steven Dake To: libssh2-devel@cool.haxx.se Subject: [PATCH] Use safer snprintf rather then sprintf in scp_send() Date: Tue, 6 Mar 2012 00:33:57 -0700 Message-Id: <1331019237-17135-1-git-send-email-sdake@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Signed-off-by: Steven Dake --- src/scp.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/scp.c b/src/scp.c index a40f7e9..5534b02 100644 --- a/src/scp.c +++ b/src/scp.c @@ -795,8 +795,8 @@ scp_send(LIBSSH2_SESSION * session, const char *path, int mode, return NULL; } - sprintf((char *)session->scpSend_command, "scp -%st ", - (mtime || atime)?"p":""); + snprintf((char *)session->scpSend_command, session->scpSend_command_len, + "scp -%st ", (mtime || atime)?"p":""); cmd_len = strlen((char *)session->scpSend_command); -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 18:39:21 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267TTqS002716; Tue, 6 Mar 2012 08:29:32 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267TPqG002681 for ; Tue, 6 Mar 2012 08:29:26 +0100 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q267TQOp016895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 02:29:26 -0500 Received: from beast.broked.org.com ([10.3.112.16]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q267TPIq030452; Tue, 6 Mar 2012 02:29:25 -0500 From: Steven Dake To: libssh2-devel@cool.haxx.se Subject: [PATCH] Add comment indicating a resource leak is not really a resource leak Date: Tue, 6 Mar 2012 00:27:43 -0700 Message-Id: <1331018863-14610-1-git-send-email-sdake@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se While possibly obvious to those investigating the code, coverity complains about this out of scope leak. Signed-off-by: Steven Dake --- src/openssl.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/openssl.c b/src/openssl.c index db95b12..7d686a1 100644 --- a/src/openssl.c +++ b/src/openssl.c @@ -217,6 +217,10 @@ static int aes_ctr_init(EVP_CIPHER_CTX *ctx, const unsigned char *key, const unsigned char *iv, int enc) /* init key */ { + /* + * variable "c" is leaked from this scope, but is later freed + * in aes_ctr_cleanup + */ aes_ctr_ctx *c = malloc(sizeof(*c)); const EVP_CIPHER *aes_cipher; (void) enc; -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 18:50:55 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267PkQo032054; Tue, 6 Mar 2012 08:26:11 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267PYnK031958 for ; Tue, 6 Mar 2012 08:25:35 +0100 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q267PYna006067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 02:25:34 -0500 Received: from beast.broked.org.com ([10.3.112.16]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q267PXIf029890; Tue, 6 Mar 2012 02:25:34 -0500 From: Steven Dake To: libssh2-devel@cool.haxx.se Subject: [PATCH] Use safer snprintf rather then sprintf in scp_recv() Date: Tue, 6 Mar 2012 00:23:51 -0700 Message-Id: <1331018631-14282-1-git-send-email-sdake@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se While the buffer is indeed allocated to a safe length, better safe then sorry. Signed-off-by: Steven Dake --- src/scp.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/src/scp.c b/src/scp.c index 649c2a6..a40f7e9 100644 --- a/src/scp.c +++ b/src/scp.c @@ -294,8 +294,7 @@ scp_recv(LIBSSH2_SESSION * session, const char *path, struct stat * sb) return NULL; } - /* sprintf() is fine here since we allocated a large enough buffer */ - sprintf((char *)session->scpRecv_command, "scp -%sf ", sb?"p":""); + snprintf((char *)session->scpRecv_command, session->scpRecv_command_len, "scp -%sf ", sb?"p":""); cmd_len = strlen((char *)session->scpRecv_command); -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 18:52:43 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26C1KBp016348; Tue, 6 Mar 2012 13:01:41 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26C1IpC016340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Mar 2012 13:01:18 +0100 Received: from [IPv6:2001:16d8:ff00:548::2] (cl-1353.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:548::2]) (authenticated bits=0) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q26C1HfZ007846 for ; Tue, 6 Mar 2012 12:01:19 GMT Message-ID: <1331035287.6380.5.camel@hlaptop.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Tue, 06 Mar 2012 13:01:27 +0100 In-Reply-To: <20120306051405.29732.qmail@stuge.se> References: <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> <4F556D11.2000609@redhat.com> <1331003629.4659.8.camel@home.hno.se> <20120306051405.29732.qmail@stuge.se> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Tue, 06 Mar 2012 12:01:19 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q26C1KBp016348 tis 2012-03-06 klockan 06:14 +0100 skrev Peter Stuge: > Henrik Nordström wrote: > > For now we need your patch but with corrected comments and description. > > It's the wrong thing, but much better than doing nothing. > > Hm? I think doing the wrong thing isn't such a good idea? It is a small step towards a better result. > If we want to assist library users (I do) I think what we could do is > return an error for _keepalive_send() until it's safe to send one. That too, but is unrelated other than attempting to send keep-alive too early before protocol is active triggers the problem. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 18:54:16 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26C4ckx018147; Tue, 6 Mar 2012 13:04:40 +0100 Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26C4adT018141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Mar 2012 13:04:36 +0100 Received: from [IPv6:2001:16d8:ff00:548::2] (cl-1353.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:548::2]) (authenticated bits=0) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q26C4a2P026098 for ; Tue, 6 Mar 2012 12:04:37 GMT Message-ID: <1331035480.6380.8.camel@hlaptop.hno.se> Subject: Re: [PATCH] Follow RFC4253 section 11.4 From: Henrik =?ISO-8859-1?Q?Nordstr=F6m?= To: libssh2 development Date: Tue, 06 Mar 2012 13:04:40 +0100 In-Reply-To: <4F55A278.2060007@redhat.com> References: <4F4FA9FF.9040008@redhat.com> <20120301170717.24925.qmail@stuge.se> <4F4FC046.6050004@redhat.com> <20120301192056.2888.qmail@stuge.se> <1330634594.3159.8.camel@home.hno.se> <20120301213900.13343.qmail@stuge.se> <4F510594.4000605@redhat.com> <4F556D11.2000609@redhat.com> <1331003629.4659.8.camel@home.hno.se> <20120306051405.29732.qmail@stuge.se> <4F55A278.2060007@redhat.com> X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Tue, 06 Mar 2012 12:04:37 +0000 (UTC) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q26C4ckx018147 mÃ¥n 2012-03-05 klockan 22:36 -0700 skrev Steven Dake: > On 03/05/2012 10:14 PM, Peter Stuge wrote: > > Henrik Nordström wrote: > >> For now we need your patch but with corrected comments and description. > >> It's the wrong thing, but much better than doing nothing. > > > > Hm? I think doing the wrong thing isn't such a good idea? > > > > If we want to assist library users (I do) I think what we could do is > > return an error for _keepalive_send() until it's safe to send one. > > > > > > It is keepalive_config which triggers the want_replys (keepalive_send > doesn't take a want reply parameter) No. That's the SSH_MSG_REQUEST_FAILURE problem and should be fixed so that the keep-alive code picks up the response it asked for. What we discuss here is the patch to ignore SSH_MSG_UNIMPLEMENTED. Regards Henrik _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 18:55:54 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267BV1t021547; Tue, 6 Mar 2012 08:11:38 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q267BTKK021524 for ; Tue, 6 Mar 2012 08:11:30 +0100 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q267BQCC011346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Mar 2012 02:11:26 -0500 Received: from beast.broked.org.com ([10.3.112.16]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q267BPdU024070; Tue, 6 Mar 2012 02:11:25 -0500 From: Steven Dake To: libssh2-devel@cool.haxx.se Subject: [PATCH] use snprintf in knownhost_writeline() rather then sprintf Date: Tue, 6 Mar 2012 00:09:42 -0700 Message-Id: <1331017782-10298-1-git-send-email-sdake@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Although the function checks the length, if the code was in error, there could potentially be a buffer overrun with the use of sprintf. Instead replace with snprintf. Signed-off-by: Steven Dake --- src/knownhost.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/knownhost.c b/src/knownhost.c index 193bda3..c58dfbb 100644 --- a/src/knownhost.c +++ b/src/knownhost.c @@ -997,10 +997,10 @@ knownhost_writeline(LIBSSH2_KNOWNHOSTS *hosts, if(nlen <= buflen) if(node->comment) - sprintf(buf, "|1|%s|%s%s %s %s\n", saltalloc, namealloc, + snprintf(buf, buflen, "|1|%s|%s%s %s %s\n", saltalloc, namealloc, keytype, node->key, node->comment); else - sprintf(buf, "|1|%s|%s%s %s\n", saltalloc, namealloc, + snprintf(buf, buflen, "|1|%s|%s%s %s\n", saltalloc, namealloc, keytype, node->key); else rc = _libssh2_error(hosts->session, LIBSSH2_ERROR_BUFFER_TOO_SMALL, @@ -1016,10 +1016,10 @@ knownhost_writeline(LIBSSH2_KNOWNHOSTS *hosts, if(nlen <= buflen) /* these types have the plain name */ if(node->comment) - sprintf(buf, "%s%s %s %s\n", node->name, keytype, node->key, + snprintf(buf, buflen, "%s%s %s %s\n", node->name, keytype, node->key, node->comment); else - sprintf(buf, "%s%s %s\n", node->name, keytype, node->key); + snprintf(buf, buflen, "%s%s %s\n", node->name, keytype, node->key); else rc = _libssh2_error(hosts->session, LIBSSH2_ERROR_BUFFER_TOO_SMALL, "Known-host write buffer too small"); -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 18:57:35 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26Hv9im023865; Tue, 6 Mar 2012 18:57:33 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26Hv60c023848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Mar 2012 18:57:06 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q26Hv5fp023842; Tue, 6 Mar 2012 18:57:06 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 6 Mar 2012 18:57:05 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] Use safer snprintf rather then sprintf in scp_recv() In-Reply-To: <1331018631-14282-1-git-send-email-sdake@redhat.com> Message-ID: References: <1331018631-14282-1-git-send-email-sdake@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Tue, 6 Mar 2012, Steven Dake wrote: > While the buffer is indeed allocated to a safe length, better safe then > sorry. Sure, but we aim for C89 compatibility so snprintf() isn't generally available - we would then need to provide an internal version for the inferior systems! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 20:16:56 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26JGcX4025109; Tue, 6 Mar 2012 20:16:53 +0100 Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26JGZQW025025 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 6 Mar 2012 20:16:36 +0100 Received: by qcsg15 with SMTP id g15so3256844qcs.41 for ; Tue, 06 Mar 2012 11:16:31 -0800 (PST) Received-SPF: pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.196.66 as permitted sender) client-ip=10.224.196.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of alexander.lamaison@gmail.com designates 10.224.196.66 as permitted sender) smtp.mail=alexander.lamaison@gmail.com; dkim=pass header.i=alexander.lamaison@gmail.com Received: from mr.google.com ([10.224.196.66]) by 10.224.196.66 with SMTP id ef2mr13317838qab.64.1331061391608 (num_hops = 1); Tue, 06 Mar 2012 11:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=7ySuEMQLf/XRKnzv9ImCbE7ZHBStoAq2CQSTpbBUksA=; b=XSOJXQfxnTAavcNrueeD4mueazLQScIh1mIeZ6an1Dn5HCznXqF4LvWBTTuoouzQRO UIYfzN48/kZ2HVKroDIgKygSSEaKmGtBhtY7Lg+QiknRFnU2ecfJzZqfx8H2oF1jmW1n hBz8/4CiRaIPqaM57lSAEXUs2JwsZg/yrtJsPwehmKBBK6Pv/OXgiTyqXH2ITZ0Wgwte 1qmQnnfX7D/8OCXg67dLHTh8HutvBUwdMDhs42kA/I4je6kxWMfIVWaX+iL6HdNriI1b 8hri+c6xUHeQaUJz1IUghgeHdSWuE6yGWFkx+Z6K+qPojB+UiS5eE8AELHJL59YcJ/1X Hu0w== MIME-Version: 1.0 Received: by 10.224.196.66 with SMTP id ef2mr11405855qab.64.1331061391546; Tue, 06 Mar 2012 11:16:31 -0800 (PST) Received: by 10.229.144.211 with HTTP; Tue, 6 Mar 2012 11:16:31 -0800 (PST) In-Reply-To: References: <1331018631-14282-1-git-send-email-sdake@redhat.com> Date: Tue, 6 Mar 2012 19:16:31 +0000 X-Google-Sender-Auth: c_C6KG-dfTHVxSXIZU2QO7Npz9k Message-ID: Subject: Re: [PATCH] Use safer snprintf rather then sprintf in scp_recv() From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 6 March 2012 17:57, Daniel Stenberg wrote: > On Tue, 6 Mar 2012, Steven Dake wrote: > >> While the buffer is indeed allocated to a safe length, better safe then >> sorry. > > Sure, but we aim for C89 compatibility so snprintf() isn't generally > available - we would then need to provide an internal version for the > inferior systems! That's what I thought. But a quick rgrep and I find we use it all over the place! Alex _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 21:46:39 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26KkKO9006196; Tue, 6 Mar 2012 21:46:35 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26KkJmq006178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Mar 2012 21:46:19 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q26KkI0E006175 for ; Tue, 6 Mar 2012 21:46:18 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 6 Mar 2012 21:46:18 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] Use safer snprintf rather then sprintf in scp_recv() In-Reply-To: Message-ID: References: <1331018631-14282-1-git-send-email-sdake@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Tue, 6 Mar 2012, Alexander Lamaison wrote: >> Sure, but we aim for C89 compatibility so snprintf() isn't generally >> available - we would then need to provide an internal version for the >> inferior systems! > > That's what I thought. But a quick rgrep and I find we use it all over the > place! Haha, well that what I get for just blabbing without checking my facts properly. I guess nobody truly used libssh2 yet on one of them old and stupid systems! =) Ok, I retract my objection and as we already use snprintf() we can continue using it and when someone wants libssh2 on a system which doesn't already provide one, we can work on adding an internal one for those at that time. Thanks Alexander! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 6 23:27:18 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26MQxbE022720; Tue, 6 Mar 2012 23:27:16 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26MQwRn022695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Mar 2012 23:26:58 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q26MQv4N022683; Tue, 6 Mar 2012 23:26:58 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 6 Mar 2012 23:26:57 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] Use safer snprintf rather then sprintf in scp_send() In-Reply-To: <1331019237-17135-1-git-send-email-sdake@redhat.com> Message-ID: References: <1331019237-17135-1-git-send-email-sdake@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Tue, 6 Mar 2012, Steven Dake wrote: Thanks! I now merged and pushed your three snprintf patches and the fixed comment one. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 7 00:26:03 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26NPoik005519; Wed, 7 Mar 2012 00:26:01 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q26NPlJj005485 for ; Wed, 7 Mar 2012 00:25:48 +0100 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q26NPlWp027072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Mar 2012 18:25:47 -0500 Received: from beast.broked.org ([10.3.112.16]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q26NPkv0016448; Tue, 6 Mar 2012 18:25:47 -0500 Message-ID: <4F569C96.2090509@redhat.com> Date: Tue, 06 Mar 2012 16:24:06 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Re: [PATCH] Use safer snprintf rather then sprintf in scp_send() References: <1331019237-17135-1-git-send-email-sdake@redhat.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: Daniel Stenberg X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 03/06/2012 03:26 PM, Daniel Stenberg wrote: > On Tue, 6 Mar 2012, Steven Dake wrote: > > Thanks! I now merged and pushed your three snprintf patches and the > fixed comment one. > Ok Wasn't sure if libssh2 community would be interested in these sorts of janitorial patches. I have a coverity license and it kicks out about 90 problems. I can only handle doing 2 or 3 at a time before I get bored, so more should be coming over time :) Best way to coverity-ize a project is slow with lots of breaks inbetween ;) I find coverity a bit noisy, but it does improve code quality a bit. Regards -steve _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 7 14:47:52 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q27DlDJs014222; Wed, 7 Mar 2012 14:47:44 +0100 Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q27DlAK6014078 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 7 Mar 2012 14:47:11 +0100 Received: by qcsg15 with SMTP id g15so3954907qcs.41 for ; Wed, 07 Mar 2012 05:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ygBxLrSlorGMvGANfQ7hne81FK6SfZDs8aIRVZFGELw=; b=mj21C7aouEXIv5f9/z9EzMLVBl3yI1jkwnojmNSd8Dtb/hYVjbYOVrWpKsiwwu/GsD zopTNYlmpBJjA+OeWksBbMRZUcODf1CLmhwNwBswYzPFWiFRAb3VqQaFwjJBKlhVHIBr 9RJGjf5HuOQiolztgaa/Q0ukarfbpM0l1Fi+sumenCFgj+6EvDDrG4aJmw3IpcQVC6dw TmSLXAFYkTQYh4zMOaytXiuTlCzgFjb1zCFR91geJUcsCsOQ3o5yacUo+6IYloju5j5t U0gwekIu0B19/MMCYqMpMG6+Ru3GGgFJkORCZTMh6DlrphESGMC7RFZ7jrngv5Re/M8T tNkw== MIME-Version: 1.0 Received: by 10.224.34.3 with SMTP id j3mr1256818qad.77.1331128024210; Wed, 07 Mar 2012 05:47:04 -0800 (PST) Received: by 10.229.144.211 with HTTP; Wed, 7 Mar 2012 05:47:04 -0800 (PST) In-Reply-To: <4F569C96.2090509@redhat.com> References: <1331019237-17135-1-git-send-email-sdake@redhat.com> <4F569C96.2090509@redhat.com> Date: Wed, 7 Mar 2012 13:47:04 +0000 X-Google-Sender-Auth: 70VZ8pC7OIp6RE-XONWIF738ndA Message-ID: Subject: Re: [PATCH] Use safer snprintf rather then sprintf in scp_send() From: Alexander Lamaison To: libssh2 development X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q27DlAK6014078 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q27DlDJs014222 On 6 March 2012 23:24, Steven Dake wrote: > Wasn't sure if libssh2 community would be interested in these sorts of > janitorial patches.  I have a coverity license and it kicks out about 90 > problems.  I can only handle doing 2 or 3 at a time before I get bored, > so more should be coming over time :)  Best way to coverity-ize a > project is slow with lots of breaks inbetween ;)  I find coverity a bit > noisy, but it does improve code quality a bit. 'Janitorial' patches are very welcome. IMHO we don't do enough of them. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 8 08:37:35 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q287bFkP007624; Thu, 8 Mar 2012 08:37:31 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q287bC5r007611 for ; Thu, 8 Mar 2012 08:37:13 +0100 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q287bCje000538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Mar 2012 02:37:12 -0500 Received: from beast.broked.org.com ([10.3.112.16]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q287bBGG015160; Thu, 8 Mar 2012 02:37:11 -0500 From: Steven Dake To: libssh2-devel@cool.haxx.se Subject: [PATCH] Tell C compiler we don't care about return code of libssh2_init Date: Thu, 8 Mar 2012 00:35:29 -0700 Message-Id: <1331192129-28812-1-git-send-email-sdake@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se The call of libssh2_init returns a return code, but nothing could be done within the _libssh2_init_if_needed execution path. Signed-off-by: Steven Dake --- src/global.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/global.c b/src/global.c index 409e8e8..dc45e70 100644 --- a/src/global.c +++ b/src/global.c @@ -74,5 +74,5 @@ void _libssh2_init_if_needed(void) { if (_libssh2_initialized == 0) - libssh2_init (0); + (void)libssh2_init (0); } -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 8 21:01:12 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q28K0X3J005158; Thu, 8 Mar 2012 21:01:06 +0100 Received: from zeus.promailserver.com (zeus.promailserver.com [74.200.236.204]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q28K0VgY004919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Mar 2012 21:00:32 +0100 Received: from Pippin ([83.112.149.63]) by zeus.promailserver.com (Merak 8.3.6) with ASMTP id SXI64127 for ; Thu, 8 Mar 2012 20:00:27 -0000 Message-ID: <914A4DD3D02B4499A26BF34C97661D0D@Pippin> From: =?iso-8859-1?Q?Elli=E9_Computing_Open_Source_Program?= To: Subject: can the agent be freed just after userauth succeeded? Date: Thu, 8 Mar 2012 21:00:31 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0220830370==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Ce message est composi et au format MIME. --===============0220830370== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CCFD6E.7FA2FE40" Ce message est composi et au format MIME. ------=_NextPart_000_00A0_01CCFD6E.7FA2FE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am about to add support in libcurl for agent based authentication, I = am missing some information. Is there a list of libssh2_agent_ API which = might return EAGAIN, or might they all return EAGAIN? Once libssh2_agent_userauth succeeded or failed on the last identity, = can I immediately get rid of it with libssh2_agent_disconnect/free = sequence? or do I need to wait for the end of the channel as in the = sample. Best regards Armel ------=_NextPart_000_00A0_01CCFD6E.7FA2FE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am about to add support in libcurl for agent based = authentication, I am=20 missing some information. Is there a list of libssh2_agent_ API which = might=20 return EAGAIN, or might they all return EAGAIN?
 
Once libssh2_agent_userauth succeeded or failed on the last = identity, can I=20 immediately get rid of it with libssh2_agent_disconnect/free sequence? = or do I=20 need to wait for the end of the channel as in the sample.
 
Best regards
Armel
 
 
 
------=_NextPart_000_00A0_01CCFD6E.7FA2FE40-- --===============0220830370== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0220830370==-- From libssh2-devel-bounces@cool.haxx.se Fri Mar 9 03:14:03 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q292DbKM014239; Fri, 9 Mar 2012 03:13:58 +0100 Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q292DYK8012373 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 9 Mar 2012 03:13:36 +0100 Received: by dald2 with SMTP id d2so1112619dal.41 for ; Thu, 08 Mar 2012 18:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=I02zIGNJdN+5Rk1/02Taso+yYDTsR4tizwD3I74Qojc=; b=QDMeLFHfpitl/bW1kZ6CGq+MKEMV+oxDXw8TsQ9h1pJTS4wr/ndUBoZtcuCqtdWrRy OMHiiOQVE/pqPowU74VBYfVF97SbturVZTkI25aNY/0yVnxrxfeKCo1s/BddFZQR31Lc bgmYBC79xtFCCmToqDwTblUhS78KYsz/KvKZmZrnNMVwhU2Y4wkBKIF9AVshuMvgY5AW fyeykDrGJIIHqwRo3JJ/lMNPW23mk7YaATCqK6W+vqetzd/ucFxUE7LH1hS0br9ADNCM a5mtGVKZ2Zwc9aaFMaJAzEiS/HRIFKwi208NNee1erTAx/8BRPw0rvvnuSH+bYbEwuyk ugzQ== MIME-Version: 1.0 Received: by 10.68.201.201 with SMTP id kc9mr1463036pbc.143.1331259209918; Thu, 08 Mar 2012 18:13:29 -0800 (PST) Received: by 10.142.249.35 with HTTP; Thu, 8 Mar 2012 18:13:29 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Mar 2012 02:13:29 +0000 X-Google-Sender-Auth: rrBna5QnyqdAH9bsJM-xYCFqv84 Message-ID: Subject: sftp_write still broken on Windows From: Alexander Lamaison To: "development, libssh2" Content-Type: multipart/mixed; boundary=e89a8ff1c0804fa8a304bac5f072 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --e89a8ff1c0804fa8a304bac5f072 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The latest code still blocks when doing sftp_write on Windows. =A0It happens if it tries to transfer more than about 96MB. =A0I've attached the script and the trace output is here: http://dl.dropbox.com/u/6028779/trace3.out I've not got time to dig into it right now. =A0Better to get it out there than keep it to myself though. The CTRL+C at the end is where I terminate it after it blocks. =A0The block seems to happen the first time it reads 3 rather than 4 and wants to unlink the packet (whatever that implies). Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) --e89a8ff1c0804fa8a304bac5f072 Content-Type: text/x-c++src; charset=US-ASCII; name="libssh2_bigwrite.cpp" Content-Disposition: attachment; filename="libssh2_bigwrite.cpp" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzj3kwl91 LyoNCiAqIFRoZSBzYW1wbGUgY29kZSBoYXMgZGVmYXVsdCB2YWx1ZXMgZm9yIGhvc3QgbmFtZSwg dXNlciBuYW1lLCBwYXNzd29yZA0KICogYW5kIHBhdGggdG8gY29weSwgYnV0IHlvdSBjYW4gc3Bl Y2lmeSB0aGVtIG9uIHRoZSBjb21tYW5kIGxpbmUgbGlrZToNCiAqDQogKiAic2Z0cCAxOTIuMTY4 LjAuMSB1c2VyIHBhc3N3b3JkIC90bXAvc2VjcmV0cyAtcHwtaXwtayINCiAqLw0KDQovLyNkZWZp bmUgVEVTVF9SRUFEX1NJWkUgNjU0MzIxMA0KI2RlZmluZSBURVNUX1JFQURfU0laRSA2NTQNCg0K I2luY2x1ZGUgPGxpYnNzaDJfY29uZmlnLmg+DQojaW5jbHVkZSA8bGlic3NoMi5oPg0KI2luY2x1 ZGUgPGxpYnNzaDJfc2Z0cC5oPg0KDQojaWZkZWYgSEFWRV9XSU5TT0NLMl9IDQojIGluY2x1ZGUg PHdpbnNvY2syLmg+DQojZW5kaWYNCiNpZmRlZiBIQVZFX05FVElORVRfSU5fSA0KIyBpbmNsdWRl IDxuZXRpbmV0L2luLmg+DQojZW5kaWYNCiNpZmRlZiBIQVZFX1NZU19TT0NLRVRfSA0KIyBpbmNs dWRlIDxzeXMvc29ja2V0Lmg+DQojZW5kaWYNCiMgaWZkZWYgSEFWRV9VTklTVERfSA0KI2luY2x1 ZGUgPHVuaXN0ZC5oPg0KI2VuZGlmDQojaWZkZWYgSEFWRV9BUlBBX0lORVRfSA0KIyBpbmNsdWRl IDxhcnBhL2luZXQuaD4NCiNlbmRpZg0KI2lmZGVmIEhBVkVfU1lTX1RJTUVfSA0KIyBpbmNsdWRl IDxzeXMvdGltZS5oPg0KI2VuZGlmDQoNCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRl IDxmY250bC5oPg0KI2luY2x1ZGUgPGVycm5vLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNs dWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDxjdHlwZS5oPg0KDQoNCmNvbnN0IGNoYXIgKnVzZXJu YW1lPSJ1c2VybmFtZSI7DQpjb25zdCBjaGFyICpwYXNzd29yZD0icGFzc3dvcmQiOw0KY29uc3Qg Y2hhciAqc2Z0cHBhdGg9Ii90bXAvVEVTVCI7DQpjb25zdCBjaGFyICpsb2NhbHBhdGg9IiI7DQoN Cg0Kc3RhdGljIHZvaWQga2JkX2NhbGxiYWNrKGNvbnN0IGNoYXIgKm5hbWUsIGludCBuYW1lX2xl biwgDQogICAgICAgICAgICAgY29uc3QgY2hhciAqaW5zdHJ1Y3Rpb24sIGludCBpbnN0cnVjdGlv bl9sZW4sIGludCBudW1fcHJvbXB0cywNCiAgICAgICAgICAgICBjb25zdCBMSUJTU0gyX1VTRVJB VVRIX0tCRElOVF9QUk9NUFQgKnByb21wdHMsDQogICAgICAgICAgICAgTElCU1NIMl9VU0VSQVVU SF9LQkRJTlRfUkVTUE9OU0UgKnJlc3BvbnNlcywNCiAgICAgICAgICAgICB2b2lkICoqYWJzdHJh Y3QpDQp7DQogICAgKHZvaWQpbmFtZTsNCiAgICAodm9pZCluYW1lX2xlbjsNCiAgICAodm9pZClp bnN0cnVjdGlvbjsNCiAgICAodm9pZClpbnN0cnVjdGlvbl9sZW47DQogICAgaWYgKG51bV9wcm9t cHRzID09IDEpIHsNCiAgICAgICAgcmVzcG9uc2VzWzBdLnRleHQgPSBzdHJkdXAocGFzc3dvcmQp Ow0KICAgICAgICByZXNwb25zZXNbMF0ubGVuZ3RoID0gc3RybGVuKHBhc3N3b3JkKTsNCiAgICB9 DQogICAgKHZvaWQpcHJvbXB0czsNCiAgICAodm9pZClhYnN0cmFjdDsNCn0gLyoga2JkX2NhbGxi YWNrICovDQoNCg0KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCnsNCiAgICB1bnNp Z25lZCBsb25nIGhvc3RhZGRyOw0KICAgIGludCBzb2NrLCBpLCBhdXRoX3B3ID0gMDsNCiAgICBz dHJ1Y3Qgc29ja2FkZHJfaW4gc2luOw0KICAgIGNvbnN0IGNoYXIgKmZpbmdlcnByaW50Ow0KICAg IGNoYXIgKnVzZXJhdXRobGlzdDsNCiAgICBMSUJTU0gyX1NFU1NJT04gKnNlc3Npb247DQogICAg aW50IHJjOw0KICAgIExJQlNTSDJfU0ZUUCAqc2Z0cF9zZXNzaW9uOw0KICAgIExJQlNTSDJfU0ZU UF9IQU5ETEUgKnNmdHBfaGFuZGxlOw0KCWNoYXIgKm1lbTsNCgljaGFyICpwdHI7DQoJRklMRSAq ZnA7DQoNCiNpZmRlZiBXSU4zMg0KICAgIFdTQURBVEEgd3NhZGF0YTsNCg0KICAgIFdTQVN0YXJ0 dXAoTUFLRVdPUkQoMiwwKSwgJndzYWRhdGEpOw0KI2VuZGlmDQoNCiAgICBpZiAoYXJnYyA+IDEp IHsNCiAgICAgICAgaG9zdGFkZHIgPSBpbmV0X2FkZHIoYXJndlsxXSk7DQogICAgfSBlbHNlIHsN CiAgICAgICAgaG9zdGFkZHIgPSBodG9ubCgweDdGMDAwMDAxKTsNCiAgICB9DQoNCiAgICBpZihh cmdjID4gMikgew0KICAgICAgICB1c2VybmFtZSA9IGFyZ3ZbMl07DQogICAgfQ0KICAgIGlmKGFy Z2MgPiAzKSB7DQogICAgICAgIHBhc3N3b3JkID0gYXJndlszXTsNCiAgICB9DQogICAgaWYoYXJn YyA+IDQpIHsNCiAgICAgICAgc2Z0cHBhdGggPSBhcmd2WzRdOw0KICAgIH0NCglpZihhcmdjID4g NSkgew0KICAgICAgICBsb2NhbHBhdGggPSBhcmd2WzVdOw0KICAgIH0NCg0KICAgIC8qDQogICAg ICogVGhlIGFwcGxpY2F0aW9uIGNvZGUgaXMgcmVzcG9uc2libGUgZm9yIGNyZWF0aW5nIHRoZSBz b2NrZXQNCiAgICAgKiBhbmQgZXN0YWJsaXNoaW5nIHRoZSBjb25uZWN0aW9uDQogICAgICovDQog ICAgc29jayA9IHNvY2tldChBRl9JTkVULCBTT0NLX1NUUkVBTSwgMCk7DQoNCiAgICBzaW4uc2lu X2ZhbWlseSA9IEFGX0lORVQ7DQogICAgc2luLnNpbl9wb3J0ID0gaHRvbnMoMjIpOw0KICAgIHNp bi5zaW5fYWRkci5zX2FkZHIgPSBob3N0YWRkcjsNCiAgICBpZiAoY29ubmVjdChzb2NrLCAoc3Ry dWN0IHNvY2thZGRyKikoJnNpbiksDQogICAgICAgICAgICAgICAgc2l6ZW9mKHN0cnVjdCBzb2Nr YWRkcl9pbikpICE9IDApIHsNCiAgICAgICAgZnByaW50ZihzdGRlcnIsICJmYWlsZWQgdG8gY29u bmVjdCFcbiIpOw0KICAgICAgICByZXR1cm4gLTE7DQogICAgfQ0KDQogICAgLyogQ3JlYXRlIGEg c2Vzc2lvbiBpbnN0YW5jZQ0KICAgICAqLw0KICAgIHNlc3Npb24gPSBsaWJzc2gyX3Nlc3Npb25f aW5pdCgpOw0KICAgIGlmKCFzZXNzaW9uKQ0KICAgICAgICByZXR1cm4gLTE7DQoNCiAgICAvKiBT aW5jZSB3ZSBoYXZlIHNldCBub24tYmxvY2tpbmcsIHRlbGwgbGlic3NoMiB3ZSBhcmUgYmxvY2tp bmcgKi8NCiAgICBsaWJzc2gyX3Nlc3Npb25fc2V0X2Jsb2NraW5nKHNlc3Npb24sIDEpOw0KDQog ICAgLyogLi4uIHN0YXJ0IGl0IHVwLiBUaGlzIHdpbGwgdHJhZGUgd2VsY29tZSBiYW5uZXJzLCBl eGNoYW5nZSBrZXlzLA0KICAgICAqIGFuZCBzZXR1cCBjcnlwdG8sIGNvbXByZXNzaW9uLCBhbmQg TUFDIGxheWVycw0KICAgICAqLw0KICAgIHJjID0gbGlic3NoMl9zZXNzaW9uX3N0YXJ0dXAoc2Vz c2lvbiwgc29jayk7DQogICAgaWYocmMpIHsNCiAgICAgICAgZnByaW50ZihzdGRlcnIsICJGYWls dXJlIGVzdGFibGlzaGluZyBTU0ggc2Vzc2lvbjogJWRcbiIsIHJjKTsNCiAgICAgICAgcmV0dXJu IC0xOw0KICAgIH0NCg0KICAgIC8qIEF0IHRoaXMgcG9pbnQgd2UgaGF2bid0IHlldCBhdXRoZW50 aWNhdGVkLiAgVGhlIGZpcnN0IHRoaW5nIHRvIGRvDQogICAgICogaXMgY2hlY2sgdGhlIGhvc3Rr ZXkncyBmaW5nZXJwcmludCBhZ2FpbnN0IG91ciBrbm93biBob3N0cyBZb3VyIGFwcA0KICAgICAq IG1heSBoYXZlIGl0IGhhcmQgY29kZWQsIG1heSBnbyB0byBhIGZpbGUsIG1heSBwcmVzZW50IGl0 IHRvIHRoZQ0KICAgICAqIHVzZXIsIHRoYXQncyB5b3VyIGNhbGwNCiAgICAgKi8NCiAgICBmaW5n ZXJwcmludCA9IGxpYnNzaDJfaG9zdGtleV9oYXNoKHNlc3Npb24sIExJQlNTSDJfSE9TVEtFWV9I QVNIX01ENSk7DQogICAgZnByaW50ZihzdGRlcnIsICJGaW5nZXJwcmludDogIik7DQogICAgZm9y KGkgPSAwOyBpIDwgMTY7IGkrKykgew0KICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIiUwMlggIiwg KHVuc2lnbmVkIGNoYXIpZmluZ2VycHJpbnRbaV0pOw0KICAgIH0NCiAgICBmcHJpbnRmKHN0ZGVy ciwgIlxuIik7DQoNCiAgICAvKiBjaGVjayB3aGF0IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYXJl IGF2YWlsYWJsZSAqLw0KICAgIHVzZXJhdXRobGlzdCA9IGxpYnNzaDJfdXNlcmF1dGhfbGlzdChz ZXNzaW9uLCB1c2VybmFtZSwgc3RybGVuKHVzZXJuYW1lKSk7DQogICAgcHJpbnRmKCJBdXRoZW50 aWNhdGlvbiBtZXRob2RzOiAlc1xuIiwgdXNlcmF1dGhsaXN0KTsNCiAgICBpZiAoc3Ryc3RyKHVz ZXJhdXRobGlzdCwgInBhc3N3b3JkIikgIT0gTlVMTCkgew0KICAgICAgICBhdXRoX3B3IHw9IDE7 DQogICAgfQ0KICAgIGlmIChzdHJzdHIodXNlcmF1dGhsaXN0LCAia2V5Ym9hcmQtaW50ZXJhY3Rp dmUiKSAhPSBOVUxMKSB7DQogICAgICAgIGF1dGhfcHcgfD0gMjsNCiAgICB9DQoNCiAgICAvKiBp ZiB3ZSBnb3QgYW4gNC4gYXJndW1lbnQgd2Ugc2V0IHRoaXMgb3B0aW9uIGlmIHN1cHBvcnRlZCAq LyANCiAgICBpZihhcmdjID4gNikgew0KICAgICAgICBpZiAoKGF1dGhfcHcgJiAxKSAmJiAhc3Ry Y2FzZWNtcChhcmd2WzZdLCAiLXAiKSkgew0KICAgICAgICAgICAgYXV0aF9wdyA9IDE7DQogICAg ICAgIH0NCiAgICAgICAgaWYgKChhdXRoX3B3ICYgMikgJiYgIXN0cmNhc2VjbXAoYXJndls2XSwg Ii1pIikpIHsNCiAgICAgICAgICAgIGF1dGhfcHcgPSAyOw0KICAgICAgICB9DQogICAgfQ0KDQog ICAgaWYgKGF1dGhfcHcgJiAxKSB7DQoJCS8qIFdlIGNvdWxkIGF1dGhlbnRpY2F0ZSB2aWEgcGFz c3dvcmQgKi8NCgkJZnByaW50ZihzdGRlcnIsICJQYXNzd29yZDogJXNcbiIsIHBhc3N3b3JkKTsN CiAgICAgICAgaWYgKGxpYnNzaDJfdXNlcmF1dGhfcGFzc3dvcmQoc2Vzc2lvbiwgdXNlcm5hbWUs IHBhc3N3b3JkKSkgew0KICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJBdXRoZW50aWNhdGlv biBieSBwYXNzd29yZCBmYWlsZWQuXG4iKTsNCiAgICAgICAgICAgIGdvdG8gc2h1dGRvd247DQog ICAgICAgIH0NCiAgICB9IGVsc2UgaWYgKGF1dGhfcHcgJiAyKSB7DQogICAgICAgIC8qIE9yIHZp YSBrZXlib2FyZC1pbnRlcmFjdGl2ZSAqLw0KICAgICAgICBpZiAobGlic3NoMl91c2VyYXV0aF9r ZXlib2FyZF9pbnRlcmFjdGl2ZShzZXNzaW9uLCB1c2VybmFtZSwgJmtiZF9jYWxsYmFjaykgKSB7 DQogICAgICAgICAgICBwcmludGYoIlx0QXV0aGVudGljYXRpb24gYnkga2V5Ym9hcmQtaW50ZXJh Y3RpdmUgZmFpbGVkIVxuIik7DQogICAgICAgICAgICBnb3RvIHNodXRkb3duOw0KICAgICAgICB9 IGVsc2Ugew0KICAgICAgICAgICAgcHJpbnRmKCJcdEF1dGhlbnRpY2F0aW9uIGJ5IGtleWJvYXJk LWludGVyYWN0aXZlIHN1Y2NlZWRlZC5cbiIpOw0KICAgICAgICB9DQogICAgfSBlbHNlIHsNCiAg ICAgICAgcHJpbnRmKCJObyBzdXBwb3J0ZWQgYXV0aGVudGljYXRpb24gbWV0aG9kcyBmb3VuZCFc biIpOw0KICAgICAgICBnb3RvIHNodXRkb3duOw0KICAgIH0NCg0KICAgIGZwcmludGYoc3RkZXJy LCAibGlic3NoMl9zZnRwX2luaXQoKSFcbiIpOw0KICAgIHNmdHBfc2Vzc2lvbiA9IGxpYnNzaDJf c2Z0cF9pbml0KHNlc3Npb24pOw0KDQogICAgaWYgKCFzZnRwX3Nlc3Npb24pIHsNCiAgICAgICAg ZnByaW50ZihzdGRlcnIsICJVbmFibGUgdG8gaW5pdCBTRlRQIHNlc3Npb25cbiIpOw0KICAgICAg ICBnb3RvIHNodXRkb3duOw0KICAgIH0NCg0KCWxpYnNzaDJfdHJhY2Uoc2Vzc2lvbiwgKH4wKSAm IH4oTElCU1NIMl9UUkFDRV9UUkFOUy8qIHwgTElCU1NIMl9UUkFDRV9DT05OKi8pKTsNCg0KICAg IC8qIE9wZW4gbG9jYWwgc291cmNlIGZpbGUgKi8NCg0KCWZwID0gZm9wZW4obG9jYWxwYXRoLCAi cmIiKTsNCglpZiAoIWZwKSB7DQogICAgICAgIGZwcmludGYoc3RkZXJyLCAiVW5hYmxlIHRvIG9w ZW4gbG9jYWwgZmlsZVxuIik7DQogICAgICAgIGdvdG8gc2h1dGRvd247DQogICAgfQ0KDQoJLyog UnVuIHRlc3QgKi8NCg0KCXNmdHBfaGFuZGxlID0NCgkJbGlic3NoMl9zZnRwX29wZW4oDQoJCXNm dHBfc2Vzc2lvbiwgc2Z0cHBhdGgsIExJQlNTSDJfRlhGX1dSSVRFIHwgTElCU1NIMl9GWEZfQ1JF QVQsIA0KCQlMSUJTU0gyX1NGVFBfU19JUlVTUiB8IExJQlNTSDJfU0ZUUF9TX0lXVVNSIHwgTElC U1NIMl9TRlRQX1NfSVJHUlAgfA0KCQlMSUJTU0gyX1NGVFBfU19JUk9USCk7DQoJaWYgKCFzZnRw X2hhbmRsZSkgew0KCQljaGFyICptc2c7DQoJCWZwcmludGYoc3RkZXJyLCAiVW5hYmxlIHRvIG9w ZW4gZmlsZSB3aXRoIFNGVFBcbiIpOw0KCQlsaWJzc2gyX3Nlc3Npb25fbGFzdF9lcnJvcihzZXNz aW9uLCAmbXNnLCBOVUxMLCAwKTsNCgkJZnByaW50ZihzdGRlcnIsICIlc1xuIiwgbXNnKTsNCgkJ ZnByaW50ZihzdGRlcnIsICIlc1xuIiwgbGlic3NoMl92ZXJzaW9uKDApKTsNCgkJZ290byBzaHV0 ZG93bjsNCgl9DQoNCglmb3IgKGludCBpID0gNjAwMDAwMDA7IGkgPCA2MDAwMDAwMDA7IGkrPTEw MDAwMDAwKQ0KCXsNCgkJc2l6ZV90IG53cml0dGVuID0gMDsNCgkJZnByaW50ZihzdGRlcnIsICJ0 cnlpbmcgdG8gd3JpdGUgJWQgYnl0ZXNcbiIsIGkpOw0KDQoJCS8qIFJlYWQgbG9jYWwgZGF0YSBp bnRvIGJ1ZmZlciAqLw0KICAgICAgICBtZW0gPSAoY2hhciAqKW1hbGxvYyhpKTsNCgkJZnNlZWso ZnAsIDAsIFNFRUtfU0VUKTsNCgkJcmMgPSBmcmVhZChtZW0sIDEsIGksIGZwKTsNCgkJaWYgKHJj IDwgaSkgew0KCQkJZnByaW50ZihzdGRlcnIsICJVbmFibGUgdG8gcmVhZCBmcm9tIGxvY2FsIGZp bGU6ICVkXG4iLCByYyk7DQoJCQlnb3RvIHNodXRkb3duOw0KCQl9DQoNCgkJLyogV3JpdGUgdG8g cmVtb3RlIGVuZCAqLw0KCQkvL2xpYnNzaDJfc2Z0cF9zZWVrKHNmdHBfaGFuZGxlLCAwKTsNCg0K CQlkbyB7DQoJCQkvKiB3cml0ZSBkYXRhIGluIGEgbG9vcCB1bnRpbCB3ZSBibG9jayAqLw0KCQkJ ZnByaW50ZihzdGRlcnIsICJ3cml0dGVuICVkIGJ5dGVzIG9mICVkXG4iLCBud3JpdHRlbiwgaSk7 DQoJCQlyYyA9IGxpYnNzaDJfc2Z0cF93cml0ZShzZnRwX2hhbmRsZSwgbWVtICsgbndyaXR0ZW4s IGkgLSBud3JpdHRlbik7DQoJCQlpZihyYyA8IDApIHsNCgkJCQljaGFyICptc2c7DQoJCQkJZnBy aW50ZihzdGRlcnIsICJXUklURSBGQUlMRUQhXG4iKTsNCgkJCQlsaWJzc2gyX3Nlc3Npb25fbGFz dF9lcnJvcihzZXNzaW9uLCAmbXNnLCBOVUxMLCAwKTsNCgkJCQlmcHJpbnRmKHN0ZGVyciwgIiVz XG4iLCBtc2cpOw0KCQkJCWZwcmludGYoc3RkZXJyLCAiJXNcbiIsIGxpYnNzaDJfdmVyc2lvbigw KSk7DQoJCQkJYnJlYWs7DQoJCQl9DQoJCQlud3JpdHRlbiArPSByYzsNCgkJfSB3aGlsZSAobndy aXR0ZW4gPCBpKTsNCg0KICAgICAgICBmcmVlKG1lbSk7DQoJfQ0KDQoJcmMgPSBsaWJzc2gyX3Nm dHBfY2xvc2Uoc2Z0cF9oYW5kbGUpOw0KCWlmIChyYyA8IDApIHsNCgkJY2hhciAqbXNnOw0KCQlm cHJpbnRmKHN0ZGVyciwgImxpYnNzaDJfc2Z0cF9jbG9zZSBGQUlMRUQhXG4iKTsNCgkJbGlic3No Ml9zZXNzaW9uX2xhc3RfZXJyb3Ioc2Vzc2lvbiwgJm1zZywgTlVMTCwgMCk7DQoJCWZwcmludGYo c3RkZXJyLCAiJXNcbiIsIG1zZyk7DQoJCWZwcmludGYoc3RkZXJyLCAiJXNcbiIsIGxpYnNzaDJf dmVyc2lvbigwKSk7DQoJfQ0KDQoJZmNsb3NlKGZwKTsNCiAgICBsaWJzc2gyX3NmdHBfc2h1dGRv d24oc2Z0cF9zZXNzaW9uKTsNCg0KICBzaHV0ZG93bjoNCg0KICAgIGxpYnNzaDJfc2Vzc2lvbl9k aXNjb25uZWN0KHNlc3Npb24sICJOb3JtYWwgU2h1dGRvd24sIFRoYW5rIHlvdSBmb3IgcGxheWlu ZyIpOw0KICAgIGxpYnNzaDJfc2Vzc2lvbl9mcmVlKHNlc3Npb24pOw0KDQojaWZkZWYgV0lOMzIN CiAgICBjbG9zZXNvY2tldChzb2NrKTsNCiNlbHNlDQogICAgY2xvc2Uoc29jayk7DQojZW5kaWYN CiAgICBmcHJpbnRmKHN0ZGVyciwgImFsbCBkb25lXG4iKTsNCiAgICByZXR1cm4gMDsNCn0NCg== --e89a8ff1c0804fa8a304bac5f072 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --e89a8ff1c0804fa8a304bac5f072-- From libssh2-devel-bounces@cool.haxx.se Fri Mar 9 18:16:32 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q29HG7mq003463; Fri, 9 Mar 2012 18:16:28 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q29HG58N003454 for ; Fri, 9 Mar 2012 18:16:06 +0100 Received: (qmail 18388 invoked by uid 501); 9 Mar 2012 17:16:05 -0000 Message-ID: <20120309171605.18387.qmail@stuge.se> Date: Fri, 9 Mar 2012 18:16:05 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: can the agent be freed just after userauth succeeded? Mail-Followup-To: libssh2-devel@cool.haxx.se References: <914A4DD3D02B4499A26BF34C97661D0D@Pippin> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <914A4DD3D02B4499A26BF34C97661D0D@Pippin> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q29HG7mq003463 Ellié Computing Open Source Program wrote: > I am about to add support in libcurl for agent based authentication, > I am missing some information. Is there a list of libssh2_agent_ API > which might return EAGAIN, or might they all return EAGAIN? The man pages do not say? > Once libssh2_agent_userauth succeeded or failed on the last > identity, can I immediately get rid of it with > libssh2_agent_disconnect/free sequence? or do I need to wait for > the end of the channel as in the sample. If you do not want to forward the agent connection then you should be able to close it. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 9 21:11:26 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q29KB4i0003261; Fri, 9 Mar 2012 21:11:20 +0100 Received: from zeus.promailserver.com (zeus.promailserver.com [74.200.236.204]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q29KB2lo003100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Mar 2012 21:11:03 +0100 Received: from Pippin ([83.112.149.63]) by zeus.promailserver.com (Merak 8.3.6) with ASMTP id TXT68755 for ; Fri, 9 Mar 2012 20:10:55 -0000 Message-ID: From: =?UTF-8?Q?Elli=C3=A9_Computing_Open_Source_Prog?= =?UTF-8?Q?ram?= To: "libssh2 development" References: <914A4DD3D02B4499A26BF34C97661D0D@Pippin> <20120309171605.18387.qmail@stuge.se> In-Reply-To: <20120309171605.18387.qmail@stuge.se> Subject: Re: can the agent be freed just after userauth succeeded? Date: Fri, 9 Mar 2012 21:11:01 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id q29KB4i0003261 >Sent: Friday, March 09, 2012 6:16 PM >To: libssh2-devel@cool.haxx.se >Subject: Re: can the agent be freed just after userauth succeeded? > >Ellié Computing Open Source Program wrote: >> I am about to add support in libcurl for agent based authentication, >> I am missing some information. Is there a list of libssh2_agent_ API >> which might return EAGAIN, or might they all return EAGAIN? > >The man pages do not say? for nearly every function, it is just "Returns 0 if succeeded, or a negative value for error" I considered that all but _init and _free could return EAGAIN, it was not too hard to implement that way. From the code in agent.c I realize some are always instant and some are indeed blocking, but at least my code will be OK if it changes. >> Once libssh2_agent_userauth succeeded or failed on the last >> identity, can I immediately get rid of it with >> libssh2_agent_disconnect/free sequence? or do I need to wait for >> the end of the channel as in the sample. > >If you do not want to forward the agent connection then you should be >able to close it. uh, I must admit I just don't know what is forwarding an agent connection, so I believe I can close it :-) Armel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sun Mar 11 07:23:48 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2B6NMeh018071; Sun, 11 Mar 2012 07:23:42 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2B6NJsg018038 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 11 Mar 2012 07:23:20 +0100 Received: by iahk25 with SMTP id k25so5603283iah.41 for ; Sat, 10 Mar 2012 22:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=aooVXOumdIcCk2KGDNdw7qXWs1bcoe2kbdT87Jdw2IQ=; b=EXORknw+LpjDs9d6W7qYRxxISWBTtiXFZoAAKRvRqFq1ANw+djgKJigfZyz/Ecdpsl AOCyhEyCWGrOkQHkK4GsSDiCey1DLUEypilOoFfI5Au7lORiMGaX9vluyp5VusXorKmO BG+iKgCmEFzP3fTui0oVinMeYVBr4jObALap/pBptJY+5BRkv9EJVMGqCzyRBZFDo2NF wrXaPK8ZK5pZii4dh8wtlnzlujsKBq7eGEZULQ+Ta8EPzXe/23NcP8BgfA8rDXKxgqZS cvnQWR72z8yywk/GQhTY2sQsNLD0nSD3yp6hSFsuByssgYTqHqQ+JId5auErAvjePEfh AC2Q== Received: by 10.50.182.197 with SMTP id eg5mr12269609igc.36.1331446994534; Sat, 10 Mar 2012 22:23:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Sat, 10 Mar 2012 22:22:54 -0800 (PST) From: Mitchell Hashimoto Date: Sat, 10 Mar 2012 22:22:54 -0800 X-Google-Sender-Auth: sf8eo2jnFeFk0KyAT52kOO1ZeQM Message-ID: Subject: Getting stream data in order received To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0020783679==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0020783679== Content-Type: multipart/alternative; boundary=14dae9340ac925821604baf1a9d6 --14dae9340ac925821604baf1a9d6 Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm executing a remote program that sends output to both stdout/stderr. Is there a way in libssh2 to receive the output in the order it arrived, rather than as one giant buffer on stdout, then another on stderr, since this is causing out of order results. Best, Mitchell --14dae9340ac925821604baf1a9d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm executing a remote program that sends output= to both stdout/stderr. Is there a way in libssh2 to receive the output in = the order it arrived, rather than as one giant buffer on stdout, then anoth= er on stderr, since this is causing out of order results.

Best,
Mitchell
--14dae9340ac925821604baf1a9d6-- --===============0020783679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0020783679==-- From libssh2-devel-bounces@cool.haxx.se Sun Mar 11 11:58:54 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2BAwRo5006473; Sun, 11 Mar 2012 11:58:48 +0100 Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2BAwNGU006319 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 11 Mar 2012 11:58:25 +0100 Received: by yhgm50 with SMTP id m50so2349583yhg.41 for ; Sun, 11 Mar 2012 03:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=dntwXiyvBdr30nmoxm6/MN3ZrOzZXNKaM5meOViJ+P4=; b=WgajIfMUYIOGg7kXFSOUC7c2ouJvoW+VdYfF+2i39GeyY+JJpVWljei8NagCpBNXeV hTyUXxWqHsGFbmKvrsjMEmSXvX+UlAduwiQJzhjHzZZYHvlQgaY7oY0BMAAgBH0yFgwG 39zP8ZTmctfNKvf6HcmvGZxT5KiJ73HOOK5CxkSJrGildggxidQ/W74g8ir0ZFsJ0TJ2 0je8TZLAudtsT2nUrBDji82e9DYjFTwVKfeLoGr47pC+W+A9d5EB0HMGIbpyNbJpPmYx QAql3gp6IyqSk4hStKgTE3v4bpceZrIGLBRDSKs/YFMpvVZX9k5ouXQGNfBz1AFlSZ+r giMQ== MIME-Version: 1.0 Received: by 10.229.78.159 with SMTP id l31mr1269898qck.114.1331463496194; Sun, 11 Mar 2012 03:58:16 -0700 (PDT) Received: by 10.229.144.211 with HTTP; Sun, 11 Mar 2012 03:58:16 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Mar 2012 10:58:16 +0000 X-Google-Sender-Auth: w5CFH809oQSzRuyGRAFqINB7oz0 Message-ID: Subject: Re: Getting stream data in order received From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 11 March 2012 06:22, Mitchell Hashimoto wrote: > > I'm executing a remote program that sends output to both stdout/stderr. Is > there a way in libssh2 to receive the output in the order it arrived, rather > than as one giant buffer on stdout, then another on stderr, since this is > causing out of order results. That's always going to be a problem, even when you execute the program locally. stdout is buffered and stderr isn't so they don't stay in sync. See http://www.pixelbeat.org/programming/stdio_buffering/ for more. But this is a general unix process issue, nothing to do with libssh2. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sun Mar 11 18:35:54 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2BHZWDM031846; Sun, 11 Mar 2012 18:35:49 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2BHZTlp031781 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 11 Mar 2012 18:35:31 +0100 Received: by iahk25 with SMTP id k25so6410936iah.41 for ; Sun, 11 Mar 2012 10:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=7wAh2q+sMb+vsO//0fdsFYkaGXWk3Ln8NG4LB6DAyDs=; b=XI8Eox9f8bcBOMrmT3wIT4kOd014Oh6ef94R+8cspSnvBx7dLyKw8Q9gH8i8fy+T0u KrataM+PTCbB2rqMDRgED6VcZmtYqJMMCWJnLfl6S9yQTG32lJONZRJnUctaKACz8o0f 0I406u9arS7ADIiKzW7hPRLAtcGh8cgPY0cL9SLzKdpzdmCy9kqhOYwJ3SP+3hKByLry uNSElVUpibACT/wEsNY7Kd1XbKcm7xtzE5Jb0x/UG0kyMy1Y/etteudVynZ5pbUKUx7T G9zADq7hJS/oTucgIf0VyB6FJNGPKByy5XTKkPrhfz16BImKLoYcvniAj+wGdqplPFIH V9ug== Received: by 10.50.37.236 with SMTP id b12mr14953455igk.36.1331487323673; Sun, 11 Mar 2012 10:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Sun, 11 Mar 2012 10:35:03 -0700 (PDT) In-Reply-To: References: From: Mitchell Hashimoto Date: Sun, 11 Mar 2012 10:35:03 -0700 X-Google-Sender-Auth: 0fLXhwrx9X3ERBfHZF2hPiSrOf0 Message-ID: Subject: Re: Getting stream data in order received To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0491108434==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0491108434== Content-Type: multipart/alternative; boundary=f46d044788d9f353a204bafb0c33 --f46d044788d9f353a204bafb0c33 Content-Type: text/plain; charset=ISO-8859-1 Alex, On Sun, Mar 11, 2012 at 3:58 AM, Alexander Lamaison wrote: > On 11 March 2012 06:22, Mitchell Hashimoto > wrote: > > > > I'm executing a remote program that sends output to both stdout/stderr. > Is > > there a way in libssh2 to receive the output in the order it arrived, > rather > > than as one giant buffer on stdout, then another on stderr, since this is > > causing out of order results. > > That's always going to be a problem, even when you execute the program > locally. stdout is buffered and stderr isn't so they don't stay in > sync. See http://www.pixelbeat.org/programming/stdio_buffering/ for > more. But this is a general unix process issue, nothing to do with > libssh2. > > Alex > Certainly, but you can maintain a certain order by doing the equivalent fsync()s with the streams. The main issue I see is that you can only ask for a buffer of data from a stream, where it would be nice to ask "give me all of this stream ID until another stream data packet was seen." Of course this wouldn't _guarantee_ order but it would be more correct. No? Mitchell > > -- > Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > --f46d044788d9f353a204bafb0c33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

On Sun, Mar 11, 2012 at 3:58 AM, Al= exander Lamaison <swish@lammy.co.uk> wrote:
On 11 March 2012 06:22, Mitchell Ha= shimoto <mitchell.hashim= oto@gmail.com> wrote:
>
> I'm executing a remote program that sends output to both stdout/st= derr. Is
> there a way in libssh2 to receive the output in the order it arrived, = rather
> than as one giant buffer on stdout, then another on stderr, since this= is
> causing out of order results.

That's always going to be a problem, even when you execute = the program
locally. =A0stdout is buffered and stderr isn't so they don't stay = in
sync. =A0See http://www.pixelbeat.org/programming/stdio_buffering/= for
more. =A0But this is a general unix process issue, nothing to do with
libssh2.

Alex

Certainly, but you can maintain a = certain order by doing the equivalent fsync()s with the streams.=A0

The main issue I see is that you can only ask for a buffe= r of data from a stream, where it would be nice to ask "give me all of= this stream ID until another stream data packet was seen." Of course = this wouldn't _guarantee_ order but it would be more correct.

No?

Mitchell
=A0

--
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/li= bssh2-devel

--f46d044788d9f353a204bafb0c33-- --===============0491108434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0491108434==-- From libssh2-devel-bounces@cool.haxx.se Sun Mar 11 23:23:07 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2BMMVkn005285; Sun, 11 Mar 2012 23:23:02 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2BMMTmR005277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Mar 2012 23:22:29 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2BMMSoc005274; Sun, 11 Mar 2012 23:22:28 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 11 Mar 2012 23:22:28 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] Tell C compiler we don't care about return code of libssh2_init In-Reply-To: <1331192129-28812-1-git-send-email-sdake@redhat.com> Message-ID: References: <1331192129-28812-1-git-send-email-sdake@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, 8 Mar 2012, Steven Dake wrote: > The call of libssh2_init returns a return code, but nothing could be done > within the _libssh2_init_if_needed execution path. Thanks, merged and pushed! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 07:11:30 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C6B69e005747; Mon, 12 Mar 2012 07:11:25 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C6B3g7005712 for ; Mon, 12 Mar 2012 07:11:04 +0100 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2C6B2rs007637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 02:11:02 -0400 Received: from beast.broked.org.com ([10.3.112.8]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2C6Ax1G007717; Mon, 12 Mar 2012 02:11:01 -0400 From: Steven Dake To: libssh2-devel@cool.haxx.se Subject: [PATCH] Fix suspicious sizeof usage in examples/x11.c Date: Sun, 11 Mar 2012 23:09:09 -0700 Message-Id: <1331532549-20918-1-git-send-email-sdake@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se In the x11 example, sizeof(buf) = 8UL (on x86_64), when this should probably represent the buffer size available. I am not sure how to test that this change is actually correct, however. Signed-off-by: Steven Dake --- example/x11.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/example/x11.c b/example/x11.c index 86dca0f..085b7be 100644 --- a/example/x11.c +++ b/example/x11.c @@ -208,7 +208,7 @@ static int x11_send_receive(LIBSSH2_CHANNEL *channel, int sock) rc = libssh2_poll(fds, nfds, 0); if (rc >0) { - rc = libssh2_channel_read(channel, buf,sizeof(buf)); + rc = libssh2_channel_read(channel, buf, bufsize); rc = write(sock, buf, rc); } -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 07:12:58 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C6Cv7t006748; Mon, 12 Mar 2012 07:12:57 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C6Cs30006698 for ; Mon, 12 Mar 2012 07:12:55 +0100 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2C6CoVL008066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 02:12:50 -0400 Received: from beast.broked.org.com ([10.3.112.8]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2C6CmFI006924; Mon, 12 Mar 2012 02:12:49 -0400 From: Steven Dake To: libssh2-devel@cool.haxx.se Subject: [PATCH] In examples/x11.c, Make sure sizeof passed to read operation is correct Date: Sun, 11 Mar 2012 23:10:58 -0700 Message-Id: <1331532658-21099-1-git-send-email-sdake@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se sizeof(buf) expands to 8ULL (since its a pointer). This variable may have been static in the past, leading to this error. Signed-off-by: Steven Dake --- example/x11.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/example/x11.c b/example/x11.c index 085b7be..6480dc8 100644 --- a/example/x11.c +++ b/example/x11.c @@ -217,7 +217,7 @@ static int x11_send_receive(LIBSSH2_CHANNEL *channel, int sock) memset((void *)buf,0,bufsize); /* Data in sock*/ - rc = read(sock, buf,sizeof(buf)); + rc = read(sock, buf, bufsize); if (rc > 0) rc = libssh2_channel_write(channel,buf, rc); else -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 07:20:09 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C6K6Qj011764; Mon, 12 Mar 2012 07:20:08 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C6K4e2011653 for ; Mon, 12 Mar 2012 07:20:04 +0100 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2C6K311010391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 02:20:03 -0400 Received: from beast.broked.org ([10.3.112.8]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2C6K2c0009688 for ; Mon, 12 Mar 2012 02:20:02 -0400 Message-ID: <4F5D9525.4080804@redhat.com> Date: Sun, 11 Mar 2012 23:18:13 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Question about kex.c:1868 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hi, Not entirely sure how this code snippet is supposed to work, but is it possible that the following could happen: method_type = LIBSSH2_METHOD_LANG_CS or LANG_SC (this sets mlist to NULL) mlist passed in as NULL to 3rd parameter of kex_get_method_by_name resulting in segfault from null dereference? Regards -steve _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 11:00:05 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C9xcdZ031358; Mon, 12 Mar 2012 11:00:00 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2C9wNCq030527 for ; Mon, 12 Mar 2012 10:58:23 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id 23BF91F29D1 for ; Mon, 12 Mar 2012 10:58:24 +0100 (MET) Received: from erebus.got.appgate.com (erebus.got.appgate.com [172.23.2.58]) by krakatau.got.appgate.com (Postfix) with ESMTP id 18932BD4057 for ; Mon, 12 Mar 2012 10:58:24 +0100 (CET) Message-ID: <4F5DC8BF.8030406@cryptzone.com> Date: Mon, 12 Mar 2012 10:58:23 +0100 From: Tom Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: libssh2 development Subject: Re: Callback for channel data ready References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Another question regarding the channel data queue. Is there a risk that we could miss incoming data which is received during the query-loop? Imagine the following situation: 1. poll() indicates POLLIN on the session socket. 2. The application checks channel #1, no data is waiting. 3. The application checks channel #2, no data is waiting, but libssh2 receives data for channel #1. 4. poll() sits around waiting, while we need the channel #1 data to carry on the conversation. We have seen delays in traffic now and then, and I wonder if this is the reason. If so, can you recommend a workaround? Looping one more time wouldn't change the situation. A dirty workaround I can think of is to register a snooping recv() callback and keep looping until recv() hasn't received anything during a loop. -- Best Regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 11:15:52 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CAFkFB014212; Mon, 12 Mar 2012 11:15:51 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CAFiOK014171 for ; Mon, 12 Mar 2012 11:15:44 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id 8B76F1F29C6 for ; Mon, 12 Mar 2012 11:15:45 +0100 (MET) Received: from erebus.got.appgate.com (erebus.got.appgate.com [172.23.2.58]) by krakatau.got.appgate.com (Postfix) with ESMTP id 834D7BD4057 for ; Mon, 12 Mar 2012 11:15:45 +0100 (CET) Message-ID: <4F5DCCD1.9090502@cryptzone.com> Date: Mon, 12 Mar 2012 11:15:45 +0100 From: Tom Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: libssh2 development Subject: Re: Callback for channel data ready References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> In-Reply-To: <4F5DC8BF.8030406@cryptzone.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Tom Weber skrev 3/12/12 10:58 AM: > Another question regarding the channel data queue. Is there a risk that > we could miss incoming data which is received during the query-loop? > Imagine the following situation: > > 1. poll() indicates POLLIN on the session socket. > > 2. The application checks channel #1, no data is waiting. > > 3. The application checks channel #2, no data is waiting, but libssh2 > receives data for channel #1. > > 4. poll() sits around waiting, while we need the channel #1 data to > carry on the conversation. > > We have seen delays in traffic now and then, and I wonder if this is the > reason. If so, can you recommend a workaround? Looping one more time > wouldn't change the situation. A dirty workaround I can think of is to > register a snooping recv() callback and keep looping until recv() hasn't > received anything during a loop. > After looking at the API, I think I have found a solution. libssh2_channel_window_read_ex() can check if there is data waiting on a channel, without reading from the socket. So we would have to run a libssh2_channel_window_read_ex() loop after each libssh2_channel_read_ex() loop, and repeat both loops until libssh2_channel_window_read_ex() returns zero for all channels. -- Best Regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 12:40:36 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CBeJCR012184; Mon, 12 Mar 2012 12:40:32 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CBeH8p012161 for ; Mon, 12 Mar 2012 12:40:18 +0100 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2CBeG3U024190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Mar 2012 07:40:17 -0400 Received: from t500.mbooth (ovpn-116-56.ams2.redhat.com [10.36.116.56]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2CBeFWx027864 for ; Mon, 12 Mar 2012 07:40:16 -0400 Message-ID: <4F5DE09F.5070804@redhat.com> Date: Mon, 12 Mar 2012 11:40:15 +0000 From: Matthew Booth Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2-devel@cool.haxx.se Subject: Unchecked error in _libssh2_channel_write causes infinite loop X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se I've been encountering an issue in my application where it reliably gets into an infinite loop part way through a very large data transfer. The application is exclusively sending data during the transfer. The problem seems to relate to a transport error which I haven't yet gotten to the bottom of. However, the infinite loop seems to be down to an unchecked error in _libssh2_channel_write(): /* drain the incoming flow first, mostly to make sure we get all * pending window adjust packets */ do rc = _libssh2_transport_read(session); while (rc > 0); if(channel->local.window_size <= 0) /* there's no room for data so we stop */ return (rc==LIBSSH2_ERROR_EAGAIN?rc:0); In my case, _libssh2_transport_read is returning LIBSSH2_ERROR_SOCKET_RECV (don't know why yet). The result of this in the above code is that _libssh2_channel_write returns 0, throwing away the error information. My code spots a zero return, checks for eof, doesn't find one and goes round again: infinite loop. I would just submit a patch which adds "if (rc<0) return rc;" immediately after the read loop, but it seems like the author has intentionally not done this here. Git commit 3c71ad4fce745876f7e7ad33b846518f2d50edf6 and its associated mailing list thread doesn't shed any light on why only EAGAIN is handled. Can anybody explain? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 18:44:47 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CHiLnR019513; Mon, 12 Mar 2012 18:44:41 +0100 Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CHiIXw019463 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 12 Mar 2012 18:44:19 +0100 Received: by yhgm50 with SMTP id m50so3586069yhg.41 for ; Mon, 12 Mar 2012 10:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=a4O49uQqCUVZg5btyafnPoIv2HvVwL3TLRp1Q0JeXXw=; b=q2G9sLRHpvSKeCUydUuGsw/LbFrzzC8GdrM8ub/FyeD++dDlLCh+AbBLPyqRq/tAVh 8RuTUcJb6mY+fJuhdFfD48cKGUlOxACHfmadM6YSNLUPtSM7hlD1Ki+kvS/FyDNR35Pj vmwDpJp1KkgZSbkjxWH00KL0NvTN5+VAOiFvmyCWoj+h0LVCruxhUMgPPt1/3fQtT04/ NhcKahKmS85NOdvFmQigkG8TmFjVe/ERQmP2Y420QJoOztkgGNC00eGUmjHcmu6WSPUN ps/vo8KToyLqdT3QFtr8jks39Y63uUTNKtkdiqvNfk1jTXfpwTeX1V8WTpzbzFTqOCtY yE0A== MIME-Version: 1.0 Received: by 10.68.136.228 with SMTP id qd4mr2238578pbb.141.1331574253669; Mon, 12 Mar 2012 10:44:13 -0700 (PDT) Received: by 10.142.52.20 with HTTP; Mon, 12 Mar 2012 10:44:13 -0700 (PDT) Date: Mon, 12 Mar 2012 12:44:13 -0500 Message-ID: Subject: sftp problem reading large directories From: E L To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0329027182==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0329027182== Content-Type: multipart/alternative; boundary=047d7b10cff161cc5504bb0f4a3f --047d7b10cff161cc5504bb0f4a3f Content-Type: text/plain; charset=ISO-8859-1 I recently updated to 1.4 of libssh2 and now read of large directories causes my application (and the sftpdir.c example) to hang. It appears to be an issue with the recent change to move the window adjustment from channel.c to the calling function. The sftp_read() function now calls _libssh2_channel_receive_window_adjust(), but there is nothing in sftp_readdir(). The source just before this commit works for me http://git.libssh2.org/?p=libssh2.git;a=commitdiff;h=03ca9020756a4e16f0294e5b35e9826ee6af2364 Eric --047d7b10cff161cc5504bb0f4a3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I recently updated to 1.4 of libssh2 and now read of large directories=20 causes my application (and the sftpdir.c example) to hang.

It appear= s to be an issue with the recent change to move the window adjustment from = channel.c to the calling function.
The sftp_read() function now calls _libssh2_channel_receive_window_adjust()= , but there is nothing in sftp_readdir().
--047d7b10cff161cc5504bb0f4a3f-- --===============0329027182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0329027182==-- From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 19:27:01 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CIQro4019080; Mon, 12 Mar 2012 19:27:00 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CIQp9G019066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Mar 2012 19:26:51 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2CIQpg7019062 for ; Mon, 12 Mar 2012 19:26:51 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 12 Mar 2012 19:26:51 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: sftp problem reading large directories In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Mon, 12 Mar 2012, E L wrote: > It appears to be an issue with the recent change to move the window > adjustment from channel.c to the calling function. The sftp_read() function > now calls _libssh2_channel_receive_window_adjust(), but there is nothing in > sftp_readdir(). Oops. My fault. I'll write up a fix soonish! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 12 22:58:17 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CLvYw0004309; Mon, 12 Mar 2012 22:58:13 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2CLvWvj004289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Mar 2012 22:57:32 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2CLvWOO004285 for ; Mon, 12 Mar 2012 22:57:32 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 12 Mar 2012 22:57:32 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: sftp problem reading large directories In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Mon, 12 Mar 2012, Daniel Stenberg wrote: >> It appears to be an issue with the recent change to move the window >> adjustment from channel.c to the calling function. The sftp_read() function >> now calls _libssh2_channel_receive_window_adjust(), but there is nothing in >> sftp_readdir(). > > Oops. My fault. I'll write up a fix soonish! Thanks for a good report. I used this script: #!/usr/bin/perl my $l= 'A' x 100; foreach my $i (0 .. 100000) { my $name = $i.$l; open(F, ">$name") or die "stupid program: $!"; print F $name; close(F); } ... and could easily repeat this problem locally. I then wrote a fix that properly sends updated window size to the remote. I've now pushed my fix to the git repo using hash 7194a9bd7ba45. I'll appreciate if you test it and give us your comments! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 01:05:49 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2D05bfc006791; Tue, 13 Mar 2012 01:05:47 +0100 Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2D05XmR006753 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Mar 2012 01:05:34 +0100 Received: by yenl9 with SMTP id l9so4073593yen.41 for ; Mon, 12 Mar 2012 17:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=hO7C6f+tb6qJQwD99TXuB4YvvywxgJ8b9S8M5yaR/MU=; b=YiQGtcX9v1iXYx2hrh17EQvkaSJmQKD9HP8ANWU8R/VFzVW7RjP6OcylP5ZVebRe5X IBi6hxAsFcQphTE4bEjobI4zgiuYzpcDrmhHo7L4OuvFonrNEUd8TYohezEIMNTMLyxf ZfNP8TGItrLKSpyb1UC62epcHHZ5wmPOm9mv16YF0OdM0y+EHg8ZgYZAtYTWvu/LgsKs puPhud+iSF/15kPHqMFF8MYXInkzE5Ob2In0kueLHuOvU7yDafUbfaB99dkwl4SJOHUe 3jIglCIU4O8RgasHl5bBlXMFUvFPXnIU4mImuQ1GBjGfZunA+FrXv3NqozQUVHMdI8Wq ZpPA== Received: by 10.236.161.72 with SMTP id v48mr5915848yhk.112.1331597128163; Mon, 12 Mar 2012 17:05:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.164.11 with HTTP; Mon, 12 Mar 2012 17:05:07 -0700 (PDT) From: Mitchell Hashimoto Date: Mon, 12 Mar 2012 17:05:07 -0700 X-Google-Sender-Auth: LnM32zoBPpYvpGd5TitsaTRGMsA Message-ID: Subject: Send custom requests To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0529448542==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0529448542== Content-Type: multipart/alternative; boundary=20cf302ef83ecee0dc04bb149d8a --20cf302ef83ecee0dc04bb149d8a Content-Type: text/plain; charset=ISO-8859-1 Hello, I'd like to have the option to enable SSH agent forwarding in my app that uses libssh2. Based on this RFC[1] it seems simple enough, but it requires that a send a couple custom SSH request packets. As far as I know, libssh2 does not expose a way to send custom request packet types. Would it be okay for this to be exposed? Best, Mitchell [1]: http://tools.ietf.org/html/draft-ietf-secsh-agent-02 --20cf302ef83ecee0dc04bb149d8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I'd like to have the option to enable SSH age= nt forwarding in my app that uses libssh2. Based on this RFC[1] it seems si= mple enough, but it requires that a send a couple custom SSH request packet= s. As far as I know, libssh2 does not expose a way to send custom request p= acket types. Would it be okay for this to be exposed?

Best,
Mitchell


<= /div> --20cf302ef83ecee0dc04bb149d8a-- --===============0529448542== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0529448542==-- From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 13:55:28 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DCsw3E021700; Tue, 13 Mar 2012 13:55:22 +0100 Received: from mail-pz0-f42.google.com (mail-pz0-f42.google.com [209.85.210.42]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DCssYU021668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Mar 2012 13:54:55 +0100 Received: by dang27 with SMTP id g27so820674dan.15 for ; Tue, 13 Mar 2012 05:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XOL0+e2iu3m5qn8VsYOusKaXBdlAfz6KtWWqOgltdP8=; b=mqby7MoIAewVipqaGVppmUra+FJklxhHW0XP6X+xjymtK7RBS9WKNnIVAWSzmYzHyB CnBiupRRcw/Ai7mzYygQNFe3XGgEtCJTUqFMZh63YF9IdKxcUfxMFwytojk53sEWIKGE R9LCgNRtahUx6uyAVPU/NyKbSDegaz9d2UFCRLRp7pnIQ8rSr7/JERwJAMH84aS7fyDl 2m3TG98bA26POHIoiEOKF1JXfdcILvVqEqHSKyUunKnuntDTf5Dsj+5pQy9kxSGbEBS7 uIh0OMLov/zSI73vPdIuURDlPpOoETXChiousSgERl9k6vI870DRTsZdq+9SW7sk2Kwv pDug== MIME-Version: 1.0 Received: by 10.68.237.66 with SMTP id va2mr6256024pbc.32.1331643289979; Tue, 13 Mar 2012 05:54:49 -0700 (PDT) Received: by 10.142.52.20 with HTTP; Tue, 13 Mar 2012 05:54:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 07:54:49 -0500 Message-ID: Subject: Re: sftp problem reading large directories From: E L To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0155233543==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0155233543== Content-Type: multipart/alternative; boundary=047d7b33d652444a5a04bb1f5dd6 --047d7b33d652444a5a04bb1f5dd6 Content-Type: text/plain; charset=ISO-8859-1 That worked for me. Thanks for the quick response. Eric On Mon, Mar 12, 2012 at 4:57 PM, Daniel Stenberg wrote: > On Mon, 12 Mar 2012, Daniel Stenberg wrote: > > It appears to be an issue with the recent change to move the window >>> adjustment from channel.c to the calling function. The sftp_read() function >>> now calls _libssh2_channel_receive_**window_adjust(), but there is >>> nothing in sftp_readdir(). >>> >> >> Oops. My fault. I'll write up a fix soonish! >> > > Thanks for a good report. I used this script: > > #!/usr/bin/perl > > my $l= 'A' x 100; > foreach my $i (0 .. 100000) { > my $name = $i.$l; > open(F, ">$name") or die "stupid program: $!"; > print F $name; > close(F); > } > > ... and could easily repeat this problem locally. I then wrote a fix that > properly sends updated window size to the remote. I've now pushed my fix to > the git repo using hash 7194a9bd7ba45. > > I'll appreciate if you test it and give us your comments! > > > -- > > / daniel.haxx.se > ______________________________**_________________ > libssh2-devel http://cool.haxx.se/cgi-bin/**mailman/listinfo/libssh2-devel > --047d7b33d652444a5a04bb1f5dd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That worked for me.=A0 Thanks for the quick response.

Eric

On Mon, Mar 12, 2012 at 4:57 PM, Daniel Stenbe= rg <daniel@haxx.se> wrote:
On Mon, 12 Mar 2012, Danie= l Stenberg wrote:

It appears to be an issue with the recent change to move the window adjustm= ent from channel.c to the calling function. The sftp_read() function now ca= lls _libssh2_channel_receive_window_adjust(), but there is nothing i= n sftp_readdir().

Oops. My fault. I'll write up a fix soonish!

Thanks for a good report. I used this script:

=A0#!/usr/bin/perl

=A0my $l=3D 'A' x 100;
=A0foreach my $i (0 .. 100000) {
=A0 =A0 =A0my $name =3D $i.$l;
=A0 =A0 =A0open(F, ">$name") or die "stupid program: $!&= quot;;
=A0 =A0 =A0print F $name;
=A0 =A0 =A0close(F);
=A0}

... and could easily repeat this problem locally. I then wrote a fix that p= roperly sends updated window size to the remote. I've now pushed my fix= to the git repo using hash 7194a9bd7ba45.

I'll appreciate if you test it and give us your comments!


--

=A0/ daniel.haxx.se=
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/list= info/libssh2-devel

--047d7b33d652444a5a04bb1f5dd6-- --===============0155233543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0155233543==-- From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 15:53:07 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DEqoNG006046; Tue, 13 Mar 2012 15:53:04 +0100 Received: from mail-pz0-f42.google.com (mail-pz0-f42.google.com [209.85.210.42]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DEqkw1005986 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 13 Mar 2012 15:52:47 +0100 Received: by dang27 with SMTP id g27so985603dan.15 for ; Tue, 13 Mar 2012 07:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=wh6S6ewh0Rrb2sJ3ZYeXJwX3YITdNIH/qBmDeF4w+p4=; b=wkfL0ZOVBAqZ9Drm4pbo+RWnYU85sWQKsIixIT1MY3rw8VcIlNn46aFtQaE48qhWql Ocqe+SYCdru/S0TtHT1E2bncCmR+YPDfdkVzGCXFchQ5sGGVdMR0zrXaygz/FJrry/yY quUaH998hnnmLV9ctUmycn85UIJuqL6Ws54oLP8m/ggQIhNqvkqiQT8EGP3zYYinSUou wqmFH5KH98RWJocSKcNMcpVUwpW1u1QJHU9zkr2ODMoLMrS2+2qSZMjK8Nq9SxT5YgTZ E2E2CYB1Hs5D37oHYonOnLbN5q+Y6ZBbf7SqUwS1TwF9jDk50LFqMWvp1kEIaFrAzduG G3NQ== MIME-Version: 1.0 Received: by 10.68.224.233 with SMTP id rf9mr6485801pbc.162.1331650360982; Tue, 13 Mar 2012 07:52:40 -0700 (PDT) Received: by 10.142.52.20 with HTTP; Tue, 13 Mar 2012 07:52:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 09:52:40 -0500 Message-ID: Subject: Re: sftp problem reading large directories From: E L To: libssh2 development X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2DEqkw1005986 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2DEqoNG006046 > On Mon, Mar 12, 2012 at 4:57 PM, Daniel Stenberg wrote: >> >> On Mon, 12 Mar 2012, Daniel Stenberg wrote: >> >>>> It appears to be an issue with the recent change to move the window adjustment from channel.c to the calling function. The sftp_read() function now calls _libssh2_channel_receive_window_adjust(), but there is nothing in sftp_readdir(). >>> >>> >>> Oops. My fault. I'll write up a fix soonish! >> >> >> Thanks for a good report. I used this script: >> >>  #!/usr/bin/perl >> >>  my $l= 'A' x 100; >>  foreach my $i (0 .. 100000) { >>      my $name = $i.$l; >>      open(F, ">$name") or die "stupid program: $!"; >>      print F $name; >>      close(F); >>  } >> >> ... and could easily repeat this problem locally. I then wrote a fix that properly sends updated window size to the remote. I've now pushed my fix to the git repo using hash 7194a9bd7ba45. >> >> I'll appreciate if you test it and give us your comments! >> I spoke a little too soon. The reading of large directories is working, but now the read of large files is not working for one server (GlobalScape). Something appears to get corrupted because after receiving about 650k out of 15M, one packet length comes back completely bogus. [libssh2] 14.210771 Transport: Packet type 94 received, length=118 [libssh2] 14.210771 Conn: 109 bytes packet_add() for 0/0/0 [libssh2] 14.210771 Conn: channel_read() got 2009 of data from 0/0/0 [libssh2] 14.210771 SFTP: Received packet 60 (len 2009) [libssh2] 14.210771 SFTP: recv packet [libssh2] 14.210771 Conn: channel_read() got 4 of data from 0/0/0 [libssh2] 14.210771 SFTP: Data begin - Packet Length: 1668048225 [libssh2] 14.210771 Failure Event: -25 - SFTP packet too large (I moved the debug line for Packet Length so I could see the value before the error) I'm not sure if this is the cause of what I'm seeing, but if the code in sftp_packet_read() jumps to window_adjust, the packet buffer will not be initialized but the execution can still continue to where packet is used. Eric _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 16:49:17 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DFn50M013006; Tue, 13 Mar 2012 16:49:15 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2DFn1lT012881 for ; Tue, 13 Mar 2012 16:49:01 +0100 Received: (qmail 11716 invoked by uid 501); 13 Mar 2012 15:49:02 -0000 Message-ID: <20120313154902.11715.qmail@stuge.se> Date: Tue, 13 Mar 2012 16:49:02 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: sftp problem reading large directories Mail-Followup-To: libssh2-devel@cool.haxx.se References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se E L wrote: > Something appears to get corrupted because after receiving about > 650k out of 15M, one packet length comes back completely bogus. > > [libssh2] 14.210771 Transport: Packet type 94 received, length=118 > [libssh2] 14.210771 Conn: 109 bytes packet_add() for 0/0/0 > [libssh2] 14.210771 Conn: channel_read() got 2009 of data from 0/0/0 > [libssh2] 14.210771 SFTP: Received packet 60 (len 2009) > [libssh2] 14.210771 SFTP: recv packet > [libssh2] 14.210771 Conn: channel_read() got 4 of data from 0/0/0 > [libssh2] 14.210771 SFTP: Data begin - Packet Length: 1668048225 > [libssh2] 14.210771 Failure Event: -25 - SFTP packet too large Unfortunately this is fairly useless output. Please set trace level to ~0 and send complete debug output. Thanks! > I'm not sure if this is the cause of what I'm seeing, but if the code > in sftp_packet_read() jumps to window_adjust, the packet buffer will > not be initialized but the execution can still continue to where > packet is used. Do you have a simple fix? :) //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 16:55:11 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DFswT0016459; Tue, 13 Mar 2012 16:55:09 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DFstBm016442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Mar 2012 16:54:55 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2DFstHX016437 for ; Tue, 13 Mar 2012 16:54:55 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 13 Mar 2012 16:54:54 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: sftp problem reading large directories In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Tue, 13 Mar 2012, E L wrote: > I'm not sure if this is the cause of what I'm seeing, but if the code in > sftp_packet_read() jumps to window_adjust, the packet buffer will not be > initialized but the execution can still continue to where packet is used. Ah yes I see, thanks! I'll work on an update. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 22:06:44 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DL6KJW026146; Tue, 13 Mar 2012 22:06:40 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DL6IoL026111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Mar 2012 22:06:18 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2DL6ILW026106 for ; Tue, 13 Mar 2012 22:06:18 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 13 Mar 2012 22:06:18 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: sftp problem reading large directories In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Tue, 13 Mar 2012, E L wrote: > I spoke a little too soon. The reading of large directories is working, but > now the read of large files is not working for one server (GlobalScape). > Something appears to get corrupted because after receiving about 650k out of > 15M, one packet length comes back completely bogus. Ok, one more try. I just pushed commit bf097e37b01dc9ef which is an additional change on top of the previous to make sure sftp_packet_read() does the right thing. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 22:22:16 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DLMBax006407; Tue, 13 Mar 2012 22:22:15 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DLM97x006384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Mar 2012 22:22:09 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2DLM9ff006381; Tue, 13 Mar 2012 22:22:09 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 13 Mar 2012 22:22:09 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] In examples/x11.c, Make sure sizeof passed to read operation is correct In-Reply-To: <1331532658-21099-1-git-send-email-sdake@redhat.com> Message-ID: References: <1331532658-21099-1-git-send-email-sdake@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Cc: Steven Dake X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sun, 11 Mar 2012, Steven Dake wrote: > sizeof(buf) expands to 8ULL (since its a pointer). This variable may have > been static in the past, leading to this error. Thanks, both your x11 cleanups have now been pushed. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 22:29:18 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DLTFg0012760; Tue, 13 Mar 2012 22:29:18 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DLTEcM012697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Mar 2012 22:29:14 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2DLTE8Y012693 for ; Tue, 13 Mar 2012 22:29:14 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 13 Mar 2012 22:29:14 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Question about kex.c:1868 In-Reply-To: <4F5D9525.4080804@redhat.com> Message-ID: References: <4F5D9525.4080804@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sun, 11 Mar 2012, Steven Dake wrote: > Not entirely sure how this code snippet is supposed to work, but is it > possible that the following could happen: > > method_type = LIBSSH2_METHOD_LANG_CS or LANG_SC > > (this sets mlist to NULL) > > mlist passed in as NULL to 3rd parameter of kex_get_method_by_name resulting > in segfault from null dereference? I tracked down the origin of that code. It was added Dec 9 2004 by Sara and was never really changed since (just re-indented and white-space modified). I suggest we add a check for it so that we're _sure_ it can't happen. Or what do you think? -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Mar 13 23:54:22 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DMsAXF010707; Tue, 13 Mar 2012 23:54:19 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DMs7rb010682 for ; Tue, 13 Mar 2012 23:54:07 +0100 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2DMs772000673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Mar 2012 18:54:07 -0400 Received: from beast.broked.org ([10.3.112.2]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2DMs6pt009624; Tue, 13 Mar 2012 18:54:06 -0400 Message-ID: <4F5FCF9E.2080003@redhat.com> Date: Tue, 13 Mar 2012 15:52:14 -0700 From: Steven Dake User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Re: Question about kex.c:1868 References: <4F5D9525.4080804@redhat.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: Daniel Stenberg X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 03/13/2012 02:29 PM, Daniel Stenberg wrote: > On Sun, 11 Mar 2012, Steven Dake wrote: > >> Not entirely sure how this code snippet is supposed to work, but is it >> possible that the following could happen: >> >> method_type = LIBSSH2_METHOD_LANG_CS or LANG_SC >> >> (this sets mlist to NULL) >> >> mlist passed in as NULL to 3rd parameter of kex_get_method_by_name >> resulting in segfault from null dereference? > > I tracked down the origin of that code. It was added Dec 9 2004 by Sara > and was never really changed since (just re-indented and white-space > modified). > > I suggest we add a check for it so that we're _sure_ it can't happen. Or > what do you think? > An assert would make sense (since we want to assert that something doesn't happen rather then having it happen and resulting in segfault), although asserts inside libraries are a bit evil. Another option is return an error code, but not sure how that would be passable by the api callers. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 14 00:05:26 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DN5LqJ018655; Wed, 14 Mar 2012 00:05:25 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DN5J8S018645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Mar 2012 00:05:19 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2DN5JTl018640 for ; Wed, 14 Mar 2012 00:05:19 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Wed, 14 Mar 2012 00:05:19 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Send custom requests In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Mon, 12 Mar 2012, Mitchell Hashimoto wrote: > I'd like to have the option to enable SSH agent forwarding in my app that > uses libssh2. Based on this RFC[1] it seems simple enough, but it requires > that a send a couple custom SSH request packets. As far as I know, libssh2 > does not expose a way to send custom request packet types. Would it be okay > for this to be exposed? Our "normal" approach has been to add API calls for the special packets we need so that applications won't need to known and care for SSH related binary protocol details. Don't you think that would be better suited for this case as well? In general I'm not really against a way to send "raw" SSH channel packets I'm just not sure people really want to use one. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 14 00:13:29 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DNDNce022247; Wed, 14 Mar 2012 00:13:27 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2DNDMSi022238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Mar 2012 00:13:22 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2DNDMen022235 for ; Wed, 14 Mar 2012 00:13:22 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Wed, 14 Mar 2012 00:13:22 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Unchecked error in _libssh2_channel_write causes infinite loop In-Reply-To: <4F5DE09F.5070804@redhat.com> Message-ID: References: <4F5DE09F.5070804@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Mon, 12 Mar 2012, Matthew Booth wrote: > seems to be down to an unchecked error in _libssh2_channel_write(): > > /* drain the incoming flow first, mostly to make sure we get all > * pending window adjust packets */ > do > rc = _libssh2_transport_read(session); > while (rc > 0); > > if(channel->local.window_size <= 0) > /* there's no room for data so we stop */ > return (rc==LIBSSH2_ERROR_EAGAIN?rc:0); > > In my case, _libssh2_transport_read is returning LIBSSH2_ERROR_SOCKET_RECV > (don't know why yet). The result of this in the above code is that > _libssh2_channel_write returns 0, throwing away the error information. My > code spots a zero return, checks for eof, doesn't find one and goes round > again: infinite loop. > > I would just submit a patch which adds "if (rc<0) return rc;" immediately > after the read loop, but it seems like the author has intentionally not done > this here. Git commit 3c71ad4fce745876f7e7ad33b846518f2d50edf6 and its > associated mailing list thread doesn't shed any light on why only EAGAIN is > handled. Can anybody explain? I think I only added code to handle the EAGAIN case since that was the particular case I was out to fix and I played safe and didn't modify the other cases. But I agree that it looks wrong. I would probably suggest this change as a slight variation of your suggestion: diff --git a/src/channel.c b/src/channel.c index 8d6fb0a..9e29492 100644 --- a/src/channel.c +++ b/src/channel.c @@ -2008,6 +2008,9 @@ _libssh2_channel_write(LIBSSH2_CHANNEL *channel, int strea rc = _libssh2_transport_read(session); while (rc > 0); + if((rc < 0) && (rc != LIBSSH2_ERROR_EAGAIN)) + return rc; + if(channel->local.window_size <= 0) /* there's no room for data so we stop */ return (rc==LIBSSH2_ERROR_EAGAIN?rc:0); The existing code continues even if LIBSSH2_ERROR_EAGAIN was returned as long as there is window size to go with so we should probably continue doing so. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 14 17:59:42 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2EGxCRK010225; Wed, 14 Mar 2012 17:59:32 +0100 Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2EGx8dl010172 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 14 Mar 2012 17:59:10 +0100 Received: by ghrr20 with SMTP id r20so2439683ghr.41 for ; Wed, 14 Mar 2012 09:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wm0y6zSA3rbLUlb/+70gCObzOCueUaHkLls0JW/XBOg=; b=KAJ3ecC8vxjJIKTXrTOxMEukKve5slrhBvj8g66PlYJHUWgXTVlHLB1NXsHh19zULR 4EdvtYX66iQQxEslDBTeIocXHTl6sVi3/Or68wup2KJaBTjsVIcs37+9du+GE3QM1eae VSJKDAAmXTy/4vCsdx8rhsp9ShChTkiJW6QhtXWyGwXwnSQLxdBRvHnys88GjQrNBs+R nJ7mxRRQYehYl7pOdddDvapPpTYjOuZKspiwYEXBKuJlG6ZTUcodayNskGjDD5nt7sCG BPUGrr73E8xOxwApBob7zgHQ61dkMrn1vno+iXz2jC/ZCVm4+coefSsKzxdx5BRlga4L pKBQ== MIME-Version: 1.0 Received: by 10.68.136.228 with SMTP id qd4mr3339662pbb.141.1331734955374; Wed, 14 Mar 2012 07:22:35 -0700 (PDT) Received: by 10.143.41.11 with HTTP; Wed, 14 Mar 2012 07:22:35 -0700 (PDT) In-Reply-To: <20120313154902.11715.qmail@stuge.se> References: <20120313154902.11715.qmail@stuge.se> Date: Wed, 14 Mar 2012 09:22:35 -0500 Message-ID: Subject: Re: sftp problem reading large directories From: E L To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Tue, Mar 13, 2012 at 10:49 AM, Peter Stuge wrote: > E L wrote: >> Something appears to get corrupted because after receiving about >> 650k out of 15M, one packet length comes back completely bogus. >> >> [libssh2] 14.210771 Transport: Packet type 94 received, length=118 >> [libssh2] 14.210771 Conn: 109 bytes packet_add() for 0/0/0 >> [libssh2] 14.210771 Conn: channel_read() got 2009 of data from 0/0/0 >> [libssh2] 14.210771 SFTP: Received packet 60 (len 2009) >> [libssh2] 14.210771 SFTP: recv packet >> [libssh2] 14.210771 Conn: channel_read() got 4 of data from 0/0/0 >> [libssh2] 14.210771 SFTP: Data begin - Packet Length: 1668048225 >> [libssh2] 14.210771 Failure Event: -25 - SFTP packet too large > > Unfortunately this is fairly useless output. Please set trace level > to ~0 and send complete debug output. Thanks! > > >> I'm not sure if this is the cause of what I'm seeing, but if the code >> in sftp_packet_read() jumps to window_adjust, the packet buffer will >> not be initialized but the execution can still continue to where >> packet is used. > > Do you have a simple fix? :) Daniel was already quick with the fix. Thanks. Eric _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 14 18:06:43 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2EH6d0k016123; Wed, 14 Mar 2012 18:06:42 +0100 Received: from mail-pz0-f42.google.com (mail-pz0-f42.google.com [209.85.210.42]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2EH6WWf016056 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 14 Mar 2012 18:06:36 +0100 Received: by dang27 with SMTP id g27so3121788dan.15 for ; Wed, 14 Mar 2012 10:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qqvGflgF6nQrXLcf5fpkjiUCZKAFc2VetaRL/c6g8qo=; b=nUQLvbs69Io4fghNSE/bm8V5xtLKiO42sasFhufzHYqfi7pWfnQVZ9KxP/jKNzKH9z 96VEDgdPRWfakWZ3SIQj5b0K9xyR+xSDw/TPzaHBW3pYDP4ziczVNqdbNeHGso2DDlAZ M6k7XpjENLj3vLoiys/pRNmd7R2pa0yCW8uE0cJnujyv1Hn+HM3rel0vBm7UFIa22+je mLp5spGc8GrX7lbi5D9bqYgs3hQ0lxcUllrwPk+zHfMNI55x6pMeqe3EKnix6BYa6B79 +JWwuu7Oy2KN3FITdR6cxR+hdhDKayGcPkNQqe9s/XorEjo/ehPbVa2uOPuF9tUyliUd 1riQ== MIME-Version: 1.0 Received: by 10.68.136.228 with SMTP id qd4mr3326276pbb.141.1331734718409; Wed, 14 Mar 2012 07:18:38 -0700 (PDT) Received: by 10.143.41.11 with HTTP; Wed, 14 Mar 2012 07:18:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 09:18:38 -0500 Message-ID: Subject: Re: sftp problem reading large directories From: E L To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Tue, Mar 13, 2012 at 4:06 PM, Daniel Stenberg wrote: > > Ok, one more try. I just pushed commit bf097e37b01dc9ef which is an > additional change on top of the previous to make sure sftp_packet_read() > does the right thing. > Thanks, it is now working for large directories and large files. Eric _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 14 22:58:21 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2ELw3p0018075; Wed, 14 Mar 2012 22:58:17 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2ELw23B018041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Mar 2012 22:58:02 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2ELw24S018036 for ; Wed, 14 Mar 2012 22:58:02 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Wed, 14 Mar 2012 22:58:02 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: sftp problem reading large directories In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Wed, 14 Mar 2012, E L wrote: > Thanks, it is now working for large directories and large files. Excellent! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 14 23:13:01 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2EMCvb2031245; Wed, 14 Mar 2012 23:12:59 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2EMCZjS031062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Mar 2012 23:12:35 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2EMCY2q031058 for ; Wed, 14 Mar 2012 23:12:34 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Wed, 14 Mar 2012 23:12:34 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Callback for channel data ready In-Reply-To: <4F5DCCD1.9090502@cryptzone.com> Message-ID: References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Mon, 12 Mar 2012, Tom Weber wrote: > After looking at the API, I think I have found a solution. > > libssh2_channel_window_read_ex() can check if there is data waiting on a > channel, without reading from the socket. Using that API you can know how much data that is already read off the socket and is waiting for you to get read, yes. > So we would have to run a libssh2_channel_window_read_ex() loop after each > libssh2_channel_read_ex() loop, and repeat both loops until > libssh2_channel_window_read_ex() returns zero for all channels. I would do it simpler. I would just do this: select() on socket if(readable) { for(loop over all channels) { rc = libssh2_channel_read_ex( channel [check index] ...); ... } } -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 14 23:54:18 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2EMs8p3003795; Wed, 14 Mar 2012 23:54:16 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2EMs6YK003773 for ; Wed, 14 Mar 2012 23:54:06 +0100 Received: (qmail 28984 invoked by uid 501); 14 Mar 2012 22:54:07 -0000 Message-ID: <20120314225407.28983.qmail@stuge.se> Date: Wed, 14 Mar 2012 23:54:07 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Callback for channel data ready Mail-Followup-To: libssh2-devel@cool.haxx.se References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Daniel Stenberg wrote: >> So we would have to run a libssh2_channel_window_read_ex() loop after each >> libssh2_channel_read_ex() loop, and repeat both loops until >> libssh2_channel_window_read_ex() returns zero for all channels. > > I would do it simpler. See also example/direct_tcpip.c and tcpip-forward.c which I believe are reliable. Although they only open one channel each. Suggest play with them to add a second channel. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 09:44:54 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F8iYn9029638; Thu, 15 Mar 2012 09:44:48 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F8iWdE029631 for ; Thu, 15 Mar 2012 09:44:32 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id 9D8FC1F29B0 for ; Thu, 15 Mar 2012 09:44:33 +0100 (MET) Received: from erebus.got.appgate.com (erebus.got.appgate.com [172.23.2.58]) by krakatau.got.appgate.com (Postfix) with ESMTP id 8EAA7BD4064 for ; Thu, 15 Mar 2012 09:44:33 +0100 (CET) Message-ID: <4F61ABF1.2030605@cryptzone.com> Date: Thu, 15 Mar 2012 09:44:33 +0100 From: Tom Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: libssh2 development Subject: Re: Callback for channel data ready References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Daniel Stenberg skrev 3/14/12 11:12 PM: >> So we would have to run a libssh2_channel_window_read_ex() loop after >> each libssh2_channel_read_ex() loop, and repeat both loops until >> libssh2_channel_window_read_ex() returns zero for all channels. > > I would do it simpler. I would just do this: > > select() on socket > > if(readable) { > > for(loop over all channels) { > > rc = libssh2_channel_read_ex( channel [check index] ...); > > ... > } > } > Sure, and that's what I did first, but I repeat my concern: What if libssh2_channel_read_ex() reads data from the socket, which turns out to be data for another channel which has already been checked? It will be put aside in the queue and my app wouldn't learn of its existence before the next select() returns, either because of a timeout or other SSH data. -- Best Regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 10:06:45 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F96duh014894; Thu, 15 Mar 2012 10:06:45 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F96bd9014795 for ; Thu, 15 Mar 2012 10:06:37 +0100 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2F96WoM021656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 05:06:32 -0400 Received: from t500.mbooth (ovpn-116-79.ams2.redhat.com [10.36.116.79]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2F96Vev009124; Thu, 15 Mar 2012 05:06:31 -0400 Message-ID: <4F61B116.6080900@redhat.com> Date: Thu, 15 Mar 2012 09:06:30 +0000 From: Matthew Booth Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: libssh2 development Subject: Re: Unchecked error in _libssh2_channel_write causes infinite loop References: <4F5DE09F.5070804@redhat.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: Daniel Stenberg X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 03/13/2012 11:13 PM, Daniel Stenberg wrote: > On Mon, 12 Mar 2012, Matthew Booth wrote: > >> seems to be down to an unchecked error in _libssh2_channel_write(): >> >> /* drain the incoming flow first, mostly to make sure we get all >> * pending window adjust packets */ >> do >> rc = _libssh2_transport_read(session); >> while (rc > 0); >> >> if(channel->local.window_size <= 0) >> /* there's no room for data so we stop */ >> return (rc==LIBSSH2_ERROR_EAGAIN?rc:0); >> >> In my case, _libssh2_transport_read is returning >> LIBSSH2_ERROR_SOCKET_RECV (don't know why yet). The result of this in >> the above code is that _libssh2_channel_write returns 0, throwing away >> the error information. My code spots a zero return, checks for eof, >> doesn't find one and goes round again: infinite loop. >> >> I would just submit a patch which adds "if (rc<0) return rc;" >> immediately after the read loop, but it seems like the author has >> intentionally not done this here. Git commit >> 3c71ad4fce745876f7e7ad33b846518f2d50edf6 and its associated mailing >> list thread doesn't shed any light on why only EAGAIN is handled. Can >> anybody explain? > > I think I only added code to handle the EAGAIN case since that was the > particular case I was out to fix and I played safe and didn't modify the > other cases. > > But I agree that it looks wrong. I would probably suggest this change as > a slight variation of your suggestion: > > diff --git a/src/channel.c b/src/channel.c > index 8d6fb0a..9e29492 100644 > --- a/src/channel.c > +++ b/src/channel.c > @@ -2008,6 +2008,9 @@ _libssh2_channel_write(LIBSSH2_CHANNEL *channel, > int strea > rc = _libssh2_transport_read(session); > while (rc > 0); > > + if((rc < 0) && (rc != LIBSSH2_ERROR_EAGAIN)) > + return rc; > + > if(channel->local.window_size <= 0) > /* there's no room for data so we stop */ > return (rc==LIBSSH2_ERROR_EAGAIN?rc:0); > > The existing code continues even if LIBSSH2_ERROR_EAGAIN was returned as > long as there is window size to go with so we should probably continue > doing so. I tested the above and it works as expected. Will you push it? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 10:13:07 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9D3JF019112; Thu, 15 Mar 2012 10:13:07 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2F9D2qQ019097 for ; Thu, 15 Mar 2012 10:13:02 +0100 Received: (qmail 12422 invoked by uid 501); 15 Mar 2012 09:13:02 -0000 Message-ID: <20120315091302.12421.qmail@stuge.se> Date: Thu, 15 Mar 2012 10:13:02 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Callback for channel data ready Mail-Followup-To: libssh2-devel@cool.haxx.se References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F61ABF1.2030605@cryptzone.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Tom Weber wrote: > What if libssh2_channel_read_ex() reads data from the socket, which > turns out to be data for another channel which has already been > checked? Keep looping over all channels until none return data. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 10:15:10 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9F828021218; Thu, 15 Mar 2012 10:15:10 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9F6AG021209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Mar 2012 10:15:06 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2F9F60e021203 for ; Thu, 15 Mar 2012 10:15:06 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 15 Mar 2012 10:15:06 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Callback for channel data ready In-Reply-To: <4F61ABF1.2030605@cryptzone.com> Message-ID: References: <20120229080800.13736.qmail@stuge.se> <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, 15 Mar 2012, Tom Weber wrote: > Sure, and that's what I did first, but I repeat my concern: What if > libssh2_channel_read_ex() reads data from the socket, which turns out to be > data for another channel which has already been checked? Yeah, this is really the main argument for introducing a single "drain the socket" function to make multi-channel use better... Patches welcome! :-) -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 10:45:26 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9jGUU014091; Thu, 15 Mar 2012 10:45:25 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9jEtA014079 for ; Thu, 15 Mar 2012 10:45:14 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id E1F9B1F29C8 for ; Thu, 15 Mar 2012 10:45:15 +0100 (MET) Received: from erebus.got.appgate.com (erebus.got.appgate.com [172.23.2.58]) by krakatau.got.appgate.com (Postfix) with ESMTP id B3BC4BD407A for ; Thu, 15 Mar 2012 10:45:15 +0100 (CET) Message-ID: <4F61BA2B.5050601@cryptzone.com> Date: Thu, 15 Mar 2012 10:45:15 +0100 From: Tom Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: libssh2 development Subject: Re: Callback for channel data ready References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> In-Reply-To: <20120315091302.12421.qmail@stuge.se> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Peter Stuge skrev 3/15/12 10:13 AM: > Tom Weber wrote: >> What if libssh2_channel_read_ex() reads data from the socket, which >> turns out to be data for another channel which has already been >> checked? > > Keep looping over all channels until none return data. > The same thing can happen there. Even if no libssh2_channel_read_ex() call returns data during a loop, one of them can read data from the socket, for a channel which has already been checked. What I need is a way to check for data *without* reading more from the socket. I would probably have designed the API so that the app explicitly reads socket data with libssh2_transport_read(), wrapped in libssh2_session_read(), and libssh2_channel_read() would only operate on that data, it wouldn't call libssh2_transport_read() itself. But I guess it's too late to make such a change. -- Best Regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 10:50:29 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9oQE2017392; Thu, 15 Mar 2012 10:50:29 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2F9oPbn017375 for ; Thu, 15 Mar 2012 10:50:25 +0100 Received: (qmail 15636 invoked by uid 501); 15 Mar 2012 09:50:26 -0000 Message-ID: <20120315095026.15635.qmail@stuge.se> Date: Thu, 15 Mar 2012 10:50:26 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Callback for channel data ready Mail-Followup-To: libssh2-devel@cool.haxx.se References: <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> <4F61BA2B.5050601@cryptzone.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4F61BA2B.5050601@cryptzone.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Tom Weber wrote: > I would probably have designed the API so that This is not useful I'm afraid. > I guess it's too late to make such a change. Yes. But new and improved API can be added of course. Suggest something! :) //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 10:54:41 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9sdhK019458; Thu, 15 Mar 2012 10:54:40 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2F9sbtW019426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Mar 2012 10:54:37 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2F9sb4l019423 for ; Thu, 15 Mar 2012 10:54:37 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 15 Mar 2012 10:54:37 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Callback for channel data ready In-Reply-To: <4F61BA2B.5050601@cryptzone.com> Message-ID: References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> <4F61BA2B.5050601@cryptzone.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, 15 Mar 2012, Tom Weber wrote: > I would probably have designed the API so that the app explicitly reads > socket data with libssh2_transport_read(), wrapped in > libssh2_session_read(), and libssh2_channel_read() would only operate on > that data, it wouldn't call libssh2_transport_read() itself. But I guess > it's too late to make such a change. It is never too late! We can "easily" add a function today that just reads everything off the socket, and then you can use the existing libssh2_channel_read() function just fine (when this API "mode" is used, we would prevent the channel read functions to try reading anything from the transport). We could also add a function that can return exactly which channels that have data pending. Or am I missing something? -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 13:10:14 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FC9qgS001507; Thu, 15 Mar 2012 13:10:11 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FC9od8001489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Mar 2012 13:09:50 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2FC9nNq001486 for ; Thu, 15 Mar 2012 13:09:50 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 15 Mar 2012 13:09:49 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Unchecked error in _libssh2_channel_write causes infinite loop In-Reply-To: <4F61B116.6080900@redhat.com> Message-ID: References: <4F5DE09F.5070804@redhat.com> <4F61B116.6080900@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, 15 Mar 2012, Matthew Booth wrote: >> The existing code continues even if LIBSSH2_ERROR_EAGAIN was returned as >> long as there is window size to go with so we should probably continue >> doing so. > > I tested the above and it works as expected. Will you push it? Done now. Thanks a lot! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 17:24:54 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FGOZpl012395; Thu, 15 Mar 2012 17:24:51 +0100 Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FGOXT1012347 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 15 Mar 2012 17:24:33 +0100 Received: by eekd17 with SMTP id d17so2104116eek.41 for ; Thu, 15 Mar 2012 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=da/ACXGdQhqktCWHTzMPiK5OPqh0QWO2c7Pd+TlNPJc=; b=j9OlVTfUIobA3bvWtwCVl3lpC+BPzaCXyVYRfN6q3RHzgxH9AkFKmqsoRfSpPWC+M2 nd+3icxIE3XV2Z/Ppdu2AXBAwM8pexnxcuHzfp0F072zdoZeur9lUAgrp+Kt+qn3tXue yJ9ZBOJudCzUDWIdyj2U7EAIqBJahikxN8BYnVHGuwf3+SLBFsgVfbC9055aLNHD+FED cMY6KpIAjOUZQc2uE/id40rhZjo/4tAjuRMMkoEb54LVB8FUjlKDAqDXWEGvewxwDTtp 8TpLnxKPS4b4Lu2lXAicAQAHRXTFpbvOwF/LDwnvUIoIxwdpB8can7mSf282RcPEhxjg 6rVw== Received: by 10.50.182.197 with SMTP id eg5mr10237735igc.36.1331828669321; Thu, 15 Mar 2012 09:24:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Thu, 15 Mar 2012 09:24:09 -0700 (PDT) In-Reply-To: References: From: Mitchell Hashimoto Date: Thu, 15 Mar 2012 09:24:09 -0700 X-Google-Sender-Auth: AEw9QsCnJ7EF438hy0DLLumQak4 Message-ID: Subject: Re: Send custom requests To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1962404469==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============1962404469== Content-Type: multipart/alternative; boundary=14dae9340ac9bc92d604bb4a8645 --14dae9340ac9bc92d604bb4a8645 Content-Type: text/plain; charset=ISO-8859-1 Daniel, On Tue, Mar 13, 2012 at 4:05 PM, Daniel Stenberg wrote: > On Mon, 12 Mar 2012, Mitchell Hashimoto wrote: > > I'd like to have the option to enable SSH agent forwarding in my app that >> uses libssh2. Based on this RFC[1] it seems simple enough, but it requires >> that a send a couple custom SSH request packets. As far as I know, libssh2 >> does not expose a way to send custom request packet types. Would it be okay >> for this to be exposed? >> > > Our "normal" approach has been to add API calls for the special packets we > need so that applications won't need to known and care for SSH related > binary protocol details. Don't you think that would be better suited for > this case as well? > > In general I'm not really against a way to send "raw" SSH channel packets > I'm just not sure people really want to use one. I agree, but I think having an API for sending a custom SSH_MSG_CHANNEL_REQUEST packet would be helpful for "advanced" use cases since it is a core part of the SSH spec, and I believe channels are free to implement custom requests. I realize not many people build custom channel types on the remote end, but they're certainly well-within the RFC[1] to do so. In that case, libssh2 can't possibly handle every possible request type, so having this raw API would help. For example, SSH agent forwarding came much later and still as far as I know doesn't even have a finalized RFC[2]. This added custom REQUESTS. If libssh2 supported sending custom requests, then users can begin using this new thing immediately, while custom methods are added which perhaps makes this easier. Therefore, I'm saying: Can we do both? I'd happily provide patches for both cases. :) Mitchell [1]: http://tools.ietf.org/html/rfc4254#page-9 [2]: http://tools.ietf.org/html/draft-ietf-secsh-agent-02#page-10 > > > -- > > / daniel.haxx.se > ______________________________**_________________ > libssh2-devel http://cool.haxx.se/cgi-bin/**mailman/listinfo/libssh2-devel > --14dae9340ac9bc92d604bb4a8645 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel,

On Tue, Mar 13, 2012 at 4:05 PM, = Daniel Stenberg <dan= iel@haxx.se> wrote:
On Mon, 12 Mar 2012, Mitchell Hashimoto wrote:

I'd like to have the option to enable SSH agent forwarding in my app th= at uses libssh2. Based on this RFC[1] it seems simple enough, but it requir= es that a send a couple custom SSH request packets. As far as I know, libss= h2 does not expose a way to send custom request packet types. Would it be o= kay for this to be exposed?

Our "normal" approach has been to add API calls for the special p= ackets we need so that applications won't need to known and care for SS= H related binary protocol details. Don't you think that would be better= suited for this case as well?

In general I'm not really against a way to send "raw" SSH cha= nnel packets I'm just not sure people really want to use one.

I agree, but I think having an API for sending a cus= tom SSH_MSG_CHANNEL_REQUEST packet would be helpful for "advanced"= ; use cases since it is a core part of the SSH spec, and I believe channels= are free to implement custom requests. I realize not many people build cus= tom channel types on the remote end, but they're certainly well-within = the RFC[1] to do so. In that case, libssh2 can't possibly handle every = possible request type, so having this raw API would help.

For example, SSH agent forwarding came much later and s= till as far as I know doesn't even have a finalized RFC[2]. This added = custom REQUESTS. If libssh2 supported sending custom requests, then users c= an begin using this new thing immediately, while custom methods are added w= hich perhaps makes this easier.

Therefore, I'm saying: Can we do both? I'd happ= ily provide patches for both cases. :)


--14dae9340ac9bc92d604bb4a8645-- --===============1962404469== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============1962404469==-- From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 17:32:31 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FGWSTc017587; Thu, 15 Mar 2012 17:32:31 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2FGWRu6017572 for ; Thu, 15 Mar 2012 17:32:27 +0100 Received: (qmail 15538 invoked by uid 501); 15 Mar 2012 16:32:27 -0000 Message-ID: <20120315163227.15537.qmail@stuge.se> Date: Thu, 15 Mar 2012 17:32:27 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Send custom requests Mail-Followup-To: libssh2-devel@cool.haxx.se References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Mitchell Hashimoto wrote: > Can we do both? Not for no reason. Do the agent API. Let's look at something more generic when there is actual need. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 21:19:30 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FKJ60d024530; Thu, 15 Mar 2012 21:19:23 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FKJ2hK024351 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 15 Mar 2012 21:19:04 +0100 Received: by iahk25 with SMTP id k25so5074208iah.41 for ; Thu, 15 Mar 2012 13:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=4xGn0LqgMgKFfQrD91GesYH6nmuW/EEcvrm4lwU2rVU=; b=bBWk1Vhp8C2ZjoC0R/tvy365N2Cw9DWbkl6LKlKLKdnlTtxBD7VnFXnj4VFnJwxT7H 2BM16cSSbP6UtA4nBP3rjCblTHfun5bDFgH5Omtit7V0Xhw0gCVLX6pxXYiezmLlfbwk pv27J4EU6Jauf+ncvJ7UKtH22HB4ml6udFsJpavHILIQSA7xpLqx/69qNErujd/SNP5n YQO3/vmCUyx4UTEm+QSPFKsmRnvvcy3MaEXcNacu08PfPi1YdxWGf4z8mgpSkOB92IbM EMgb952BnXvYjWgBEjRJAKfFRxcnZgqEdHEnYdp3uL+N58yMGzKsb2m/Erdn1TbimM3i TD+w== Received: by 10.50.188.138 with SMTP id ga10mr10886347igc.51.1331842739204; Thu, 15 Mar 2012 13:18:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Thu, 15 Mar 2012 13:18:39 -0700 (PDT) From: Mitchell Hashimoto Date: Thu, 15 Mar 2012 13:18:39 -0700 X-Google-Sender-Auth: A9_2fy3PpozeVk4eUvpUyWZBhNE Message-ID: Subject: Compiling from git To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0918179469==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============0918179469== Content-Type: multipart/alternative; boundary=14dae93407f95df22404bb4dcd5b --14dae93407f95df22404bb4dcd5b Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm working on some patches for libssh2 and I'm not entirely comfortable with the autotools process. What is the correct way to generate the proper files and compile the source directly from git? Mitchell --14dae93407f95df22404bb4dcd5b Content-Type: text/html; charset=ISO-8859-1 Hi,

I'm working on some patches for libssh2 and I'm not entirely comfortable with the autotools process. What is the correct way to generate the proper files and compile the source directly from git?

Mitchell
--14dae93407f95df22404bb4dcd5b-- --===============0918179469== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============0918179469==-- From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 21:29:50 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FKTiMJ032071; Thu, 15 Mar 2012 21:29:49 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2FKTgjc032067 for ; Thu, 15 Mar 2012 21:29:42 +0100 Received: (qmail 4005 invoked by uid 501); 15 Mar 2012 20:29:44 -0000 Message-ID: <20120315202944.4004.qmail@stuge.se> Date: Thu, 15 Mar 2012 21:29:44 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Compiling from git Mail-Followup-To: libssh2-devel@cool.haxx.se References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Mitchell Hashimoto wrote: > What is the correct way to generate the proper files and compile > the source directly from git? clone, then cd into libssh2, then: ./buildconf && ./configure --prefix=/tmp/ls2 && make install Between builds, run: make distclean && rm -rf /tmp/ls2 //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 15 22:52:49 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FLqbHK029933; Thu, 15 Mar 2012 22:52:47 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FLqapS029916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Mar 2012 22:52:36 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2FLqaHT029913 for ; Thu, 15 Mar 2012 22:52:36 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 15 Mar 2012 22:52:36 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Compiling from git In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, 15 Mar 2012, Mitchell Hashimoto wrote: > I'm working on some patches for libssh2 and I'm not entirely comfortable > with the autotools process. What is the correct way to generate the proper > files and compile the source directly from git? I'll let you in on the little trick I sometimes do while developing programs using my development libssh2 version: To build: $ cd /my/source/dir $ ./buildconf $ ./configure [options] $ make -j4 Create a 'lib' dir that is a symbolic link directly to where the libssh2.a file is: $ ln -s src/.libs lib Now, you can build libssh2-using programs with configure and point it with ./configure --prefix to the root of the libssh2 source dir and you won't have to do 'make install' etc when rebuilding libssh2 for experiments. That works because --prefix expects a lib directory and an include directory. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 00:27:03 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FNQjZ0027159; Fri, 16 Mar 2012 00:26:58 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2FNQfOd027137 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 16 Mar 2012 00:26:43 +0100 Received: by iahk25 with SMTP id k25so5328957iah.41 for ; Thu, 15 Mar 2012 16:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=RTQjQ0RGjPQLm/jwPMvspZoUhz+nCE5lI7wkO9XQx5g=; b=iSQJkOuqNWPufQT0HOEqdpVeBXsM3xtWXtSXEVr8GmL4QyE5vFngyFExV6S7ryqeGM mO6yVOCmj24V0iY0FeZHL4Y3oazCDio9XKbC/va1hn0VPCQ5Yye5JBxtck3i/q/Jvilf TinK4uwQfTJH26U7cbTQQJQaVyL5WiDmuq2q7EdIDRFn2pQgOEfJT+tL0iAcj+7RimCB UnD0RW8WcL7ygrcl4kKnJI9CbwKimPuLTziYaPFiCtqM7uQ6wrRIGwekadadmFFM2LjP remM5FbSMaqNx9RaIrRL1gPQ+bdFL0xgUnynqaaXl1ltR4YuDj7ZnSTTf6lvqJMwuynC HMOw== Received: by 10.50.207.5 with SMTP id ls5mr11229716igc.51.1331853997413; Thu, 15 Mar 2012 16:26:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Thu, 15 Mar 2012 16:26:16 -0700 (PDT) From: Mitchell Hashimoto Date: Thu, 15 Mar 2012 16:26:16 -0700 X-Google-Sender-Auth: 9hxHK6nravJeA2vk0qekvHTIRAc Message-ID: Subject: [PATCH] Request SSH agent forwarding To: libssh2 development Content-Type: multipart/mixed; boundary=14dae9340a4768955b04bb506ccd X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --14dae9340a4768955b04bb506ccd Content-Type: text/plain; charset=ISO-8859-1 Hello, Attached is a patch to add a new method `libssh2_channel_request_auth_agent` which requests that an agent forwarding listener be started on the remote side for SSH agent forwarding. The method adheres to the RFC draft[2] as well as contains RFC non-compliant tries (sending "auth-agent-req@openssh.com") in order to remain working with OpenSSH. This is my first patch so please let me know if I did anything wrong. I've tested the code by modifying the ssh_exec.c example to request agent forwarding, which worked great. I didn't write a new example though, so I didn't commit these changes (since it alters ssh_exec). Best, Mitchell --14dae9340a4768955b04bb506ccd Content-Type: application/octet-stream; name="libssh2_channel_request_auth_agent.patch" Content-Disposition: attachment; filename="libssh2_channel_request_auth_agent.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzuffzcq0 ZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGlic3NoMi5oIGIvaW5jbHVkZS9saWJzc2gyLmgKaW5kZXgg NWEyMmJlMi4uYjUwYTAwMSAxMDA2NDQKLS0tIGEvaW5jbHVkZS9saWJzc2gyLmgKKysrIGIvaW5j bHVkZS9saWJzc2gyLmgKQEAgLTYzOCw2ICs2MzgsOCBAQCBMSUJTU0gyX0FQSSBpbnQgbGlic3No Ml9jaGFubmVsX3NldGVudl9leChMSUJTU0gyX0NIQU5ORUwgKmNoYW5uZWwsCiAgbGlic3NoMl9j aGFubmVsX3NldGVudl9leCgoY2hhbm5lbCksICh2YXJuYW1lKSwgc3RybGVuKHZhcm5hbWUpLCAo dmFsdWUpLCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJsZW4odmFsdWUpKQogCitM SUJTU0gyX0FQSSBpbnQgbGlic3NoMl9jaGFubmVsX3JlcXVlc3RfYXV0aF9hZ2VudChMSUJTU0gy X0NIQU5ORUwgKmNoYW5uZWwpOworCiBMSUJTU0gyX0FQSSBpbnQgbGlic3NoMl9jaGFubmVsX3Jl cXVlc3RfcHR5X2V4KExJQlNTSDJfQ0hBTk5FTCAqY2hhbm5lbCwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc3QgY2hhciAqdGVybSwKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IHRlcm1f bGVuLApkaWZmIC0tZ2l0IGEvc3JjL2NoYW5uZWwuYyBiL3NyYy9jaGFubmVsLmMKaW5kZXggOWUy OTQ5Mi4uNTQ5MTBlZiAxMDA2NDQKLS0tIGEvc3JjL2NoYW5uZWwuYworKysgYi9zcmMvY2hhbm5l bC5jCkBAIC05NzMsNiArOTczLDE1OCBAQCBzdGF0aWMgaW50IGNoYW5uZWxfcmVxdWVzdF9wdHko TElCU1NIMl9DSEFOTkVMICpjaGFubmVsLAogICAgICAgICAgICAgICAgICAgICAgICAgICAiVW5h YmxlIHRvIGNvbXBsZXRlIHJlcXVlc3QgZm9yIGNoYW5uZWwgcmVxdWVzdC1wdHkiKTsKIH0KIAor LyoqCisgKiBjaGFubmVsX3JlcXVlc3RfYXV0aF9hZ2VudAorICogVGhlIGFjdHVhbCByZS1lbnRy YW50IG1ldGhvZCB3aGljaCByZXF1ZXN0cyBhbiBhdXRoIGFnZW50LgorICogKi8KK3N0YXRpYyBp bnQgY2hhbm5lbF9yZXF1ZXN0X2F1dGhfYWdlbnQoTElCU1NIMl9DSEFOTkVMICpjaGFubmVsLAor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpyZXF1ZXN0 X3N0ciwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50IHJlcXVlc3Rf c3RyX2xlbikKK3sKKyAgICBMSUJTU0gyX1NFU1NJT04gKnNlc3Npb24gPSBjaGFubmVsLT5zZXNz aW9uOworICAgIHVuc2lnbmVkIGNoYXIgKnM7CisgICAgc3RhdGljIGNvbnN0IHVuc2lnbmVkIGNo YXIgcmVwbHlfY29kZXNbM10gPQorICAgICAgICB7IFNTSF9NU0dfQ0hBTk5FTF9TVUNDRVNTLCBT U0hfTVNHX0NIQU5ORUxfRkFJTFVSRSwgMCB9OworICAgIGludCByYzsKKworICAgIGlmIChjaGFu bmVsLT5yZXFfYXV0aF9hZ2VudF9zdGF0ZSA9PSBsaWJzc2gyX05CX3N0YXRlX2lkbGUpIHsKKyAg ICAgICAgLyogT25seSB2YWxpZCBvcHRpb25zIGFyZSAiYXV0aC1hZ2VudC1yZXEiIGFuZAorICAg ICAgICAgKiAiYXV0aC1hZ2VudC1yZXFAb3BlbnNzaC5jb20iIHNvIHdlIG1ha2Ugc3VyZSBpdCBp cyBub3QKKyAgICAgICAgICogYWN0dWFsbHkgbG9uZ2VyIHRoYW4gdGhlIGxvbmdlc3QgcG9zc2li bGUuICovCisgICAgICAgIGlmKHJlcXVlc3Rfc3RyX2xlbiA+IDI2KSB7CisgICAgICAgICAgICBy ZXR1cm4gX2xpYnNzaDJfZXJyb3Ioc2Vzc2lvbiwgTElCU1NIMl9FUlJPUl9JTlZBTCwKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAicmVxdWVzdF9zdHIgbGVuZ3RoIHRvbyBsYXJn ZSIpOworICAgICAgICB9CisKKyAgICAgICAgLyoKKyAgICAgICAgICogIExlbmd0aDogMjQgb3Ig MzYgPSBwYWNrZXRfdHlwZSgxKSArIGNoYW5uZWwoNCkgKyByZXFfbGVuKDQpICsKKyAgICAgICAg ICogICAgcmVxdWVzdF9zdHIgKHZhcmlhYmxlKSArIHdhbnRfcmVwbHkgKDEpICovCisgICAgICAg IGNoYW5uZWwtPnJlcV9hdXRoX2FnZW50X3BhY2tldF9sZW4gPSAxMCArIHJlcXVlc3Rfc3RyX2xl bjsKKworICAgICAgICAvKiBaZXJvIG91dCB0aGUgcmVxdWlyZWV2IHN0YXRlIHRvIHJlc2V0ICov CisgICAgICAgIG1lbXNldCgmY2hhbm5lbC0+cmVxX2F1dGhfYWdlbnRfcmVxdWlyZXZfc3RhdGUs IDAsCisgICAgICAgICAgICAgICBzaXplb2YoY2hhbm5lbC0+cmVxX2F1dGhfYWdlbnRfcmVxdWly ZXZfc3RhdGUpKTsKKworICAgICAgICBfbGlic3NoMl9kZWJ1ZyhzZXNzaW9uLCBMSUJTU0gyX1RS QUNFX0NPTk4sCisgICAgICAgICAgICAgICAgICAgICAgICJSZXF1ZXN0aW5nIGF1dGggYWdlbnQg b24gY2hhbm5lbCAlbHUvJWx1IiwKKyAgICAgICAgICAgICAgICAgICAgICAgY2hhbm5lbC0+bG9j YWwuaWQsIGNoYW5uZWwtPnJlbW90ZS5pZCk7CisKKyAgICAgICAgLyoKKyAgICAgICAgICogIGJ5 dGUgICAgICBTU0hfTVNHX0NIQU5ORUxfUkVRVUVTVAorICAgICAgICAgKiAgdWludDMyICAgIHJl Y2lwaWVudCBjaGFubmVsCisgICAgICAgICAqICBzdHJpbmcgICAgImF1dGgtYWdlbnQtcmVxIgor ICAgICAgICAgKiAgYm9vbGVhbiAgIHdhbnQgcmVwbHkKKyAgICAgICAgICogKi8KKyAgICAgICAg cyA9IGNoYW5uZWwtPnJlcV9hdXRoX2FnZW50X3BhY2tldDsKKyAgICAgICAgKihzKyspID0gU1NI X01TR19DSEFOTkVMX1JFUVVFU1Q7CisgICAgICAgIF9saWJzc2gyX3N0b3JlX3UzMigmcywgY2hh bm5lbC0+cmVtb3RlLmlkKTsKKyAgICAgICAgX2xpYnNzaDJfc3RvcmVfc3RyKCZzLCAoY2hhciAq KXJlcXVlc3Rfc3RyLCByZXF1ZXN0X3N0cl9sZW4pOworICAgICAgICAqKHMrKykgPSAweDAxOwor CisgICAgICAgIGNoYW5uZWwtPnJlcV9hdXRoX2FnZW50X3N0YXRlID0gbGlic3NoMl9OQl9zdGF0 ZV9jcmVhdGVkOworICAgIH0KKworICAgIGlmIChjaGFubmVsLT5yZXFfYXV0aF9hZ2VudF9zdGF0 ZSA9PSBsaWJzc2gyX05CX3N0YXRlX2NyZWF0ZWQpIHsKKyAgICAgICAgLyogU2VuZCB0aGUgcGFj a2V0LCB3ZSBjYW4gdXNlIHNpemVvZigpIG9uIHRoZSBwYWNrZXQgYmVjYXVzZSBpdAorICAgICAg ICAgKiBpcyBhbHdheXMgY29tcGxldGVseSBmaWxsZWQ7IHRoZXJlIGFyZSBubyB2YXJpYWJsZSBs ZW5ndGggZmllbGRzLiAqLworICAgICAgICByYyA9IF9saWJzc2gyX3RyYW5zcG9ydF9zZW5kKHNl c3Npb24sIGNoYW5uZWwtPnJlcV9hdXRoX2FnZW50X3BhY2tldCwKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjaGFubmVsLT5yZXFfYXV0aF9hZ2VudF9wYWNrZXRfbGVuLAor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5VTEwsIDApOworCisgICAgICAg IGlmIChyYyA9PSBMSUJTU0gyX0VSUk9SX0VBR0FJTikgeworICAgICAgICAgICAgX2xpYnNzaDJf ZXJyb3Ioc2Vzc2lvbiwgcmMsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAiV291bGQgYmxv Y2sgc2VuZGluZyBhdXRoLWFnZW50IHJlcXVlc3QiKTsKKyAgICAgICAgfSBlbHNlIGlmIChyYykg eworICAgICAgICAgICAgY2hhbm5lbC0+cmVxX2F1dGhfYWdlbnRfc3RhdGUgPSBsaWJzc2gyX05C X3N0YXRlX2lkbGU7CisgICAgICAgICAgICByZXR1cm4gX2xpYnNzaDJfZXJyb3Ioc2Vzc2lvbiwg cmMsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIlVuYWJsZSB0byBzZW5kIGF1 dGgtYWdlbnQgcmVxdWVzdCIpOworICAgICAgICB9CisKKyAgICAgICAgX2xpYnNzaDJfaHRvbnUz MihjaGFubmVsLT5yZXFfYXV0aF9hZ2VudF9sb2NhbF9jaGFubmVsLAorICAgICAgICAgICAgICAg ICAgICAgICAgIGNoYW5uZWwtPmxvY2FsLmlkKTsKKworICAgICAgICBjaGFubmVsLT5yZXFfYXV0 aF9hZ2VudF9zdGF0ZSA9IGxpYnNzaDJfTkJfc3RhdGVfc2VudDsKKyAgICB9CisKKyAgICBpZiAo Y2hhbm5lbC0+cmVxX2F1dGhfYWdlbnRfc3RhdGUgPT0gbGlic3NoMl9OQl9zdGF0ZV9zZW50KSB7 CisgICAgICAgIHVuc2lnbmVkIGNoYXIgKmRhdGE7CisgICAgICAgIHNpemVfdCBkYXRhX2xlbjsK KyAgICAgICAgdW5zaWduZWQgY2hhciBjb2RlOworCisgICAgICAgIHJjID0gX2xpYnNzaDJfcGFj a2V0X3JlcXVpcmV2KHNlc3Npb24sIHJlcGx5X2NvZGVzLCAmZGF0YSwgJmRhdGFfbGVuLAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxLCBjaGFubmVsLT5yZXFfYXV0aF9h Z2VudF9sb2NhbF9jaGFubmVsLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA0LCAmY2hhbm5lbC0+cmVxX2F1dGhfYWdlbnRfcmVxdWlyZXZfc3RhdGUpOworCisgICAgICAg IGlmIChyYyA9PSBMSUJTU0gyX0VSUk9SX0VBR0FJTikgeworICAgICAgICAgICAgcmV0dXJuIHJj OworICAgICAgICB9IGVsc2UgaWYgKHJjKSB7CisgICAgICAgICAgICBjaGFubmVsLT5yZXFfYXV0 aF9hZ2VudF9zdGF0ZSA9IGxpYnNzaDJfTkJfc3RhdGVfaWRsZTsKKyAgICAgICAgICAgIHJldHVy biBfbGlic3NoMl9lcnJvcihzZXNzaW9uLCBMSUJTU0gyX0VSUk9SX1BST1RPLAorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICJGYWlsZWQgdG8gcmVxdWVzdCBhdXRoLWFnZW50Iik7 CisgICAgICAgIH0KKworICAgICAgICBjb2RlID0gZGF0YVswXTsKKworICAgICAgICBMSUJTU0gy X0ZSRUUoc2Vzc2lvbiwgZGF0YSk7CisgICAgICAgIGNoYW5uZWwtPnJlcV9hdXRoX2FnZW50X3N0 YXRlID0gbGlic3NoMl9OQl9zdGF0ZV9pZGxlOworCisgICAgICAgIGlmIChjb2RlID09IFNTSF9N U0dfQ0hBTk5FTF9TVUNDRVNTKQorICAgICAgICAgICAgcmV0dXJuIDA7CisgICAgfQorCisgICAg cmV0dXJuIF9saWJzc2gyX2Vycm9yKHNlc3Npb24sIExJQlNTSDJfRVJST1JfQ0hBTk5FTF9SRVFV RVNUX0RFTklFRCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIlVuYWJsZSB0byBjb21wbGV0 ZSByZXF1ZXN0IGZvciBhdXRoLWFnZW50Iik7Cit9CisKKy8qCisgKiBsaWJzc2gyX2NoYW5uZWxf cmVxdWVzdF9hdXRoX2FnZW50CisgKiBSZXF1ZXN0cyB0aGF0IGFnZW50IGZvcndhcmRpbmcgYmUg ZW5hYmxlZCBmb3IgdGhlIHNlc3Npb24uIFRoZQorICogcmVxdWVzdCBtdXN0IGJlIHNlbnQgb3Zl ciBhIHNwZWNpZmljIGNoYW5uZWwsIHdoaWNoIHN0YXJ0cyB0aGUgYWdlbnQKKyAqIGxpc3RlbmVy IG9uIHRoZSByZW1vdGUgc2lkZS4gT25jZSB0aGUgY2hhbm5lbCBpcyBjbG9zZWQsIHRoZSBhZ2Vu dAorICogbGlzdGVuZXIgY29udGludWVzIHRvIGV4aXN0LgorICogKi8KK0xJQlNTSDJfQVBJIGlu dAorbGlic3NoMl9jaGFubmVsX3JlcXVlc3RfYXV0aF9hZ2VudChMSUJTU0gyX0NIQU5ORUwgKmNo YW5uZWwpCit7CisgICAgaW50IHJjOworCisgICAgaWYgKCFjaGFubmVsKQorICAgICAgICByZXR1 cm4gTElCU1NIMl9FUlJPUl9CQURfVVNFOworCisgICAgLyogVGhlIGN1cnJlbnQgUkZDIGRyYWZ0 IGZvciBhZ2VudCBmb3J3YXJkaW5nIHNheXMgeW91J3JlIHN1cHBvc2VkIHRvCisgICAgICogc2Vu ZCAiYXV0aC1hZ2VudC1yZXEsIiBidXQgbW9zdCBTU0ggc2VydmVycyBvdXQgdGhlcmUgcmlnaHQg bm93CisgICAgICogYWN0dWFsbHkgZXhwZWN0ICJhdXRoLWFnZW50LXJlcUBvcGVuc3NoLmNvbSwi IHNvIHdlIHRyeSB0aGF0CisgICAgICogZmlyc3QuICovCisgICAgaWYgKGNoYW5uZWwtPnJlcV9h dXRoX2FnZW50X3RyeV9zdGF0ZSA9PSBsaWJzc2gyX05CX3N0YXRlX2lkbGUpIHsKKyAgICAgICAg QkxPQ0tfQURKVVNUKHJjLCBjaGFubmVsLT5zZXNzaW9uLAorICAgICAgICAgICAgICAgICAgICAg Y2hhbm5lbF9yZXF1ZXN0X2F1dGhfYWdlbnQoY2hhbm5lbCwKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICJhdXRoLWFnZW50LXJlcUBvcGVuc3NoLmNvbSIs CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyNikpOwor CisgICAgICAgIC8qIElmIHdlIGZhaWxlZCAoYnV0IG5vdCB3aXRoIEVBR0FJTiksIHRoZW4gd2Ug bW92ZSBvbnRvCisgICAgICAgICAqIHRoZSBuZXh0IHN0ZXAgdG8gdHJ5IGFub3RoZXIgcmVxdWVz dCB0eXBlLiAqLworICAgICAgICBpZiAocmMgIT0gMCAmJiByYyAhPSBMSUJTU0gyX0VSUk9SX0VB R0FJTikKKyAgICAgICAgICAgIGNoYW5uZWwtPnJlcV9hdXRoX2FnZW50X3RyeV9zdGF0ZSA9IGxp YnNzaDJfTkJfc3RhdGVfc2VudDsKKyAgICB9CisKKyAgICBpZiAoY2hhbm5lbC0+cmVxX2F1dGhf YWdlbnRfdHJ5X3N0YXRlID09IGxpYnNzaDJfTkJfc3RhdGVfc2VudCkgeworICAgICAgICBCTE9D S19BREpVU1QocmMsIGNoYW5uZWwtPnNlc3Npb24sCisgICAgICAgICAgICAgICAgICAgICBjaGFu bmVsX3JlcXVlc3RfYXV0aF9hZ2VudChjaGFubmVsLAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgImF1dGgtYWdlbnQtcmVxIiwgMTQpKTsKKworICAgICAg ICAvKiBJZiB3ZSBmYWlsZWQgd2l0aG91dCBhbiBFQUdBSU4sIHRoZW4gbW92ZSBvbiB3aXRoIHRo aXMKKyAgICAgICAgICogc3RhdGUgbWFjaGluZS4gKi8KKyAgICAgICAgaWYgKHJjICE9IDAgJiYg cmMgIT0gTElCU1NIMl9FUlJPUl9FQUdBSU4pCisgICAgICAgICAgICBjaGFubmVsLT5yZXFfYXV0 aF9hZ2VudF90cnlfc3RhdGUgPSBsaWJzc2gyX05CX3N0YXRlX3NlbnQxOworICAgIH0KKworICAg IC8qIElmIHRoaW5ncyBhcmUgZ29vZCwgcmVzZXQgdGhlIHRyeSBzdGF0ZS4gKi8KKyAgICBpZiAo cmMgPT0gMCkKKyAgICAgICAgY2hhbm5lbC0+cmVxX2F1dGhfYWdlbnRfdHJ5X3N0YXRlID0gbGli c3NoMl9OQl9zdGF0ZV9pZGxlOworCisgICAgcmV0dXJuIHJjOworfQorCiAvKgogICogbGlic3No Ml9jaGFubmVsX3JlcXVlc3RfcHR5X2V4CiAgKiBEdWguLi4gUmVxdWVzdCBhIFBUWQpkaWZmIC0t Z2l0IGEvc3JjL2xpYnNzaDJfcHJpdi5oIGIvc3JjL2xpYnNzaDJfcHJpdi5oCmluZGV4IGM2NzBh MTYuLjFmNGRhNDAgMTAwNjQ0Ci0tLSBhL3NyYy9saWJzc2gyX3ByaXYuaAorKysgYi9zcmMvbGli c3NoMl9wcml2LmgKQEAgLTQyOCw2ICs0MjgsMTMgQEAgc3RydWN0IF9MSUJTU0gyX0NIQU5ORUwK ICAgICAvKiBTdGF0ZSB2YXJpYWJsZXMgdXNlZCBpbiBsaWJzc2gyX2NoYW5uZWxfaGFuZGxlX2V4 dGVuZGVkX2RhdGEyKCkgKi8KICAgICBsaWJzc2gyX25vbmJsb2NraW5nX3N0YXRlcyBleHREYXRh Ml9zdGF0ZTsKIAorICAgIC8qIFN0YXRlIHZhcmlhYmxlcyB1c2VkIGluIGxpYnNzaDJfY2hhbm5l bF9yZXF1ZXN0X2F1dGhfYWdlbnQoKSAqLworICAgIGxpYnNzaDJfbm9uYmxvY2tpbmdfc3RhdGVz IHJlcV9hdXRoX2FnZW50X3RyeV9zdGF0ZTsKKyAgICBsaWJzc2gyX25vbmJsb2NraW5nX3N0YXRl cyByZXFfYXV0aF9hZ2VudF9zdGF0ZTsKKyAgICB1bnNpZ25lZCBjaGFyIHJlcV9hdXRoX2FnZW50 X3BhY2tldFszNl07CisgICAgc2l6ZV90IHJlcV9hdXRoX2FnZW50X3BhY2tldF9sZW47CisgICAg dW5zaWduZWQgY2hhciByZXFfYXV0aF9hZ2VudF9sb2NhbF9jaGFubmVsWzRdOworICAgIHBhY2tl dF9yZXF1aXJldl9zdGF0ZV90IHJlcV9hdXRoX2FnZW50X3JlcXVpcmV2X3N0YXRlOwogfTsKIAog c3RydWN0IF9MSUJTU0gyX0xJU1RFTkVSCg== --14dae9340a4768955b04bb506ccd Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --14dae9340a4768955b04bb506ccd-- From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 08:36:14 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2G7Zmgw015894; Fri, 16 Mar 2012 08:36:09 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2G7ZklV015877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Mar 2012 08:35:46 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2G7ZkGF015872 for ; Fri, 16 Mar 2012 08:35:46 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 16 Mar 2012 08:35:46 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] Request SSH agent forwarding In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, 15 Mar 2012, Mitchell Hashimoto wrote: > Attached is a patch to add a new method `libssh2_channel_request_auth_agent` > which requests that an agent forwarding listener be started on the remote > side for SSH agent forwarding. Thanks. Can you also provide a man page for this new function so that I can better understand how it is supposed to work? It would also make it easier to review the code. > I've tested the code by modifying the ssh_exec.c example to request agent > forwarding, which worked great. I didn't write a new example though, so I > didn't commit these changes (since it alters ssh_exec). It'd be great if you just renamed your test code then and submitted it as a new example! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 12:15:30 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GBFEdf021256; Fri, 16 Mar 2012 12:15:26 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GBFDk9021252 for ; Fri, 16 Mar 2012 12:15:13 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id C65CF1F29CE for ; Fri, 16 Mar 2012 12:15:14 +0100 (MET) Received: from localhost (it.got.cryptzone.com [172.24.4.4]) by krakatau.got.appgate.com (Postfix) with ESMTP id 9FB90BD407A for ; Fri, 16 Mar 2012 12:15:14 +0100 (CET) Received: from 172.24.4.2 (SquirrelMail authenticated user tom) by localhost with HTTP; Fri, 16 Mar 2012 12:13:50 +0100 Message-ID: <6073dbcf4bcaa9c844fb21f04d0e6e72.squirrel@localhost> In-Reply-To: References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> <4F61BA2B.5050601@cryptzone.com> Date: Fri, 16 Mar 2012 12:13:50 +0100 Subject: Re: Callback for channel data ready From: "Tom Weber" To: "libssh2 development" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Thu, March 15, 2012 10:54, Daniel Stenberg wrote: > It is never too late! We can "easily" add a function today that just reads > everything off the socket, and then you can use the existing > libssh2_channel_read() function just fine (when this API "mode" is used, we > would prevent the channel read functions to try reading anything from the > transport). We could also add a function that can return exactly which > channels that have data pending. > > Or am I missing something? > But how is that "mode" going to be set? Perhaps in the same manner as blocking, as in: libssh2_session_set_automatic_read() libssh2_session_get_automatic_read() Where my suggested mode would be a zero value. Speaking of blocking/nonblocking, the API confuses me when it comes to nonblocking mode and a complex operation returning EAGAIN. Say that I call libssh2_channel_direct_tcpip_ex() (which involves both a send and receive operation) and it returns EAGAIN, then I wonder: 1) Did EAGAIN happen during send or receive? Do I need to care? 2) Do I have to make the same call again until the operation is complete? 3) If yes, do I have to pass in the same arguments? 4) If yes, what happens if I pass in other arguments? 5) If yes, what happens if I start some other operation before this one is complete? From glancing at the code, I guess the answers are: 1) Don't care 2) Yes 3) Yes 4) Depends 5) ??? I think that either the documentation should be clear in this regard (there are no pages about the behavior in general), or a clearer asynchronous API should be implemented, and a synchronous one which builds on that. For instance: libssh2_channel_direct_tcpip_async() Which would return directly, only putting a packet in an out-queue. Then you would need to keep calling: libssh2_session_process() Which both sends and receives as much as possible. It would return an array of flags, such as: ...REQUEST_COMPLETE ...CHANNEL_DATA_RECEIVED ...NEED_POLLOUT Where ...REQUEST_COMPLETE signals that the outstanding request (for simplicity, only one at a time should be allowed) has completed. You would also get the return code for that request, either through the same call or through: libssh2_session_get_request_status() or similar. This would probably be too complicated for simple applications, therefore the asynchronous API should be wrapped inside synchronous helper functions such as (pseudocode): int libssh2_channel_direct_tcpip_sync(...) { int flags; int rc; libssh2_channel_direct_tcpip_async(...); do { poll(...); libssh2_session_process(..., &flags); } while (!(flags & LIBSSH2_REQUEST_COMPLETED)); return libssh2_session_get_request_status(...); } It lacks proper error handling and poll direction checking, but it should illustrate what I mean. Additional benefits of (a)synchronous APIs would be: 1) No need for libssh2_session_set_blocking(), the meaning of which hasn't been entirely clear for me. 2) No need to switch between blocking and nonblocking mode on the socket behind the scenes. Just let it always be nonblocking. 3) An opportunity to get rid of BLOCK_ADJUST(), which I think makes the code significantly harder to read for a newcomer (it did for me). -- Best regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 12:26:08 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GBQ443028363; Fri, 16 Mar 2012 12:26:08 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GBQ2sg028359 for ; Fri, 16 Mar 2012 12:26:02 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id CFCB21F29CE for ; Fri, 16 Mar 2012 12:26:03 +0100 (MET) Received: from localhost (it.got.cryptzone.com [172.24.4.4]) by krakatau.got.appgate.com (Postfix) with ESMTP id A65B5BD407A for ; Fri, 16 Mar 2012 12:26:03 +0100 (CET) Received: from 172.24.4.2 (SquirrelMail authenticated user tom) by localhost with HTTP; Fri, 16 Mar 2012 12:24:39 +0100 Message-ID: In-Reply-To: <6073dbcf4bcaa9c844fb21f04d0e6e72.squirrel@localhost> References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> <4F61BA2B.5050601@cryptzone.com> <6073dbcf4bcaa9c844fb21f04d0e6e72.squirrel@localhost> Date: Fri, 16 Mar 2012 12:24:39 +0100 Subject: Re: Callback for channel data ready From: "Tom Weber" To: "libssh2 development" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Fri, March 16, 2012 12:13, Tom Weber wrote: > > int libssh2_channel_direct_tcpip_sync(...) > { > int flags; > int rc; > > libssh2_channel_direct_tcpip_async(...); > do { > poll(...); > libssh2_session_process(..., &flags); > } while (!(flags & LIBSSH2_REQUEST_COMPLETED)); > > return libssh2_session_get_request_status(...); > } > Before anyone points it out, yes that function should return a pointer to a new channel. Or preferably store it through a destination pointer (LIBSSH2_CHANNEL **) passed in as argument, so that we can get an error code as return value. -- Best regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 13:36:20 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GCa4ja013257; Fri, 16 Mar 2012 13:36:18 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GCa2J6013245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Mar 2012 13:36:02 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2GCa2VE013241 for ; Fri, 16 Mar 2012 13:36:02 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 16 Mar 2012 13:36:02 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Callback for channel data ready In-Reply-To: <6073dbcf4bcaa9c844fb21f04d0e6e72.squirrel@localhost> Message-ID: References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> <4F61BA2B.5050601@cryptzone.com> <6073dbcf4bcaa9c844fb21f04d0e6e72.squirrel@localhost> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Fri, 16 Mar 2012, Tom Weber wrote: > But how is that "mode" going to be set? Perhaps in the same manner as > blocking, as in: I was thinking that there mere use of the "atomic read" function would be signal enough. It would then mark the session as done atomic style. I don't think we need to bother with allowing such a mode to get switched off again. > Speaking of blocking/nonblocking, the API confuses me when it comes to > nonblocking mode and a complex operation returning EAGAIN. Say that I call > libssh2_channel_direct_tcpip_ex() (which involves both a send and receive > operation) and it returns EAGAIN, then I wonder: > > 1) Did EAGAIN happen during send or receive? Do I need to care? See libssh2_session_block_directions() and you need to care if you want to wait for the correct socket actitity before you try again. > 2) Do I have to make the same call again until the operation is complete? Yes. > 3) If yes, do I have to pass in the same arguments? Yes. > 4) If yes, what happens if I pass in other arguments? It might cause failure. > 5) If yes, what happens if I start some other operation before this one is > complete? It might cause confusion and badness. > I think that either the documentation should be clear in this regard (there > are no pages about the behavior in general) Please give us your suggestions! > a clearer asynchronous API should be implemented, and a synchronous one > which builds on that. We've discussed something like that but nobody has yet volunteered to do the work so we keep to the old and existing API... -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 16:29:52 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GFTadq022626; Fri, 16 Mar 2012 16:29:48 +0100 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GFTIs3022488 for ; Fri, 16 Mar 2012 16:29:19 +0100 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2GFTEkO004412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Mar 2012 11:29:14 -0400 Received: from t500.mbooth (ovpn-116-76.ams2.redhat.com [10.36.116.76]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2GFTBsb020411 for ; Fri, 16 Mar 2012 11:29:12 -0400 From: Matthew Booth To: libssh2-devel@cool.haxx.se Subject: [PATCH] transport_send: Check for in-progress key exchange before sending data Date: Fri, 16 Mar 2012 15:29:00 +0000 Message-Id: <1331911740-25966-1-git-send-email-mbooth@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se _libssh2_channel_write() first reads outstanding packets before writing new data. If it reads a key exchange request, it will immediately start key re-exchange, which will require sending a response. If the output socket is full, this will result in a return from _libssh2_transport_read() of LIBSSH2_ERROR_EAGAIN. In order not to block a write because there is no data to read, this error is explicitly ignored and the code continues marshalling a packet for sending. When it is sent, the remote end immediately drops the connection because it was expecting a continuation of the key exchange, but got a data packet. This change adds the same check for key exchange to _libssh2_transport_send() that is in _libssh2_transport_read(). This ensures that key exchange is completed before any data packet is sent. --- src/transport.c | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/src/transport.c b/src/transport.c index c1b0e56..999eadf 100644 --- a/src/transport.c +++ b/src/transport.c @@ -298,7 +298,7 @@ int _libssh2_transport_read(LIBSSH2_SESSION * session) * is done! */ _libssh2_debug(session, LIBSSH2_TRACE_TRANS, "Redirecting into the" - " key re-exchange"); + " key re-exchange from _libssh2_transport_read"); rc = _libssh2_kex_exchange(session, 1, &session->startup_key_state); if (rc) return rc; @@ -689,6 +689,24 @@ int _libssh2_transport_send(LIBSSH2_SESSION *session, const unsigned char *orgdata = data; size_t orgdata_len = data_len; + /* + * If the last read operation was interrupted in the middle of a key + * exchange, we must complete that key exchange before continuing to write + * further data. + * + * See the similar block in _libssh2_transport_read for more details. + */ + if (session->state & LIBSSH2_STATE_EXCHANGING_KEYS && + !(session->state & LIBSSH2_STATE_KEX_ACTIVE)) { + /* Don't write any new packets if we're still in the middle of a key + * exchange. */ + _libssh2_debug(session, LIBSSH2_TRACE_TRANS, "Redirecting into the" + " key re-exchange from _libssh2_transport_send"); + rc = _libssh2_kex_exchange(session, 1, &session->startup_key_state); + if (rc) + return rc; + } + debugdump(session, "libssh2_transport_write plain", data, data_len); if(data2) debugdump(session, "libssh2_transport_write plain2", data2, data2_len); -- 1.7.7.6 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 16:42:35 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GFgDXG000649; Fri, 16 Mar 2012 16:42:32 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GFgB2o000621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Mar 2012 16:42:11 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2GFgAQ6000613 for ; Fri, 16 Mar 2012 16:42:10 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 16 Mar 2012 16:42:10 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: [PATCH] transport_send: Check for in-progress key exchange before sending data In-Reply-To: <1331911740-25966-1-git-send-email-mbooth@redhat.com> Message-ID: References: <1331911740-25966-1-git-send-email-mbooth@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Fri, 16 Mar 2012, Matthew Booth wrote: > This change adds the same check for key exchange to > _libssh2_transport_send() that is in _libssh2_transport_read(). This ensures > that key exchange is completed before any data packet is sent. Sounds perfectly logical to me. Thanks a lot. Pushed! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 22:08:23 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GL7vk5003057; Fri, 16 Mar 2012 22:08:16 +0100 Received: from nic.appgate.com (nic.appgate.com [79.138.127.130]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GL7tbc002948 for ; Fri, 16 Mar 2012 22:07:55 +0100 Received: from krakatau.got.appgate.com (krakatau.got.appgate.com [172.23.2.32]) by nic.appgate.com (Postfix) with ESMTP id 6D3A71F29E6 for ; Fri, 16 Mar 2012 22:07:56 +0100 (MET) Received: from localhost (it.got.cryptzone.com [172.24.4.4]) by krakatau.got.appgate.com (Postfix) with ESMTP id 6CDACBD4065 for ; Fri, 16 Mar 2012 22:07:56 +0100 (CET) Received: from 172.24.4.2 (SquirrelMail authenticated user tom) by localhost with HTTP; Fri, 16 Mar 2012 22:06:52 +0100 Message-ID: In-Reply-To: References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> <4F61BA2B.5050601@cryptzone.com> <6073dbcf4bcaa9c844fb21f04d0e6e72.squirrel@localhost> Date: Fri, 16 Mar 2012 22:06:52 +0100 Subject: Re: Callback for channel data ready From: "Tom Weber" To: "libssh2 development" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Fri, March 16, 2012 13:36, Daniel Stenberg wrote: > It might cause confusion and badness. :-) Thanks for the quick responses! >> a clearer asynchronous API should be implemented, and a synchronous one >> which builds on that. > > We've discussed something like that but nobody has yet volunteered to do the > work so we keep to the old and existing API... Interesting. I'm working on a product which builds on libssh2, and depending on how that plays out, there could be mutual benefits in helping out with libssh2... at the moment I'm swamped in work however. :-P -- Best regards, Tom Weber Cryptzone Group AB _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Mar 16 22:21:22 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GLLH0r013505; Fri, 16 Mar 2012 22:21:21 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2GLLFFq013469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 16 Mar 2012 22:21:15 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2GLLFlX013466 for ; Fri, 16 Mar 2012 22:21:15 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 16 Mar 2012 22:21:15 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: Callback for channel data ready In-Reply-To: Message-ID: References: <20120301034227.14151.qmail@stuge.se> <4a60f4e511b9a5a0b32d5fe872148d8d.squirrel@localhost> <20120302190136.20200.qmail@stuge.se> <4F5DC8BF.8030406@cryptzone.com> <4F5DCCD1.9090502@cryptzone.com> <4F61ABF1.2030605@cryptzone.com> <20120315091302.12421.qmail@stuge.se> <4F61BA2B.5050601@cryptzone.com> <6073dbcf4bcaa9c844fb21f04d0e6e72.squirrel@localhost> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Fri, 16 Mar 2012, Tom Weber wrote: >> We've discussed something like that but nobody has yet volunteered to do >> the work so we keep to the old and existing API... > > Interesting. I'm working on a product which builds on libssh2, and depending > on how that plays out, there could be mutual benefits in helping out with > libssh2... at the moment I'm swamped in work however. :-P I completely understand. But discussing and toying around with designing such an alternative idea could be a first step and something we can do slowly and together and just spend all the time we need to do it. Once we agree somewhat on a decent API we can all just add pieces of code to the library to build the code to implement the interface. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 04:40:21 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2H3dnrN010982; Sat, 17 Mar 2012 04:40:14 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2H3dk8f010961 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 17 Mar 2012 04:39:47 +0100 Received: by iahk25 with SMTP id k25so7512412iah.41 for ; Fri, 16 Mar 2012 20:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=5vhwTSvKqlUpHPMWn38twWps7oESf7ZXn5LTMitnNiE=; b=H5ZO5LS1VL+WEwSZ/tDAcUGe03mA5PZR98JgarzqJiqmBy27JZdhba4MomWQJpwpL0 pYPwfeYUpSvWU5UfxTbP10ow09/PHtuRfcmMLZ95J/5VvtbIs2ov82wi8phoJPF4RrHr Y7gjMHZ8yZ0WgBel4XwEgOg+6T8rdoLimNe5lc63LqFX7C/dXtQpYBnmxtGUBaU1EeII v6CigFeejRsxSciTJACaCEnhPYm9VtWoxPAxlgw9HOf2M/MNEGcpP3zczifKCv6M/ssK Pw5YHetQyeBSlVemZRW+xDCf62eLnsJxvR1kF6bwa4uemOI2faq+7mU733AINC1SZ6cR +aZQ== Received: by 10.50.188.138 with SMTP id ga10mr1069277igc.51.1331955577314; Fri, 16 Mar 2012 20:39:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Fri, 16 Mar 2012 20:39:17 -0700 (PDT) In-Reply-To: References: From: Mitchell Hashimoto Date: Fri, 16 Mar 2012 20:39:17 -0700 X-Google-Sender-Auth: 7PvQnEU6s_OPNLZOnDhAD1tTGGI Message-ID: Subject: Re: [PATCH] Request SSH agent forwarding To: libssh2 development Content-Type: multipart/mixed; boundary=14dae93407f90ade5d04bb681304 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --14dae93407f90ade5d04bb681304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel, On Fri, Mar 16, 2012 at 12:35 AM, Daniel Stenberg wrote: > On Thu, 15 Mar 2012, Mitchell Hashimoto wrote: > >> Attached is a patch to add a new method >> `libssh2_channel_request_auth_agent` which requests that an agent forwar= ding >> listener be started on the remote side for SSH agent forwarding. > > > Thanks. Can you also provide a man page for this new function so that I c= an > better understand how it is supposed to work? It would also make it easie= r > to review the code. Yep, attached. > > >> I've tested the code by modifying the ssh_exec.c example to request agen= t >> forwarding, which worked great. I didn't write a new example though, so = I >> didn't commit these changes (since it alters ssh_exec). > > > It'd be great if you just renamed your test code then and submitted it as= a > new example! Haha maybe if this patch gets accepted. I want to straighten anything out f= irst. How is it now? Mitchell > > -- > > =A0/ daniel.haxx.se > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --14dae93407f90ade5d04bb681304 Content-Type: application/octet-stream; name="request_auth_agent_man.patch" Content-Disposition: attachment; filename="request_auth_agent_man.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzw3xrpm0 ZGlmZiAtLWdpdCBhL2RvY3MvbGlic3NoMl9jaGFubmVsX3JlcXVlc3RfYXV0aF9hZ2VudC4zIGIv ZG9jcy9saWJzc2gyX2NoYW5uZWxfcmVxdWVzdF9hdXRoX2FnZW50LjMKbmV3IGZpbGUgbW9kZSAx MDA2NDQKaW5kZXggMDAwMDAwMC4uZWE3NmE0OAotLS0gL2Rldi9udWxsCisrKyBiL2RvY3MvbGli c3NoMl9jaGFubmVsX3JlcXVlc3RfYXV0aF9hZ2VudC4zCkBAIC0wLDAgKzEsMjIgQEAKKy5USCBs aWJzc2gyX2NoYW5uZWxfcmVxdWVzdF9hdXRoX2FnZW50IDMgIjEgSnVuIDIwMDciICJsaWJzc2gy IDAuMTUiICJsaWJzc2gyIG1hbnVhbCIKKy5TSCBOQU1FCitsaWJzc2gyX2NoYW5uZWxfcmVxdWVz dF9hdXRoX2FnZW50IC0gcmVxdWVzdCBhZ2VudCBmb3J3YXJkaW5nIGZvciBhIHNlc3Npb24KKy5T SCBTWU5PUFNJUworI2luY2x1ZGUgPGxpYnNzaDIuaD4KKworaW50CitsaWJzc2gyX2NoYW5uZWxf cmVxdWVzdF9hdXRoX2FnZW50KExJQlNTSDJfQ0hBTk5FTCAqY2hhbm5lbCk7CisKKy5TSCBERVND UklQVElPTgorUmVxdWVzdCB0aGF0IGFnZW50IGZvcndhcmRpbmcgYmUgZW5hYmxlZCBmb3IgdGhp cyBTU0ggc2Vzc2lvbi4gVGhpcyBzZW5kcyB0aGUKK3JlcXVlc3Qgb3ZlciB0aGlzIHNwZWNpZmlj IGNoYW5uZWwsIHdoaWNoIGNhdXNlcyB0aGUgYWdlbnQgbGlzdGVuZXIgdG8gYmUKK3N0YXJ0ZWQg b24gdGhlIHJlbW90ZSBzaWRlIHVwb24gc3VjY2Vzcy4gVGhpcyBhZ2VudCBsaXN0ZW5lciB3aWxs IHRoZW4gcnVuCitmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBTU0ggc2Vzc2lvbi4KKworXGZJY2hh bm5lbFxmUCAtIFByZXZpb3VzbHkgb3BlbmVkIGNoYW5uZWwgaW5zdGFuY2Ugc3VjaCBhcyByZXR1 cm5lZCBieQorLkJSIGxpYnNzaDJfY2hhbm5lbF9vcGVuX2V4KDMpCisKKy5TSCBSRVRVUk4gVkFM VUUKK1JldHVybiAwIG9uIHN1Y2Nlc3Mgb3IgbmVnYXRpdmUgb24gZmFpbHVyZS4gIEl0IHJldHVy bnMKK0xJQlNTSDJfRVJST1JfRUFHQUlOIHdoZW4gaXQgd291bGQgb3RoZXJ3aXNlIGJsb2NrLiBX aGlsZQorTElCU1NIMl9FUlJPUl9FQUdBSU4gaXMgYSBuZWdhdGl2ZSBudW1iZXIsIGl0IGlzbid0 IHJlYWxseSBhIGZhaWx1cmUgcGVyIHNlLgo= --14dae93407f90ade5d04bb681304 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --14dae93407f90ade5d04bb681304-- From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 15:09:50 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HE9NUi009614; Sat, 17 Mar 2012 15:09:44 +0100 Received: from goalkeeper.city-fan.org (pghmcfc-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:d97::2]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HE9J88009594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Mar 2012 15:09:21 +0100 Received: from zion.city-fan.org (zion.city-fan.org [IPv6:2001:470:9279::2]) (authenticated bits=0) by goalkeeper.city-fan.org (8.14.5/8.14.5) with ESMTP id q2HE9HjM012829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 17 Mar 2012 14:09:20 GMT Date: Sat, 17 Mar 2012 14:09:17 +0000 From: Paul Howarth To: libssh2 development Subject: OpenSSL AES-CTR not working? Message-ID: <20120317140917.3f9ad134@zion.city-fan.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se I've been trying to build libssh2 (1.4.0) against openssl 1.0.1 in Fedora Rawhide and it fails to build because global.c calls _libssh2_init_aes_ctr but that function isn't defined in openssl.c if HAVE_EVP_AES_128_CTR is defined, resulting in: /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z,relro -o direct_tcpip direct_tcpip.o ../src/libssh2.la libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z -Wl,relro -o .libs/direct_tcpip direct_tcpip.o ../src/.libs/libssh2.so -Wl,-rpath -Wl,/usr/lib64 ../src/.libs/libssh2.so: undefined reference to `_libssh2_init_aes_ctr' collect2: error: ld returned 1 exit status So I tried patching global.c not to call _libssh2_init_aes_ctr if HAVE_EVP_AES_128_CTR is defined, which fixed the compile problem but broke the test suite: Connection from 127.0.0.1 port 49111^M debug1: Client protocol version 2.0; client software version libssh2_1.4.0^M debug1: no match: libssh2_1.4.0^M debug1: Enabling compatibility mode for protocol 2.0^M debug1: Local version string SSH-2.0-OpenSSH_5.9^M debug2: fd 3 setting O_NONBLOCK^M debug1: list_hostkey_types: ssh-rsa^M debug1: SSH2_MSG_KEXINIT sent^M debug1: SSH2_MSG_KEXINIT received^M debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1^M debug2: kex_parse_kexinit: ssh-rsa^M debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se^M debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se^M debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96^M debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96^M debug2: kex_parse_kexinit: none,zlib@openssh.com^M debug2: kex_parse_kexinit: none,zlib@openssh.com^M debug2: kex_parse_kexinit: ^M debug2: kex_parse_kexinit: ^M debug2: kex_parse_kexinit: first_kex_follows 0 ^M debug2: kex_parse_kexinit: reserved 0 ^M debug2: kex_parse_kexinit: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1^M debug2: kex_parse_kexinit: ssh-rsa,ssh-dss^M debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-cbc,aes128-cbc,blowfish-cbc,arcfour128,arcfour,cast128-cbc,3des-cbc^M debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-cbc,aes128-cbc,blowfish-cbc,arcfour128,arcfour,cast128-cbc,3des-cbc^M debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com^M debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com^M debug2: kex_parse_kexinit: none^M debug2: kex_parse_kexinit: none^M debug2: kex_parse_kexinit: ^M debug2: kex_parse_kexinit: ^M debug2: kex_parse_kexinit: first_kex_follows 0 ^M debug2: kex_parse_kexinit: reserved 0 ^M debug2: mac_setup: found hmac-sha1^M debug1: kex: client->server aes128-ctr hmac-sha1 none^M debug2: mac_setup: found hmac-sha1^M debug1: kex: server->client aes128-ctr hmac-sha1 none^M debug2: dh_gen_key: priv key bits set: 176/320^M debug2: bits set: 1022/2048^M debug1: expecting SSH2_MSG_KEXDH_INIT^M debug2: bits set: 1012/2048^M debug2: kex_derive_keys^M debug2: set_newkeys: mode 1^M debug1: SSH2_MSG_NEWKEYS sent^M debug1: expecting SSH2_MSG_NEWKEYS^M debug2: set_newkeys: mode 0^M debug1: SSH2_MSG_NEWKEYS received^M debug1: KEX done^M Corrupted MAC on input.^M Disconnecting: Packet corrupt^M Do the openssl EVP functions need some initialization to fix this? Paul. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 15:13:46 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HEDjY7012359; Sat, 17 Mar 2012 15:13:46 +0100 Received: from goalkeeper.city-fan.org (pghmcfc-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:d97::2]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HEDhEM012345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Mar 2012 15:13:43 +0100 Received: from zion.city-fan.org (zion.city-fan.org [IPv6:2001:470:9279::2]) (authenticated bits=0) by goalkeeper.city-fan.org (8.14.5/8.14.5) with ESMTP id q2HEDilM012870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 17 Mar 2012 14:13:44 GMT Date: Sat, 17 Mar 2012 14:13:43 +0000 From: Paul Howarth To: libssh2-devel@cool.haxx.se Subject: Re: OpenSSL AES-CTR not working? Message-ID: <20120317141343.19c56d80@zion.city-fan.org> In-Reply-To: <20120317140917.3f9ad134@zion.city-fan.org> References: <20120317140917.3f9ad134@zion.city-fan.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sat, 17 Mar 2012 14:09:17 +0000 Paul Howarth wrote: > I've been trying to build libssh2 (1.4.0) against openssl 1.0.1 in > Fedora Rawhide and it fails to build because global.c calls > _libssh2_init_aes_ctr but that function isn't defined in openssl.c if > HAVE_EVP_AES_128_CTR is defined, resulting in: > > /bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z,relro -o > direct_tcpip direct_tcpip.o ../src/libssh2.la libtool: link: gcc -O2 > -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z -Wl,relro > -o .libs/direct_tcpip direct_tcpip.o ../src/.libs/libssh2.so > -Wl,-rpath -Wl,/usr/lib64 ../src/.libs/libssh2.so: undefined > reference to `_libssh2_init_aes_ctr' collect2: error: ld returned 1 > exit status > > So I tried patching global.c not to call _libssh2_init_aes_ctr if > HAVE_EVP_AES_128_CTR is defined, which fixed the compile problem but > broke the test suite: > (snip) I'm able to work around this for now by disabling the AES-CTR detection in configure, by doing: export ac_cv_func_EVP_aes_128_ctr=no before running the configure script, so it doesn't try to use the openssl functions. Paul. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 16:15:54 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HFFZYk024434; Sat, 17 Mar 2012 16:15:53 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2HFFX7P024415 for ; Sat, 17 Mar 2012 16:15:33 +0100 Received: (qmail 10550 invoked by uid 501); 17 Mar 2012 15:15:34 -0000 Message-ID: <20120317151534.10549.qmail@stuge.se> Date: Sat, 17 Mar 2012 16:15:34 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] Request SSH agent forwarding Mail-Followup-To: libssh2-devel@cool.haxx.se References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Mitchell Hashimoto wrote: > > It'd be great if you just renamed your test code then and > > submitted it as a new example! > > Haha maybe if this patch gets accepted. No, at the same time. > How is it now? Please use git to create a commit locally with your changes, and generate the patch file using git format-patch. If you run into any trouble using git please feel free to ask and we'll help out. Make sure to configure your name and email in git before you commit so that authorship information is correct. git config --global user.name 'Mitchell Hashimoto' git config --global user.email your@email.addr //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 17:50:36 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HGoI6E030757; Sat, 17 Mar 2012 17:50:32 +0100 Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HGoDZf030706 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 17 Mar 2012 17:50:16 +0100 Received: by dald2 with SMTP id d2so7918404dal.41 for ; Sat, 17 Mar 2012 09:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=RGMztbuHOa/LBhMDBirpA+DXdLhymzsIJ27ICeerih8=; b=KqUnD3dWsj7WTMjwx1mfRdQBpqbQimmUFpYlJlydEI66laeUKblIL/9QgooyAPl1lx 0Y9p/9OMdILJMPiWrWeNGFa7cC86RhRFMfcCZAJOOLDD9ca97145l4IAD4Ki+hyId9G2 rNdgqF7Z2sUWhiejyNyAqvNjo4WqhzHBxny9avSllDptW6tH9yCh024t+9doXxa43iNU Ie5CFy0HprVmP6uIg8WSecDyg6aRXSdO8mJAGbnqAjIr6jYCyXFJpgsnDN6OK/DqTNME dutP1NPEQyfGP/yyUI1iUkwz61BOIzBn1fr0/t6vUHlpovEoAodA1632QGc3mi+91uIT ev8A== Received: by 10.68.196.162 with SMTP id in2mr24890850pbc.17.1332003009946; Sat, 17 Mar 2012 09:50:09 -0700 (PDT) Received: from localhost.localdomain (10.sub-166-250-19.myvzw.com. [166.250.19.10]) by mx.google.com with ESMTPS id u5sm1587947pbu.76.2012.03.17.09.50.08 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Mar 2012 09:50:09 -0700 (PDT) From: Mitchell Hashimoto To: libssh2-devel@cool.haxx.se Subject: [PATCH] libssh2_channel_request_auth_agent Date: Sat, 17 Mar 2012 10:49:57 -0600 Message-Id: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> X-Mailer: git-send-email 1.7.8.4 In-Reply-To: References: Cc: Mitchell Hashimoto X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se This method will request SSH agent forwarding for the SSH session. The method is on the channel itself because it must be sent over a channel, but this simply starts the SSH agent receiver on the remote side. This includes the new API, documentation, and a new example. --- docs/libssh2_channel_request_auth_agent.3 | 22 ++ example/.gitignore | 1 + example/Makefile.am | 4 +- example/ssh2_agent_forwarding.c | 331 +++++++++++++++++++++++++++++ include/libssh2.h | 2 + src/channel.c | 152 +++++++++++++ src/libssh2_priv.h | 7 + 7 files changed, 517 insertions(+), 2 deletions(-) create mode 100644 docs/libssh2_channel_request_auth_agent.3 create mode 100644 example/ssh2_agent_forwarding.c diff --git a/docs/libssh2_channel_request_auth_agent.3 b/docs/libssh2_channel_request_auth_agent.3 new file mode 100644 index 0000000..ea76a48 --- /dev/null +++ b/docs/libssh2_channel_request_auth_agent.3 @@ -0,0 +1,22 @@ +.TH libssh2_channel_request_auth_agent 3 "1 Jun 2007" "libssh2 0.15" "libssh2 manual" +.SH NAME +libssh2_channel_request_auth_agent - request agent forwarding for a session +.SH SYNOPSIS +#include + +int +libssh2_channel_request_auth_agent(LIBSSH2_CHANNEL *channel); + +.SH DESCRIPTION +Request that agent forwarding be enabled for this SSH session. This sends the +request over this specific channel, which causes the agent listener to be +started on the remote side upon success. This agent listener will then run +for the duration of the SSH session. + +\fIchannel\fP - Previously opened channel instance such as returned by +.BR libssh2_channel_open_ex(3) + +.SH RETURN VALUE +Return 0 on success or negative on failure. It returns +LIBSSH2_ERROR_EAGAIN when it would otherwise block. While +LIBSSH2_ERROR_EAGAIN is a negative number, it isn't really a failure per se. diff --git a/example/.gitignore b/example/.gitignore index 1344819..e3c6337 100644 --- a/example/.gitignore +++ b/example/.gitignore @@ -20,6 +20,7 @@ sftp_write_nonblock config.h.in ssh2_exec ssh2_agent +ssh2_agent_forwarding libssh2_config.h libssh2_config.h.in stamp-h2 diff --git a/example/Makefile.am b/example/Makefile.am index 8c6636f..bd4eefd 100644 --- a/example/Makefile.am +++ b/example/Makefile.am @@ -6,8 +6,8 @@ EXTRA_DIST = libssh2_config.h.in noinst_PROGRAMS = direct_tcpip ssh2 scp scp_nonblock scp_write \ scp_write_nonblock sftp sftp_nonblock sftp_write sftp_write_nonblock \ sftp_mkdir sftp_mkdir_nonblock sftp_RW_nonblock sftp_write_sliding \ - sftpdir sftpdir_nonblock ssh2_exec ssh2_agent ssh2_echo sftp_append \ - subsystem_netconf tcpip-forward + sftpdir sftpdir_nonblock ssh2_exec ssh2_agent ssh2_agent_forwarding \ + ssh2_echo sftp_append subsystem_netconf tcpip-forward if HAVE_SYS_UN_H noinst_PROGRAMS += x11 diff --git a/example/ssh2_agent_forwarding.c b/example/ssh2_agent_forwarding.c new file mode 100644 index 0000000..94c7516 --- /dev/null +++ b/example/ssh2_agent_forwarding.c @@ -0,0 +1,331 @@ +/* + * Sample showing how to use libssh2 to request agent forwarding + * on the remote host. The command executed will run with agent forwarded + * so you should be able to do things like clone out protected git + * repos and such. + * + * The sample code has fixed values for host name, user name, password + * and command to run. + * + * Run it like this: + * + * $ ./ssh2_agent_forwarding 127.0.0.1 user password "uptime" + * + */ + +#include "libssh2_config.h" +#include + +#ifdef HAVE_WINSOCK2_H +# include +#endif +#ifdef HAVE_SYS_SOCKET_H +# include +#endif +#ifdef HAVE_NETINET_IN_H +# include +#endif +#ifdef HAVE_SYS_SELECT_H +# include +#endif +# ifdef HAVE_UNISTD_H +#include +#endif +#ifdef HAVE_ARPA_INET_H +# include +#endif + +#include +#include +#include +#include +#include +#include +#include + +static int waitsocket(int socket_fd, LIBSSH2_SESSION *session) +{ + struct timeval timeout; + int rc; + fd_set fd; + fd_set *writefd = NULL; + fd_set *readfd = NULL; + int dir; + + timeout.tv_sec = 10; + timeout.tv_usec = 0; + + FD_ZERO(&fd); + + FD_SET(socket_fd, &fd); + + /* now make sure we wait in the correct direction */ + dir = libssh2_session_block_directions(session); + + if(dir & LIBSSH2_SESSION_BLOCK_INBOUND) + readfd = &fd; + + if(dir & LIBSSH2_SESSION_BLOCK_OUTBOUND) + writefd = &fd; + + rc = select(socket_fd + 1, readfd, writefd, NULL, &timeout); + + return rc; +} + +int main(int argc, char *argv[]) +{ + const char *hostname = "127.0.0.1"; + const char *commandline = "uptime"; + const char *username = "user"; + const char *password = "password"; + unsigned long hostaddr; + int sock; + struct sockaddr_in sin; + const char *fingerprint; + LIBSSH2_SESSION *session; + LIBSSH2_CHANNEL *channel; + int rc; + int exitcode; + char *exitsignal=(char *)"none"; + int bytecount = 0; + size_t len; + LIBSSH2_KNOWNHOSTS *nh; + int type; + +#ifdef WIN32 + WSADATA wsadata; + WSAStartup(MAKEWORD(2,0), &wsadata); +#endif + if (argc > 1) + /* must be ip address only */ + hostname = argv[1]; + + if (argc > 2) { + username = argv[2]; + } + if (argc > 3) { + password = argv[3]; + } + if (argc > 4) { + commandline = argv[4]; + } + + rc = libssh2_init (0); + if (rc != 0) { + fprintf (stderr, "libssh2 initialization failed (%d)\n", rc); + return 1; + } + + hostaddr = inet_addr(hostname); + + /* Ultra basic "connect to port 22 on localhost" + * Your code is responsible for creating the socket establishing the + * connection + */ + sock = socket(AF_INET, SOCK_STREAM, 0); + + sin.sin_family = AF_INET; + sin.sin_port = htons(22); + sin.sin_addr.s_addr = hostaddr; + if (connect(sock, (struct sockaddr*)(&sin), + sizeof(struct sockaddr_in)) != 0) { + fprintf(stderr, "failed to connect!\n"); + return -1; + } + + /* Create a session instance */ + session = libssh2_session_init(); + if (!session) + return -1; + + /* tell libssh2 we want it all done non-blocking */ + libssh2_session_set_blocking(session, 0); + + /* ... start it up. This will trade welcome banners, exchange keys, + * and setup crypto, compression, and MAC layers + */ + while ((rc = libssh2_session_handshake(session, sock)) == + LIBSSH2_ERROR_EAGAIN); + if (rc) { + fprintf(stderr, "Failure establishing SSH session: %d\n", rc); + return -1; + } + + nh = libssh2_knownhost_init(session); + if(!nh) { + /* eeek, do cleanup here */ + return 2; + } + + /* read all hosts from here */ + libssh2_knownhost_readfile(nh, "known_hosts", + LIBSSH2_KNOWNHOST_FILE_OPENSSH); + + /* store all known hosts to here */ + libssh2_knownhost_writefile(nh, "dumpfile", + LIBSSH2_KNOWNHOST_FILE_OPENSSH); + + fingerprint = libssh2_session_hostkey(session, &len, &type); + if(fingerprint) { + struct libssh2_knownhost *host; +#if LIBSSH2_VERSION_NUM >= 0x010206 + /* introduced in 1.2.6 */ + int check = libssh2_knownhost_checkp(nh, hostname, 22, + fingerprint, len, + LIBSSH2_KNOWNHOST_TYPE_PLAIN| + LIBSSH2_KNOWNHOST_KEYENC_RAW, + &host); +#else + /* 1.2.5 or older */ + int check = libssh2_knownhost_check(nh, hostname, + fingerprint, len, + LIBSSH2_KNOWNHOST_TYPE_PLAIN| + LIBSSH2_KNOWNHOST_KEYENC_RAW, + &host); +#endif + fprintf(stderr, "Host check: %d, key: %s\n", check, + (check <= LIBSSH2_KNOWNHOST_CHECK_MISMATCH)? + host->key:""); + + /***** + * At this point, we could verify that 'check' tells us the key is + * fine or bail out. + *****/ + } + else { + /* eeek, do cleanup here */ + return 3; + } + libssh2_knownhost_free(nh); + + if ( strlen(password) != 0 ) { + /* We could authenticate via password */ + while ((rc = libssh2_userauth_password(session, username, password)) == + LIBSSH2_ERROR_EAGAIN); + if (rc) { + fprintf(stderr, "Authentication by password failed.\n"); + goto shutdown; + } + } + else { + /* Or by public key */ + while ((rc = libssh2_userauth_publickey_fromfile(session, username, + "/home/user/" + ".ssh/id_rsa.pub", + "/home/user/" + ".ssh/id_rsa", + password)) == + LIBSSH2_ERROR_EAGAIN); + if (rc) { + fprintf(stderr, "\tAuthentication by public key failed\n"); + goto shutdown; + } + } + +#if 0 + libssh2_trace(session, ~0 ); +#endif + + /* Exec non-blocking on the remove host */ + while( (channel = libssh2_channel_open_session(session)) == NULL && + libssh2_session_last_error(session,NULL,NULL,0) == + LIBSSH2_ERROR_EAGAIN ) + { + waitsocket(sock, session); + } + if( channel == NULL ) + { + fprintf(stderr,"Error\n"); + exit( 1 ); + } + while( (rc = libssh2_channel_request_auth_agent(channel)) == + LIBSSH2_ERROR_EAGAIN ) + { + waitsocket(sock, session); + } + if ( rc != 0 ) + { + fprintf(stderr, "Error, couldn't request auth agent.\n"); + exit( 1 ); + } + while( (rc = libssh2_channel_exec(channel, commandline)) == + LIBSSH2_ERROR_EAGAIN ) + { + waitsocket(sock, session); + } + if( rc != 0 ) + { + fprintf(stderr,"Error\n"); + exit( 1 ); + } + for( ;; ) + { + /* loop until we block */ + int rc; + do + { + char buffer[0x4000]; + rc = libssh2_channel_read( channel, buffer, sizeof(buffer) ); + if( rc > 0 ) + { + int i; + bytecount += rc; + fprintf(stderr, "We read:\n"); + for( i=0; i < rc; ++i ) + fputc( buffer[i], stderr); + fprintf(stderr, "\n"); + } + else { + if( rc != LIBSSH2_ERROR_EAGAIN ) + /* no need to output this for the EAGAIN case */ + fprintf(stderr, "libssh2_channel_read returned %d\n", rc); + } + } + while( rc > 0 ); + + /* this is due to blocking that would occur otherwise so we loop on + this condition */ + if( rc == LIBSSH2_ERROR_EAGAIN ) + { + waitsocket(sock, session); + } + else + break; + } + exitcode = 127; + while( (rc = libssh2_channel_close(channel)) == LIBSSH2_ERROR_EAGAIN ) + waitsocket(sock, session); + + if( rc == 0 ) + { + exitcode = libssh2_channel_get_exit_status( channel ); + libssh2_channel_get_exit_signal(channel, &exitsignal, + NULL, NULL, NULL, NULL, NULL); + } + + if (exitsignal) + printf("\nGot signal: %s\n", exitsignal); + else + printf("\nEXIT: %d bytecount: %d\n", exitcode, bytecount); + + libssh2_channel_free(channel); + channel = NULL; + +shutdown: + + libssh2_session_disconnect(session, + "Normal Shutdown, Thank you for playing"); + libssh2_session_free(session); + +#ifdef WIN32 + closesocket(sock); +#else + close(sock); +#endif + fprintf(stderr, "all done\n"); + + libssh2_exit(); + + return 0; +} diff --git a/include/libssh2.h b/include/libssh2.h index 5a22be2..b50a001 100644 --- a/include/libssh2.h +++ b/include/libssh2.h @@ -638,6 +638,8 @@ LIBSSH2_API int libssh2_channel_setenv_ex(LIBSSH2_CHANNEL *channel, libssh2_channel_setenv_ex((channel), (varname), strlen(varname), (value), \ strlen(value)) +LIBSSH2_API int libssh2_channel_request_auth_agent(LIBSSH2_CHANNEL *channel); + LIBSSH2_API int libssh2_channel_request_pty_ex(LIBSSH2_CHANNEL *channel, const char *term, unsigned int term_len, diff --git a/src/channel.c b/src/channel.c index 9e29492..54910ef 100644 --- a/src/channel.c +++ b/src/channel.c @@ -973,6 +973,158 @@ static int channel_request_pty(LIBSSH2_CHANNEL *channel, "Unable to complete request for channel request-pty"); } +/** + * channel_request_auth_agent + * The actual re-entrant method which requests an auth agent. + * */ +static int channel_request_auth_agent(LIBSSH2_CHANNEL *channel, + const char *request_str, + int request_str_len) +{ + LIBSSH2_SESSION *session = channel->session; + unsigned char *s; + static const unsigned char reply_codes[3] = + { SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE, 0 }; + int rc; + + if (channel->req_auth_agent_state == libssh2_NB_state_idle) { + /* Only valid options are "auth-agent-req" and + * "auth-agent-req@openssh.com" so we make sure it is not + * actually longer than the longest possible. */ + if(request_str_len > 26) { + return _libssh2_error(session, LIBSSH2_ERROR_INVAL, + "request_str length too large"); + } + + /* + * Length: 24 or 36 = packet_type(1) + channel(4) + req_len(4) + + * request_str (variable) + want_reply (1) */ + channel->req_auth_agent_packet_len = 10 + request_str_len; + + /* Zero out the requireev state to reset */ + memset(&channel->req_auth_agent_requirev_state, 0, + sizeof(channel->req_auth_agent_requirev_state)); + + _libssh2_debug(session, LIBSSH2_TRACE_CONN, + "Requesting auth agent on channel %lu/%lu", + channel->local.id, channel->remote.id); + + /* + * byte SSH_MSG_CHANNEL_REQUEST + * uint32 recipient channel + * string "auth-agent-req" + * boolean want reply + * */ + s = channel->req_auth_agent_packet; + *(s++) = SSH_MSG_CHANNEL_REQUEST; + _libssh2_store_u32(&s, channel->remote.id); + _libssh2_store_str(&s, (char *)request_str, request_str_len); + *(s++) = 0x01; + + channel->req_auth_agent_state = libssh2_NB_state_created; + } + + if (channel->req_auth_agent_state == libssh2_NB_state_created) { + /* Send the packet, we can use sizeof() on the packet because it + * is always completely filled; there are no variable length fields. */ + rc = _libssh2_transport_send(session, channel->req_auth_agent_packet, + channel->req_auth_agent_packet_len, + NULL, 0); + + if (rc == LIBSSH2_ERROR_EAGAIN) { + _libssh2_error(session, rc, + "Would block sending auth-agent request"); + } else if (rc) { + channel->req_auth_agent_state = libssh2_NB_state_idle; + return _libssh2_error(session, rc, + "Unable to send auth-agent request"); + } + + _libssh2_htonu32(channel->req_auth_agent_local_channel, + channel->local.id); + + channel->req_auth_agent_state = libssh2_NB_state_sent; + } + + if (channel->req_auth_agent_state == libssh2_NB_state_sent) { + unsigned char *data; + size_t data_len; + unsigned char code; + + rc = _libssh2_packet_requirev(session, reply_codes, &data, &data_len, + 1, channel->req_auth_agent_local_channel, + 4, &channel->req_auth_agent_requirev_state); + + if (rc == LIBSSH2_ERROR_EAGAIN) { + return rc; + } else if (rc) { + channel->req_auth_agent_state = libssh2_NB_state_idle; + return _libssh2_error(session, LIBSSH2_ERROR_PROTO, + "Failed to request auth-agent"); + } + + code = data[0]; + + LIBSSH2_FREE(session, data); + channel->req_auth_agent_state = libssh2_NB_state_idle; + + if (code == SSH_MSG_CHANNEL_SUCCESS) + return 0; + } + + return _libssh2_error(session, LIBSSH2_ERROR_CHANNEL_REQUEST_DENIED, + "Unable to complete request for auth-agent"); +} + +/* + * libssh2_channel_request_auth_agent + * Requests that agent forwarding be enabled for the session. The + * request must be sent over a specific channel, which starts the agent + * listener on the remote side. Once the channel is closed, the agent + * listener continues to exist. + * */ +LIBSSH2_API int +libssh2_channel_request_auth_agent(LIBSSH2_CHANNEL *channel) +{ + int rc; + + if (!channel) + return LIBSSH2_ERROR_BAD_USE; + + /* The current RFC draft for agent forwarding says you're supposed to + * send "auth-agent-req," but most SSH servers out there right now + * actually expect "auth-agent-req@openssh.com," so we try that + * first. */ + if (channel->req_auth_agent_try_state == libssh2_NB_state_idle) { + BLOCK_ADJUST(rc, channel->session, + channel_request_auth_agent(channel, + "auth-agent-req@openssh.com", + 26)); + + /* If we failed (but not with EAGAIN), then we move onto + * the next step to try another request type. */ + if (rc != 0 && rc != LIBSSH2_ERROR_EAGAIN) + channel->req_auth_agent_try_state = libssh2_NB_state_sent; + } + + if (channel->req_auth_agent_try_state == libssh2_NB_state_sent) { + BLOCK_ADJUST(rc, channel->session, + channel_request_auth_agent(channel, + "auth-agent-req", 14)); + + /* If we failed without an EAGAIN, then move on with this + * state machine. */ + if (rc != 0 && rc != LIBSSH2_ERROR_EAGAIN) + channel->req_auth_agent_try_state = libssh2_NB_state_sent1; + } + + /* If things are good, reset the try state. */ + if (rc == 0) + channel->req_auth_agent_try_state = libssh2_NB_state_idle; + + return rc; +} + /* * libssh2_channel_request_pty_ex * Duh... Request a PTY diff --git a/src/libssh2_priv.h b/src/libssh2_priv.h index c670a16..1f4da40 100644 --- a/src/libssh2_priv.h +++ b/src/libssh2_priv.h @@ -428,6 +428,13 @@ struct _LIBSSH2_CHANNEL /* State variables used in libssh2_channel_handle_extended_data2() */ libssh2_nonblocking_states extData2_state; + /* State variables used in libssh2_channel_request_auth_agent() */ + libssh2_nonblocking_states req_auth_agent_try_state; + libssh2_nonblocking_states req_auth_agent_state; + unsigned char req_auth_agent_packet[36]; + size_t req_auth_agent_packet_len; + unsigned char req_auth_agent_local_channel[4]; + packet_requirev_state_t req_auth_agent_requirev_state; }; struct _LIBSSH2_LISTENER -- 1.7.8.4 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 17:51:29 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HGpS5a031483; Sat, 17 Mar 2012 17:51:29 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HGpPxi031422 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 17 Mar 2012 17:51:26 +0100 Received: by iahk25 with SMTP id k25so8418717iah.41 for ; Sat, 17 Mar 2012 09:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=Ad/GyRcIEp0MFpr/s4UABRSayFLKMCug4m6WjAi2YRI=; b=xmMVyFpBRHEEN49ZF5F4OBUcgWuzkccng2PeMdAQD5P/mUHqPnN+OwSfAT1TzHqiZi g5keGv7GH4JJ/HmCz3bm2p4pI2mBAvkUpO9Iq+lKkS2kd8QmqtYohYucmnhDIwGMam7J /azShGPOYcndOb3WmHsxxIOgWwrGpsivcEdeLzYXX1Dvf9vYmdmVHzb6DtCfxU4zZGM5 hYVifdhmSWqh5FYlCiYsHW0tAPG6pAZ7DF19H+Szxf9FcsVLzj9lUKlCg7iF8O9+fBPA /9Dl+ltVOCdJe3ykwF4Kq25upYlKQzKsgKmTNBHqdc1AQSxvK0n6pAoX87RvBSoDpnoc zx2g== Received: by 10.50.188.138 with SMTP id ga10mr2198546igc.51.1332003081193; Sat, 17 Mar 2012 09:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Sat, 17 Mar 2012 09:51:00 -0700 (PDT) In-Reply-To: <20120317151534.10549.qmail@stuge.se> References: <20120317151534.10549.qmail@stuge.se> From: Mitchell Hashimoto Date: Sat, 17 Mar 2012 09:51:00 -0700 X-Google-Sender-Auth: 8IR9fxDEmcWocIBT9gOsiSFXstk Message-ID: Subject: Re: [PATCH] Request SSH agent forwarding To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Peter, On Sat, Mar 17, 2012 at 8:15 AM, Peter Stuge wrote: > Mitchell Hashimoto wrote: >> > It'd be great if you just renamed your test code then and >> > submitted it as a new example! >> >> Haha maybe if this patch gets accepted. > > No, at the same time. > Added. > >> How is it now? > > Please use git to create a commit locally with your changes, and > generate the patch file using git format-patch. If you run into any > trouble using git please feel free to ask and we'll help out. > > Make sure to configure your name and email in git before you commit > so that authorship information is correct. > > git config --global user.name 'Mitchell Hashimoto' > git config --global user.email your@email.addr > Ah right, I completely forgot about format-patch/send-email. I've been spoiled by GitHub pull requests :( I've sent the patch now in a separate email, properly formatted. Thanks, Mitchell > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 18:31:46 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HHVRwp025761; Sat, 17 Mar 2012 18:31:42 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2HHVPpm025756 for ; Sat, 17 Mar 2012 18:31:25 +0100 Received: (qmail 20565 invoked by uid 501); 17 Mar 2012 17:31:27 -0000 Message-ID: <20120317173127.20564.qmail@stuge.se> Date: Sat, 17 Mar 2012 18:31:27 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] libssh2_channel_request_auth_agent Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Mitchell Hashimoto wrote: > +int > +libssh2_channel_request_auth_agent(LIBSSH2_CHANNEL *channel); > + > +.SH DESCRIPTION > +Request that agent forwarding be enabled for this SSH session. This sends the > +request over this specific channel, which causes the agent listener to be > +started on the remote side upon success. This agent listener will then run > +for the duration of the SSH session. > + > +\fIchannel\fP - Previously opened channel instance such as returned by > +.BR libssh2_channel_open_ex(3) This doesn't make any sense to me. Model like the existing API which create a special purpose channel, and reuse their infrastructure, specifically libssh2_channel_process_startup(). See libssh2.h about libssh2_channel_subsystem. > +++ b/example/ssh2_agent_forwarding.c > @@ -0,0 +1,331 @@ .. > +int main(int argc, char *argv[]) > +{ > + const char *hostname = "127.0.0.1"; > + const char *commandline = "uptime"; Suggest commandline "ssh-add -l" which will actually show the agent forwarding being used. > + /* tell libssh2 we want it all done non-blocking */ > + libssh2_session_set_blocking(session, 0); Move this call to much later.. > + while ((rc = libssh2_session_handshake(session, sock)) == > + LIBSSH2_ERROR_EAGAIN); .. > + while ((rc = libssh2_userauth_password(session, username, password)) == > + LIBSSH2_ERROR_EAGAIN); .. > + while ((rc = libssh2_userauth_publickey_fromfile(session, username, > + "/home/user/" > + ".ssh/id_rsa.pub", > + "/home/user/" > + ".ssh/id_rsa", > + password)) == > + LIBSSH2_ERROR_EAGAIN); .. > + while( (channel = libssh2_channel_open_session(session)) == NULL && > + libssh2_session_last_error(session,NULL,NULL,0) == > + LIBSSH2_ERROR_EAGAIN ) > + { > + waitsocket(sock, session); > + } .. > + while( (rc = libssh2_channel_request_auth_agent(channel)) == > + LIBSSH2_ERROR_EAGAIN ) > + { > + waitsocket(sock, session); > + } .. > + while( (rc = libssh2_channel_exec(channel, commandline)) == > + LIBSSH2_ERROR_EAGAIN ) > + { > + waitsocket(sock, session); > + } .. So that you do not need these very ugly loops! > + for( ;; ) > + { > + /* loop until we block */ > + int rc; > + do > + { > + char buffer[0x4000]; > + rc = libssh2_channel_read( channel, buffer, sizeof(buffer) ); > + if( rc > 0 ) > + { > + int i; > + bytecount += rc; > + fprintf(stderr, "We read:\n"); > + for( i=0; i < rc; ++i ) > + fputc( buffer[i], stderr); > + fprintf(stderr, "\n"); > + } > + else { > + if( rc != LIBSSH2_ERROR_EAGAIN ) > + /* no need to output this for the EAGAIN case */ > + fprintf(stderr, "libssh2_channel_read returned %d\n", rc); > + } > + } > + while( rc > 0 ); > + > + /* this is due to blocking that would occur otherwise so we loop on > + this condition */ > + if( rc == LIBSSH2_ERROR_EAGAIN ) > + { > + waitsocket(sock, session); > + } > + else > + break; > + } In fact, there is no reason at all to set non-blocking in this example. It makes the code very ugly and is completely unneccessary. > + while( (rc = libssh2_channel_close(channel)) == LIBSSH2_ERROR_EAGAIN ) > + waitsocket(sock, session); Another ugly loop. Please get rid of all of them. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 18:34:59 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HHYuT6027521; Sat, 17 Mar 2012 18:34:58 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HHYqBV027444 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 17 Mar 2012 18:34:54 +0100 Received: by iahk25 with SMTP id k25so8475142iah.41 for ; Sat, 17 Mar 2012 10:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=3VHxWcHZ6K9KIGGF3CUI3F5ie6j4PCyPti9CdwetxTg=; b=cbfcRwJetjUemYSMd40BujsuyDB1RPNy68e0YpfEDcGft+geR97ZoaMffv/WLpLLpv rEEJFQroUz4aVz9J9rqZkAiRnkuO6e0MEa5gFhuRINjz7oph7cUFDF9lm7h4Ih31sJm1 uDIVrdjLjy2Fw7XwEX1wRIVBE7CgIg53s7E+BRYWBYoO44BsDz/rofSxyMrtrWUBXKp7 8GSLl2TYsrBK4RR05gzgbCUZbWsBTg8zm+lOhi9TemAEbw1b6VY1tsPHC9+qhulM0eAU eXzzYqbw4VxqezXdN2RxMIaMRR1siLnvB2EJxkMJQgVrrtqKpN6wQual/XWQhi5QvvDN 5OZQ== Received: by 10.50.212.101 with SMTP id nj5mr2281200igc.41.1332005687413; Sat, 17 Mar 2012 10:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Sat, 17 Mar 2012 10:34:27 -0700 (PDT) In-Reply-To: <20120317173127.20564.qmail@stuge.se> References: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> <20120317173127.20564.qmail@stuge.se> From: Mitchell Hashimoto Date: Sat, 17 Mar 2012 10:34:27 -0700 X-Google-Sender-Auth: OMspfvdUGPz9xbM6tKlJViiYjVY Message-ID: Subject: Re: [PATCH] libssh2_channel_request_auth_agent To: libssh2 development X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2HHYqBV027444 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2HHYuT6027521 Peter, On Sat, Mar 17, 2012 at 10:31 AM, Peter Stuge wrote: > Mitchell Hashimoto wrote: >> +int >> +libssh2_channel_request_auth_agent(LIBSSH2_CHANNEL *channel); >> + >> +.SH DESCRIPTION >> +Request that agent forwarding be enabled for this SSH session. This sends the >> +request over this specific channel, which causes the agent listener to be >> +started on the remote side upon success. This agent listener will then run >> +for the duration of the SSH session. >> + >> +\fIchannel\fP - Previously opened channel instance such as returned by >> +.BR libssh2_channel_open_ex(3) > > This doesn't make any sense to me. Model like the existing API which > create a special purpose channel, and reuse their infrastructure, > specifically libssh2_channel_process_startup(). See libssh2.h about > libssh2_channel_subsystem. > Thanks I'll take a look at that. > >> +++ b/example/ssh2_agent_forwarding.c >> @@ -0,0 +1,331 @@ > .. >> +int main(int argc, char *argv[]) >> +{ >> +    const char *hostname = "127.0.0.1"; >> +    const char *commandline = "uptime"; > > Suggest commandline "ssh-add -l" which will actually show the agent > forwarding being used. > > >> +    /* tell libssh2 we want it all done non-blocking */ >> +    libssh2_session_set_blocking(session, 0); > > Move this call to much later.. > > >> +    while ((rc = libssh2_session_handshake(session, sock)) == >> +           LIBSSH2_ERROR_EAGAIN); > .. >> +        while ((rc = libssh2_userauth_password(session, username, password)) == >> +               LIBSSH2_ERROR_EAGAIN); > .. >> +        while ((rc = libssh2_userauth_publickey_fromfile(session, username, >> +                                                         "/home/user/" >> +                                                         ".ssh/id_rsa.pub", >> +                                                         "/home/user/" >> +                                                         ".ssh/id_rsa", >> +                                                         password)) == >> +               LIBSSH2_ERROR_EAGAIN); > .. >> +    while( (channel = libssh2_channel_open_session(session)) == NULL && >> +           libssh2_session_last_error(session,NULL,NULL,0) == >> +           LIBSSH2_ERROR_EAGAIN ) >> +    { >> +        waitsocket(sock, session); >> +    } > .. >> +    while( (rc = libssh2_channel_request_auth_agent(channel)) == >> +           LIBSSH2_ERROR_EAGAIN ) >> +    { >> +        waitsocket(sock, session); >> +    } > .. >> +    while( (rc = libssh2_channel_exec(channel, commandline)) == >> +           LIBSSH2_ERROR_EAGAIN ) >> +    { >> +        waitsocket(sock, session); >> +    } > .. > > So that you do not need these very ugly loops! > > >> +    for( ;; ) >> +    { >> +        /* loop until we block */ >> +        int rc; >> +        do >> +        { >> +            char buffer[0x4000]; >> +            rc = libssh2_channel_read( channel, buffer, sizeof(buffer) ); >> +            if( rc > 0 ) >> +            { >> +                int i; >> +                bytecount += rc; >> +                fprintf(stderr, "We read:\n"); >> +                for( i=0; i < rc; ++i ) >> +                    fputc( buffer[i], stderr); >> +                fprintf(stderr, "\n"); >> +            } >> +            else { >> +                if( rc != LIBSSH2_ERROR_EAGAIN ) >> +                    /* no need to output this for the EAGAIN case */ >> +                    fprintf(stderr, "libssh2_channel_read returned %d\n", rc); >> +            } >> +        } >> +        while( rc > 0 ); >> + >> +        /* this is due to blocking that would occur otherwise so we loop on >> +           this condition */ >> +        if( rc == LIBSSH2_ERROR_EAGAIN ) >> +        { >> +            waitsocket(sock, session); >> +        } >> +        else >> +            break; >> +    } > > In fact, there is no reason at all to set non-blocking in this > example. It makes the code very ugly and is completely unneccessary. > > >> +    while( (rc = libssh2_channel_close(channel)) == LIBSSH2_ERROR_EAGAIN ) >> +        waitsocket(sock, session); > > Another ugly loop. Please get rid of all of them. Sorry, I really just copied the ssh2_exec.c example, which has all these same problems. I'll fix man and perhaps in the future I'll send another patch to fix up ssh2_exec as well. I'll address the things you pointed out. Thanks! Mitchell > > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 18:44:48 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HHiikX001104; Sat, 17 Mar 2012 18:44:48 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2HHigqS001085 for ; Sat, 17 Mar 2012 18:44:42 +0100 Received: (qmail 21544 invoked by uid 501); 17 Mar 2012 17:44:44 -0000 Message-ID: <20120317174444.21543.qmail@stuge.se> Date: Sat, 17 Mar 2012 18:44:44 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] libssh2_channel_request_auth_agent Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> <20120317173127.20564.qmail@stuge.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Mitchell Hashimoto wrote: > I really just copied the ssh2_exec.c example, which has all these > same problems. I'll fix man Not only the man page, look at how the existing API works, and make the new one for agent forwarding channels work the same. > and perhaps in the future I'll send another patch to fix up > ssh2_exec as well. That would be awesome! Meanwhile, suggest looking at other examples for inspiration. tcpip-forward.c is fairly straight-forward, for example. > I'll address the things you pointed out. Great! Thanks! //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 20:07:53 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HJ7Y1S027919; Sat, 17 Mar 2012 20:07:50 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HJ7U6X027851 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 17 Mar 2012 20:07:32 +0100 Received: by iahk25 with SMTP id k25so8595850iah.41 for ; Sat, 17 Mar 2012 12:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=krbbNzExdIp5k+R8svZP9mGLOzrmDXXVV9XfLf9gCcY=; b=I3RCX0TFHbfk/B2rGih+vkX1QtU94m0XeqG5JAGm6D6+X2Hvte1nBKn5k9OXTwrTuC tssqi2nMO+AK6Z1Kq2D/Q38UvZoCnZgSSi5TT6NoBO02hMp3N+mdviggogx6GoQdz02+ bpmZfFY2IpMQjPmM+qcyexz8iI/9wfRrDGfqxf95Jz0kS/AVpdBTpZc9nxlUVYQNu0cf 9EXlKpwCIYqJbFfKOLXOhtWqibsozlgSmb5s4fZZqvxLowu0keFAAkMTBfrLsFjYykmJ qu4Uc22FNbxBlzvzInB3pB4Oms7/2qJ4ii1NrwIwhKer3DK7NjRcxMchJveVbJPcOjDI wh7g== Received: by 10.50.207.5 with SMTP id ls5mr2378808igc.51.1332011247172; Sat, 17 Mar 2012 12:07:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Sat, 17 Mar 2012 12:07:06 -0700 (PDT) In-Reply-To: <20120317174444.21543.qmail@stuge.se> References: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> <20120317173127.20564.qmail@stuge.se> <20120317174444.21543.qmail@stuge.se> From: Mitchell Hashimoto Date: Sat, 17 Mar 2012 12:07:06 -0700 X-Google-Sender-Auth: D9Q7cGgn50kLLMnOaUfAuw7oj-E Message-ID: Subject: Re: [PATCH] libssh2_channel_request_auth_agent To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Peter, On Sat, Mar 17, 2012 at 10:44 AM, Peter Stuge wrote: > Mitchell Hashimoto wrote: >> I really just copied the ssh2_exec.c example, which has all these >> same problems. I'll fix man > > Not only the man page, look at how the existing API works, and make > the new one for agent forwarding channels work the same. Hm, I took a look at libssh2_channel_process_startup and I'm not quite sure I see the difference in what I'm doing vs what it is doing? What was the problem you saw? > > >> and perhaps in the future I'll send another patch to fix up >> ssh2_exec as well. > > That would be awesome! Meanwhile, suggest looking at other examples > for inspiration. tcpip-forward.c is fairly straight-forward, for > example. Thanks, will do. > > >> I'll address the things you pointed out. > > Great! Thanks! > > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 20:13:36 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HJDXGh031419; Sat, 17 Mar 2012 20:13:36 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2HJDW5k031408 for ; Sat, 17 Mar 2012 20:13:32 +0100 Received: (qmail 27983 invoked by uid 501); 17 Mar 2012 19:13:33 -0000 Message-ID: <20120317191333.27982.qmail@stuge.se> Date: Sat, 17 Mar 2012 20:13:33 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: [PATCH] libssh2_channel_request_auth_agent Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> <20120317173127.20564.qmail@stuge.se> <20120317174444.21543.qmail@stuge.se> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Mitchell Hashimoto wrote: > > Not only the man page, look at how the existing API works, and make > > the new one for agent forwarding channels work the same. > > Hm, I took a look at libssh2_channel_process_startup and I'm not quite > sure I see the difference in what I'm doing vs what it is doing? What > was the problem you saw? There is no way you can reuse the existing code? //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 20:50:33 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HJoPCs028197; Sat, 17 Mar 2012 20:50:32 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HJoMrg028150 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 17 Mar 2012 20:50:24 +0100 Received: by iahk25 with SMTP id k25so8651467iah.41 for ; Sat, 17 Mar 2012 12:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=wvMnFrIFNrQz5brNc5gxX1WZezlEAR9cdxz6Ba/z8d8=; b=MUWLNStY9V3Tdee1AO+pBrfD8cTmHyIQrLdPoZ8cP1rxxCu2dug55P46aCPwwIeJo/ LLMTrVNDc15ddLeYXnHoOY1jhT2UdrbFUzA+mBPPByU7I6AK+C6iyMwlbjHzNKI7yVr/ yAqsOa7hsU4wMLRC5w/rpeuCF8JUUxUd+8prFqnxsEqMI+O+nBKFYrmKBatzwXGQWl98 Se7xw3bkyJuOfqokGOJwAINXtrFbFIFzIliHReMxmN5/VNYa4i2rD51iGOpCHH9CQ6t+ Vq5Mm9WWRrHncoz7cFDulZ77NAEGzMz5SOoZfxA9PzyPxK5Fly/cWty1Fhx+3UeOozop w2Tg== Received: by 10.42.142.136 with SMTP id s8mr3919947icu.36.1332013817223; Sat, 17 Mar 2012 12:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.96.6 with HTTP; Sat, 17 Mar 2012 12:49:56 -0700 (PDT) In-Reply-To: <20120317191333.27982.qmail@stuge.se> References: <1332002997-73770-1-git-send-email-mitchell.hashimoto@gmail.com> <20120317173127.20564.qmail@stuge.se> <20120317174444.21543.qmail@stuge.se> <20120317191333.27982.qmail@stuge.se> From: Mitchell Hashimoto Date: Sat, 17 Mar 2012 12:49:56 -0700 X-Google-Sender-Auth: h0-xTtAGGuyrvjoQKJQPXqNqrHg Message-ID: Subject: Re: [PATCH] libssh2_channel_request_auth_agent To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Peter, On Sat, Mar 17, 2012 at 12:13 PM, Peter Stuge wrote: > Mitchell Hashimoto wrote: >> > Not only the man page, look at how the existing API works, and make >> > the new one for agent forwarding channels work the same. >> >> Hm, I took a look at libssh2_channel_process_startup and I'm not quite >> sure I see the difference in what I'm doing vs what it is doing? What >> was the problem you saw? > > There is no way you can reuse the existing code? Unless I'm missing something then no, it looks different enough that I can't. I based most of my code from channel_request_pty since that is a very similar call (but again, too different to share code). If this isn't reusable, and besides the example code, are there any issues you can see with the patch? Would it be possible to get this patch merged and I can submit another patch to clean up the examples? Best, Mitchell > > > //Peter > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 22:49:40 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HLnIhc018791; Sat, 17 Mar 2012 22:49:34 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HLnGqU018780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Mar 2012 22:49:16 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2HLnGO5018776 for ; Sat, 17 Mar 2012 22:49:16 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sat, 17 Mar 2012 22:49:16 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: OpenSSL AES-CTR not working? In-Reply-To: <20120317141343.19c56d80@zion.city-fan.org> Message-ID: References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1129329158-1435953880-1332020956=:21870" X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-1435953880-1332020956=:21870 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 17 Mar 2012, Paul Howarth wrote: > I'm able to work around this for now by disabling the AES-CTR detection in > configure, by doing: > > export ac_cv_func_EVP_aes_128_ctr=no Thanks for this! How about the attached patch, is that enough to make it build and work without that work-around you found? -- / daniel.haxx.se --1129329158-1435953880-1332020956=:21870 Content-Type: TEXT/x-diff; name=0001-aes-the-init-function-fails-when-OpenSSL-has-AES-sup.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=0001-aes-the-init-function-fails-when-OpenSSL-has-AES-sup.patch RnJvbSBmNzcwYTNhYzFjZjc3OGRhMDEwYjI4MmM5NGM5ZThiNDVjMzVmYWMy IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogRGFuaWVsIFN0ZW5i ZXJnIDxkYW5pZWxAaGF4eC5zZT4NCkRhdGU6IFNhdCwgMTcgTWFyIDIwMTIg MjI6NDU6NTYgKzAxMDANClN1YmplY3Q6IFtQQVRDSF0gYWVzOiB0aGUgaW5p dCBmdW5jdGlvbiBmYWlscyB3aGVuIE9wZW5TU0wgaGFzIEFFUyBzdXBwb3J0 DQoNClRoZSBpbnRlcm5hbCBpbml0IGZ1bmN0aW9uIG9ubHkgd29ya2VkIGZp bmUgd2hlbiB0aGUgY29uZmlndXJlIHNjcmlwdA0KZGlkbid0IGRldGVjdCB0 aGUgT3BlblNTTCBBRVNfQ1RSIGZ1bmN0aW9uLg0KDQpCdWc6IGh0dHA6Ly93 d3cubGlic3NoMi5vcmcvbWFpbC9saWJzc2gyLWRldmVsLWFyY2hpdmUtMjAx Mi0wMy8wMTExLnNodG1sDQpSZXBvcnRlZCBieTogUGF1bCBIb3dhcnRoDQot LS0NCiBzcmMvb3BlbnNzbC5jIHwgICAgMiArKw0KIDEgZmlsZXMgY2hhbmdl ZCwgMiBpbnNlcnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0t Z2l0IGEvc3JjL29wZW5zc2wuYyBiL3NyYy9vcGVuc3NsLmMNCmluZGV4IDQw ODE4YzAuLjkyMjA4NjggMTAwNjQ0DQotLS0gYS9zcmMvb3BlbnNzbC5jDQor KysgYi9zcmMvb3BlbnNzbC5jDQpAQCAtMzYyLDYgKzM2Miw4IEBAIHZvaWQg X2xpYnNzaDJfaW5pdF9hZXNfY3RyKHZvaWQpDQogICAgIF9saWJzc2gyX0VW UF9hZXNfMjU2X2N0cigpOw0KIH0NCiANCisjZWxzZQ0KK3ZvaWQgX2xpYnNz aDJfaW5pdF9hZXNfY3RyKHZvaWQpIHt9DQogI2VuZGlmIC8qIExJQlNTSDJf QUVTX0NUUiAqLw0KIA0KIC8qIFRPRE86IE9wdGlvbmFsbHkgY2FsbCBhIHBh c3NwaHJhc2UgY2FsbGJhY2sgc3BlY2lmaWVkIGJ5IHRoZQ0KLS0gDQoxLjcu OS4xDQoNCg== --1129329158-1435953880-1332020956=:21870 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --1129329158-1435953880-1332020956=:21870-- From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 22:59:44 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HLxcPG025488; Sat, 17 Mar 2012 22:59:43 +0100 Received: from goalkeeper.city-fan.org (pghmcfc-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:d97::2]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HLxaFX025455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Mar 2012 22:59:37 +0100 Received: from zion.city-fan.org (zion.city-fan.org [IPv6:2001:470:9279::2]) (authenticated bits=0) by goalkeeper.city-fan.org (8.14.5/8.14.5) with ESMTP id q2HLxapB023472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 17 Mar 2012 21:59:36 GMT Date: Sat, 17 Mar 2012 21:59:35 +0000 From: Paul Howarth To: libssh2-devel@cool.haxx.se Subject: Re: OpenSSL AES-CTR not working? Message-ID: <20120317215935.5eb35dcc@zion.city-fan.org> In-Reply-To: References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sat, 17 Mar 2012 22:49:16 +0100 (CET) Daniel Stenberg wrote: > On Sat, 17 Mar 2012, Paul Howarth wrote: > > > I'm able to work around this for now by disabling the AES-CTR > > detection in configure, by doing: > > > > export ac_cv_func_EVP_aes_128_ctr=no > > Thanks for this! How about the attached patch, is that enough to make > it build and work without that work-around you found? No, same symptoms as not calling the function. debug1: kex: client->server aes128-ctr hmac-sha1 none^M debug2: mac_setup: found hmac-sha1^M debug1: kex: server->client aes128-ctr hmac-sha1 none^M debug2: dh_gen_key: priv key bits set: 163/320^M debug2: bits set: 1041/2048^M debug1: expecting SSH2_MSG_KEXDH_INIT^M debug2: bits set: 1034/2048^M debug2: kex_derive_keys^M debug2: set_newkeys: mode 1^M debug1: SSH2_MSG_NEWKEYS sent^M debug1: expecting SSH2_MSG_NEWKEYS^M debug2: set_newkeys: mode 0^M debug1: SSH2_MSG_NEWKEYS received^M debug1: KEX done^M Corrupted MAC on input.^M Disconnecting: Packet corrupt^M debug1: do_cleanup^M getsockname failed: Bad file descriptor^M Failure establishing SSH session FAIL: ssh2.sh Paul. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 23:20:55 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HMKnK3007080; Sat, 17 Mar 2012 23:20:55 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HMKm8s007038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 17 Mar 2012 23:20:48 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2HMKlTG007035 for ; Sat, 17 Mar 2012 23:20:48 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sat, 17 Mar 2012 23:20:47 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: OpenSSL AES-CTR not working? In-Reply-To: <20120317215935.5eb35dcc@zion.city-fan.org> Message-ID: References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> <20120317215935.5eb35dcc@zion.city-fan.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1129329158-516749533-1332022848=:21870" X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-516749533-1332022848=:21870 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 17 Mar 2012, Paul Howarth wrote: >> Thanks for this! How about the attached patch, is that enough to make >> it build and work without that work-around you found? > > No, same symptoms as not calling the function. I simply cannot find any public docs for this strangeness from openssl (and it annoys me a lot). I guess we can instead switch to always use our implementation if AES_CTR is desired. See my second take on a patch (ditch the previous). -- / daniel.haxx.se --1129329158-516749533-1332022848=:21870 Content-Type: TEXT/x-diff; name=0001-aes-the-init-function-fails-when-OpenSSL-has-AES-sup.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=0001-aes-the-init-function-fails-when-OpenSSL-has-AES-sup.patch RnJvbSA3NjVhZDNiNWEwYWJmYjlmZjI4MzFhYTZjMDRiMzJiYTcxM2I0Y2Yz IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogRGFuaWVsIFN0ZW5i ZXJnIDxkYW5pZWxAaGF4eC5zZT4NCkRhdGU6IFNhdCwgMTcgTWFyIDIwMTIg MjI6NDU6NTYgKzAxMDANClN1YmplY3Q6IFtQQVRDSF0gYWVzOiB0aGUgaW5p dCBmdW5jdGlvbiBmYWlscyB3aGVuIE9wZW5TU0wgaGFzIEFFUyBzdXBwb3J0 DQoNClRoZSBpbnRlcm5hbCBpbml0IGZ1bmN0aW9uIG9ubHkgd29ya2VkIGZp bmUgd2hlbiB0aGUgY29uZmlndXJlIHNjcmlwdA0KZGlkbid0IGRldGVjdCB0 aGUgT3BlblNTTCBBRVNfQ1RSIGZ1bmN0aW9uIQ0KDQpCdWc6IGh0dHA6Ly93 d3cubGlic3NoMi5vcmcvbWFpbC9saWJzc2gyLWRldmVsLWFyY2hpdmUtMjAx Mi0wMy8wMTExLnNodG1sDQpSZXBvcnRlZCBieTogUGF1bCBIb3dhcnRoDQot LS0NCiBzcmMvb3BlbnNzbC5jIHwgICAgNCArKystDQogMSBmaWxlcyBjaGFu Z2VkLCAzIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pDQoNCmRpZmYg LS1naXQgYS9zcmMvb3BlbnNzbC5jIGIvc3JjL29wZW5zc2wuYw0KaW5kZXgg NDA4MThjMC4uNDgxOTgyYyAxMDA2NDQNCi0tLSBhL3NyYy9vcGVuc3NsLmMN CisrKyBiL3NyYy9vcGVuc3NsLmMNCkBAIC0yMDEsNyArMjAxLDcgQEAgX2xp YnNzaDJfY2lwaGVyX2NyeXB0KF9saWJzc2gyX2NpcGhlcl9jdHggKiBjdHgs DQogICAgIHJldHVybiByZXQgPT0gMSA/IDAgOiAxOw0KIH0NCiANCi0jaWYg TElCU1NIMl9BRVNfQ1RSICYmICFkZWZpbmVkKEhBVkVfRVZQX0FFU18xMjhf Q1RSKQ0KKyNpZiBMSUJTU0gyX0FFU19DVFINCiANCiAjaW5jbHVkZSA8b3Bl bnNzbC9hZXMuaD4NCiAjaW5jbHVkZSA8b3BlbnNzbC9ldnAuaD4NCkBAIC0z NjIsNiArMzYyLDggQEAgdm9pZCBfbGlic3NoMl9pbml0X2Flc19jdHIodm9p ZCkNCiAgICAgX2xpYnNzaDJfRVZQX2Flc18yNTZfY3RyKCk7DQogfQ0KIA0K KyNlbHNlDQordm9pZCBfbGlic3NoMl9pbml0X2Flc19jdHIodm9pZCkge30N CiAjZW5kaWYgLyogTElCU1NIMl9BRVNfQ1RSICovDQogDQogLyogVE9ETzog T3B0aW9uYWxseSBjYWxsIGEgcGFzc3BocmFzZSBjYWxsYmFjayBzcGVjaWZp ZWQgYnkgdGhlDQotLSANCjEuNy45LjENCg0K --1129329158-516749533-1332022848=:21870 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --1129329158-516749533-1332022848=:21870-- From libssh2-devel-bounces@cool.haxx.se Sat Mar 17 23:30:51 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2HMUmp2015967; Sat, 17 Mar 2012 23:30:51 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2HMUk76015951 for ; Sat, 17 Mar 2012 23:30:46 +0100 Received: (qmail 9847 invoked by uid 501); 17 Mar 2012 22:30:48 -0000 Message-ID: <20120317223048.9846.qmail@stuge.se> Date: Sat, 17 Mar 2012 23:30:48 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: OpenSSL AES-CTR not working? Mail-Followup-To: libssh2-devel@cool.haxx.se References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> <20120317215935.5eb35dcc@zion.city-fan.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Daniel Stenberg wrote: > -#if LIBSSH2_AES_CTR && !defined(HAVE_EVP_AES_128_CTR) > +#if LIBSSH2_AES_CTR .. > +#else > +void _libssh2_init_aes_ctr(void) {} > #endif /* LIBSSH2_AES_CTR */ Is the empty function needed there? //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sun Mar 18 01:49:45 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2I0nOHh004184; Sun, 18 Mar 2012 01:49:41 +0100 Received: from goalkeeper.city-fan.org (pghmcfc-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:d97::2]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2I0nL2u004166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 18 Mar 2012 01:49:22 +0100 Received: from zion.city-fan.org (zion.city-fan.org [IPv6:2001:470:9279::2]) (authenticated bits=0) by goalkeeper.city-fan.org (8.14.5/8.14.5) with ESMTP id q2I0nLDL031504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 18 Mar 2012 00:49:21 GMT Date: Sun, 18 Mar 2012 00:49:20 +0000 From: Paul Howarth To: libssh2-devel@cool.haxx.se Subject: Re: OpenSSL AES-CTR not working? Message-ID: <20120318004920.0fdf9314@zion.city-fan.org> In-Reply-To: References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> <20120317215935.5eb35dcc@zion.city-fan.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sat, 17 Mar 2012 23:20:47 +0100 (CET) Daniel Stenberg wrote: > On Sat, 17 Mar 2012, Paul Howarth wrote: > > >> Thanks for this! How about the attached patch, is that enough to > >> make it build and work without that work-around you found? > > > > No, same symptoms as not calling the function. > > I simply cannot find any public docs for this strangeness from > openssl (and it annoys me a lot). I guess we can instead switch to > always use our implementation if AES_CTR is desired. See my second > take on a patch (ditch the previous). That didn't work either. I think you'll need to kill the HAVE_EVP_AES_128_CTR bit in openssl.h too. Paul. _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sun Mar 18 11:21:09 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2IAKkge015751; Sun, 18 Mar 2012 11:21:04 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2IAKi1q015668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 18 Mar 2012 11:20:44 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2IAKiSj015663 for ; Sun, 18 Mar 2012 11:20:44 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 18 Mar 2012 11:20:44 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: OpenSSL AES-CTR not working? In-Reply-To: <20120318004920.0fdf9314@zion.city-fan.org> Message-ID: References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> <20120317215935.5eb35dcc@zion.city-fan.org> <20120318004920.0fdf9314@zion.city-fan.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sun, 18 Mar 2012, Paul Howarth wrote: >> I simply cannot find any public docs for this strangeness from openssl (and >> it annoys me a lot). I guess we can instead switch to always use our >> implementation if AES_CTR is desired. See my second take on a patch (ditch >> the previous). > > That didn't work either. I think you'll need to kill the > HAVE_EVP_AES_128_CTR bit in openssl.h too. Care to suggest a patch you think would work? -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sun Mar 18 13:57:54 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2ICvdvO020019; Sun, 18 Mar 2012 13:57:52 +0100 Received: from goalkeeper.city-fan.org (pghmcfc-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:d97::2]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2ICvcVC020002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 18 Mar 2012 13:57:38 +0100 Received: from zion.city-fan.org (zion.city-fan.org [IPv6:2001:470:9279::2]) (authenticated bits=0) by goalkeeper.city-fan.org (8.14.5/8.14.5) with ESMTP id q2ICvaAK032079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 18 Mar 2012 12:57:38 GMT Date: Sun, 18 Mar 2012 12:57:36 +0000 From: Paul Howarth To: libssh2-devel@cool.haxx.se Subject: Re: OpenSSL AES-CTR not working? Message-ID: <20120318125736.50a9b172@zion.city-fan.org> In-Reply-To: References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> <20120317215935.5eb35dcc@zion.city-fan.org> <20120318004920.0fdf9314@zion.city-fan.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/HN6kX9/ZrLIwvYgjjJ3eww7" X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --MP_/HN6kX9/ZrLIwvYgjjJ3eww7 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, 18 Mar 2012 11:20:44 +0100 (CET) Daniel Stenberg wrote: > On Sun, 18 Mar 2012, Paul Howarth wrote: > > >> I simply cannot find any public docs for this strangeness from > >> openssl (and it annoys me a lot). I guess we can instead switch to > >> always use our implementation if AES_CTR is desired. See my second > >> take on a patch (ditch the previous). > > > > That didn't work either. I think you'll need to kill the > > HAVE_EVP_AES_128_CTR bit in openssl.h too. > > Care to suggest a patch you think would work? This one works for me. Paul. --MP_/HN6kX9/ZrLIwvYgjjJ3eww7 Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=0001-aes-the-init-function-fails-when-OpenSSL-has-AES-sup.patch From 24577937c36b32472d4bfff449d5e173192eec05 Mon Sep 17 00:00:00 2001 From: Paul Howarth Date: Sun, 18 Mar 2012 12:07:27 +0000 Subject: [PATCH] aes: the init function fails when OpenSSL has AES support The internal init function only worked fine when the configure script didn't detect the OpenSSL AES_CTR function! Bug: http://www.libssh2.org/mail/libssh2-devel-archive-2012-03/0111.shtml Reported by: Paul Howarth --- src/openssl.c | 4 +++- src/openssl.h | 6 ------ 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/src/openssl.c b/src/openssl.c index 40818c0..481982c 100644 --- a/src/openssl.c +++ b/src/openssl.c @@ -201,7 +201,7 @@ _libssh2_cipher_crypt(_libssh2_cipher_ctx * ctx, return ret == 1 ? 0 : 1; } -#if LIBSSH2_AES_CTR && !defined(HAVE_EVP_AES_128_CTR) +#if LIBSSH2_AES_CTR #include #include @@ -362,6 +362,8 @@ void _libssh2_init_aes_ctr(void) _libssh2_EVP_aes_256_ctr(); } +#else +void _libssh2_init_aes_ctr(void) {} #endif /* LIBSSH2_AES_CTR */ /* TODO: Optionally call a passphrase callback specified by the diff --git a/src/openssl.h b/src/openssl.h index a196184..6d2aeed 100644 --- a/src/openssl.h +++ b/src/openssl.h @@ -148,15 +148,9 @@ void libssh2_md5(const unsigned char *message, unsigned long len, unsigned char #define _libssh2_cipher_aes256 EVP_aes_256_cbc #define _libssh2_cipher_aes192 EVP_aes_192_cbc #define _libssh2_cipher_aes128 EVP_aes_128_cbc -#ifdef HAVE_EVP_AES_128_CTR -#define _libssh2_cipher_aes128ctr EVP_aes_128_ctr -#define _libssh2_cipher_aes192ctr EVP_aes_192_ctr -#define _libssh2_cipher_aes256ctr EVP_aes_256_ctr -#else #define _libssh2_cipher_aes128ctr _libssh2_EVP_aes_128_ctr #define _libssh2_cipher_aes192ctr _libssh2_EVP_aes_192_ctr #define _libssh2_cipher_aes256ctr _libssh2_EVP_aes_256_ctr -#endif #define _libssh2_cipher_blowfish EVP_bf_cbc #define _libssh2_cipher_arcfour EVP_rc4 #define _libssh2_cipher_cast5 EVP_cast5_cbc -- 1.7.7.6 --MP_/HN6kX9/ZrLIwvYgjjJ3eww7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --MP_/HN6kX9/ZrLIwvYgjjJ3eww7-- From libssh2-devel-bounces@cool.haxx.se Sun Mar 18 15:28:22 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2IES4fI032065; Sun, 18 Mar 2012 15:28:19 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2IES2uQ032047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 18 Mar 2012 15:28:02 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2IES2I9032041 for ; Sun, 18 Mar 2012 15:28:02 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 18 Mar 2012 15:28:02 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: OpenSSL AES-CTR not working? In-Reply-To: <20120318125736.50a9b172@zion.city-fan.org> Message-ID: References: <20120317140917.3f9ad134@zion.city-fan.org> <20120317141343.19c56d80@zion.city-fan.org> <20120317215935.5eb35dcc@zion.city-fan.org> <20120318004920.0fdf9314@zion.city-fan.org> <20120318125736.50a9b172@zion.city-fan.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Sun, 18 Mar 2012, Paul Howarth wrote: >> Care to suggest a patch you think would work? > > This one works for me. Thanks, merged and pushed! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 19:28:41 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JISGOR030265; Mon, 19 Mar 2012 19:28:36 +0100 Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2JISE1F030214 for ; Mon, 19 Mar 2012 19:28:14 +0100 Received: from [98.139.91.67] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2012 18:28:09 -0000 Received: from [98.139.44.87] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2012 18:28:09 -0000 Received: from [127.0.0.1] by omp1024.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2012 18:28:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 875790.86040.bm@omp1024.access.mail.sp2.yahoo.com Received: (qmail 65020 invoked by uid 60001); 19 Mar 2012 18:28:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332181689; bh=LY+GmUBT85PvzpdbtO0xwnoyyGvHhxBUsNeVJ9wcJxk=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=MGR7RzLJSPNJ+apPSkxXlnlTG5kJDKaGY3BbN6NyOItDcDyjpGLfU3kNQKzz/zkFfoHra+HTAOnujQ/Zn2oJY1AmwItAMbmh6+1/wIw9Hacca6MoqvreYvpim1fykpz8ljfDhpSTR9YMWAs3OwWCS31RbdkZAQ+wn8aFHtFK+Qg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Y0wBPgvroRPpNjEEHgUTNDgdeou8Kf3qEPltjzC0Qh8jxxgVhQ/OI0B2SRIlN3/qQSQVapNsPRgReWJ7ynqWYh44DkydDcoLBMrx3MlEr/G4zMGvxCkiH8wAFN0c/Kpc723gwhhXR1KcCt7yz4hGET+Fo1418d5sc+DnSa2eH3g=; X-YMail-OSG: AwtnvCkVM1lwiMMLB0ZXbUgVUG13lc.xDV9Hsx0JKH7ftvQ M_CZ8xBGIYviTSkFf3Xiy3aGRrjlQ8on07dAn4uRvpUFZ2touHb5IXBwzpcp ZtgMEo.ey.tBkV1y79Xn7vrtmsScTAycvfFfyFArugw4ysBLndW.9sC0wouM kDfV1KRjiI5mVTHGBhYU3vyjDxYXft5bCt2D5OaZs9mk.bulu7.X64w7xb_U n4XQHNil5jwjIFXKHorIaJmfOLvIq0PuRIwKs6v9jNlARDVxQrN50tTzVE8u BAQMVUQuJ6YYoVHpDrhE7GCTnwgGS64XdOaGDlx2EzcK4ke0KCmBlSocMQJ8 z.4VKWXuXCONwqlxdL7h4xOsKXoCMZuyGEFfpDAge.HLZaFPJHiXm0ONXYA_ 5LYdSN04SditwZSeg6J56xRn6rBs2unkZbD3z1hlu2bDvWEymfWgsN5o3657 Tp1k3LiTrsV2ultoipDlPGPHS.PPOFbGTMzDgIGz1hKcycPL71jYo3wJJJEc LF_6ZQNMMNgo7VhTNlsp1M6un9ge6UQ-- Received: from [24.43.161.82] by web180416.mail.gq1.yahoo.com via HTTP; Mon, 19 Mar 2012 11:28:09 PDT X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.116.338427 Message-ID: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> Date: Mon, 19 Mar 2012 11:28:09 -0700 (PDT) From: Armen Babakhanian Subject: SCP Transfer example Hangs To: libssh2-devel@cool.haxx.se MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1713224950==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============1713224950== Content-Type: multipart/alternative; boundary="-1952832855-315651284-1332181689=:60413" ---1952832855-315651284-1332181689=:60413 Content-Type: text/plain; charset=us-ascii I'm using VC++ 2008. I've ran this example from the libssh2 website (http://www.libssh2.org/examples/scp.html) a few time and everytime it's hangs at the very last few bytes it needs to receive. I ran a debugger to see where the problem was occurring and it happened when this line: if((fileinfo.st_size -got) < amount) { amount = fileinfo.st_size -got; }got executed before t_rc = libssh2_channel_read(t_channel, mem, amount); which is where the app hangs. When I remove the amount setter, then it works fine, however from time to time the data received is not correct. meaning the md5sum value is not the same as the origin. ---1952832855-315651284-1332181689=:60413 Content-Type: text/html; charset=us-ascii
I'm using VC++ 2008.

I've ran this example from the libssh2 website (http://www.libssh2.org/examples/scp.html) a few time and everytime it's hangs at the very last few bytes it needs to receive.  I ran a debugger to see where the problem was occurring and it happened when this line:
        if((fileinfo.st_size -got) < amount) {
            amount = fileinfo.st_size -got;
        }
got executed before

        t_rc = libssh2_channel_read(t_channel, mem, amount);

which is where the app hangs.

When I remove the amount setter, then it works fine, however from time to time the data received is not correct. meaning the md5sum value is not the same as the origin.
---1952832855-315651284-1332181689=:60413-- --===============1713224950== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============1713224950==-- From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 19:35:38 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JIZZEK003667; Mon, 19 Mar 2012 19:35:38 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2JIZXIr003657 for ; Mon, 19 Mar 2012 19:35:33 +0100 Received: (qmail 27234 invoked by uid 501); 19 Mar 2012 18:35:34 -0000 Message-ID: <20120319183534.27233.qmail@stuge.se> Date: Mon, 19 Mar 2012 19:35:34 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: SCP Transfer example Hangs Mail-Followup-To: libssh2-devel@cool.haxx.se References: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Armen Babakhanian wrote: > (http://www.libssh2.org/examples/scp.html) a few time and everytime it's hangs > at the very last few bytes it needs to receive. I ran a debugger No, please build libssh2 with full debug logging, and call libssh2_trace(session, ~0); in the program. This should result in lots of useful output. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 19:40:51 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JIelsl008445; Mon, 19 Mar 2012 19:40:50 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JIejx6008415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Mar 2012 19:40:45 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2JIejLs008404 for ; Mon, 19 Mar 2012 19:40:45 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 19 Mar 2012 19:40:45 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: SCP Transfer example Hangs In-Reply-To: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> Message-ID: References: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Mon, 19 Mar 2012, Armen Babakhanian wrote: > I've ran this example from the libssh2 website > (http://www.libssh2.org/examples/scp.html) a few time and everytime it's > hangs at the very last few bytes it needs to receive. In addition to Peter's request, can you also tell us which version you're using and if it isn't the latest git version, have you tried that? -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 20:11:39 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JJBVh9019105; Mon, 19 Mar 2012 20:11:37 +0100 Received: from nm9-vm1.bullet.mail.sp2.yahoo.com (nm9-vm1.bullet.mail.sp2.yahoo.com [98.139.91.197]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with SMTP id q2JJBSiY018906 for ; Mon, 19 Mar 2012 20:11:29 +0100 Received: from [98.139.91.69] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2012 19:11:24 -0000 Received: from [98.139.44.79] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 19 Mar 2012 19:10:24 -0000 Received: from [127.0.0.1] by omp1016.access.mail.sp2.yahoo.com with NNFMP; 19 Mar 2012 19:10:24 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 36562.78856.bm@omp1016.access.mail.sp2.yahoo.com Received: (qmail 54702 invoked by uid 60001); 19 Mar 2012 19:10:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332184223; bh=o4j4asVZJRQRKOVbKyzmMBt+9yXHokoevuwt00+sREw=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fmLYStzMWVbiBdePGIvFoY5jZCiG1qthFkin5oYBwNl0COaDaCcrtz2OaZds5WT9BRE8olAMI6EGHqetnk8LkrsB6q5vdGVkegOtsySr4Fk8PWkZDKtcc1vnU9ihHu1NP5AZ7LcgV1w/u0g6cF/uki898rhAX7lwtiDEQYjdRg4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LeaTPhKe2rlTfdo17TfSGSwBMlEWJA/sk0UELmM8Nm1Y7l222A8beKKWGkc7UBH11fLEO+BYp6fJ5qJ+crz4YTndR656EytpLT0JHTwnKSDFn09TUjXxsbiTlmE7d/M1LQ0r5563G2MBl7BK53q78B5DDwPksxM1weeXNMHG6Bs=; X-YMail-OSG: UOt8JIcVM1m_qiUBtktRJiAhwWeMvQz3TeJKcN95aTFfzKG J9fpFRSUIJc5hYlQ6BpvSfZFe1ddK_DPoZhma4SfN9UxkY2DkcHm8I4_H0nB YYPl0kTDVMAkf6S2BQirWsU4B8aUURv6F7MXDPQTuHk1JEnok6d6z2rouRQt J2x7FRkV1FaDP0E895pIdofuKnL5SB8Dt5FXMhGgsMq5S4swMCHkdLck_bGr TJ_.MoMIIom6DFEcLmYaDwKxTXy6cwD599OPCP8sVH03AFp9eWhMOGOXdQvq BPhmTfQ4AAtqlqr13zJrE1cTkUEpUrVXqwII648WaK9U_NuNr9TcaTbz4waT Fm.eRZFUDyqP02KoFqplMfjbaZBZo0jVujlUtVlutq1k4PG4_C3kca0mM_Ah r96nFkMPnkosPuLD0oNNbi6TGaw.QGeov61lo75TKOwx0aoeNq3M7xU4Ts_g nBRg8SwsAbTzqa.CAkjpTXSK9TGERFjqbqqLMTU2sU6yRiEeGp7r2t38Ej0a SM7rxMqs5Y304gxEWw4F3CwmaVejrbg-- Received: from [24.43.161.82] by web180405.mail.gq1.yahoo.com via HTTP; Mon, 19 Mar 2012 12:10:23 PDT X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.116.338427 References: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> Message-ID: <1332184223.54080.YahooMailRC@web180405.mail.gq1.yahoo.com> Date: Mon, 19 Mar 2012 12:10:23 -0700 (PDT) From: Armen Babakhanian Subject: Re: SCP Transfer example Hangs To: libssh2 development In-Reply-To: MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1940907190==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --===============1940907190== Content-Type: multipart/alternative; boundary="-983831124-656242783-1332184223=:54080" ---983831124-656242783-1332184223=:54080 Content-Type: text/plain; charset=us-ascii I am using libssh2-1.4.0-20120313.tar I'll do that certainly but I thought maybe someone else should run it and confirm that it actually hangs before I continue to do that. btw, I tried different libraries before I switched to yours, and so far it works great, except this little issue.Thanks for your effort. ________________________________ From: Daniel Stenberg To: libssh2 development Sent: Mon, March 19, 2012 11:40:45 AM Subject: Re: SCP Transfer example Hangs On Mon, 19 Mar 2012, Armen Babakhanian wrote: > I've ran this example from the libssh2 website >(http://www.libssh2.org/examples/scp.html) a few time and everytime it's hangs >at the very last few bytes it needs to receive. In addition to Peter's request, can you also tell us which version you're using and if it isn't the latest git version, have you tried that? -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel ---983831124-656242783-1332184223=:54080 Content-Type: text/html; charset=us-ascii
I am using libssh2-1.4.0-20120313.tar
I'll do that certainly but I thought maybe someone else should run it and confirm that it actually hangs before I continue to do that.

btw, I tried different libraries before I switched to yours, and so far it works great, except this little issue.Thanks for your effort.


From: Daniel Stenberg <daniel@haxx.se>
To: libssh2 development <libssh2-devel@cool.haxx.se>
Sent: Mon, March 19, 2012 11:40:45 AM
Subject: Re: SCP Transfer example Hangs

On Mon, 19 Mar 2012, Armen Babakhanian wrote:

> I've ran this example from the libssh2 website (http://www.libssh2.org/examples/scp.html) a few time and everytime it's hangs at the very last few bytes it needs to receive.

In addition to Peter's request, can you also tell us which version you're using and if it isn't the latest git version, have you tried that?

--
/ daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
---983831124-656242783-1332184223=:54080-- --===============1940907190== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --===============1940907190==-- From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 22:04:15 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JL3w9K017442; Mon, 19 Mar 2012 22:04:13 +0100 Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JL3tHB017324 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Mar 2012 22:03:56 +0100 Received: by iahk25 with SMTP id k25so12045574iah.41 for ; Mon, 19 Mar 2012 14:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zN1wVZmqCwguGM01oyopzhEQ8mhvHjntsLOcdTkZrqg=; b=Cx+6fjmHFBYLfiC7pdaQw+QtAryiAoX8zIagPPRN66Uu04VNBQham6nBYadAYbKHv6 BBb7uR1vxilxajvEZlQ7BCv3Qp9JcFcqf++lOqYL/TtN8UkvD3oj+ZEKp1GsV+B8K1nu 2Zpq9IJWtvs64aXv7apwT72Pa3jlmlZJDtDv+8Tph/nMN88lfVH5FhnFsXzZWU6WwP1f rH1R/2kOfWY4WJnY5hshKHSKfmAvPGD6Oc+rcrobXphVJnVHN2KEQ1UO8Hw8mnwMvpwV jjNEEyOeP6ZXL1tfMbLtt4J+o/dn0y40swtmQuJf6MalOz+RFHN7K+KRaZis1Io7z2lv p+3A== MIME-Version: 1.0 Received: by 10.50.46.167 with SMTP id w7mr7011755igm.73.1332191031348; Mon, 19 Mar 2012 14:03:51 -0700 (PDT) Received: by 10.42.180.131 with HTTP; Mon, 19 Mar 2012 14:03:51 -0700 (PDT) In-Reply-To: References: <1326996007-1220-1-git-send-email-joe.turpin@gmail.com> Date: Mon, 19 Mar 2012 17:03:51 -0400 Message-ID: Subject: Re: [PATCH] userauth: Allow authentication keys to be passed in memory From: Joe Turpin To: Daniel Stenberg X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2JL3tHB017324 Cc: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2JL3w9K017442 On Sat, Jan 21, 2012 at 5:23 PM, Daniel Stenberg wrote: > Hello, > > Thanks for the updated patch! This time I applied it, had a look and here > are my comments: > > - memcpy_s() is not a function that exists portably, don't use it. I also >  think you can skip checking memcpy()'s return code. > > - your new code produces lots of warnings and we're trying hard to not have >  warnings (some are still there but lets not add new ones). ./configure >  --enable-debug helps us see them. > > - also, where it is possible please keep the source lines shorter than 80 >  columns > > -- > >  / daniel.haxx.se Daniel, Sorry for the delay. Life and work getting in the way as usual. Patch email to follow shortly with fixes for the above. --Joe _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 22:19:22 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JLJJEl030360; Mon, 19 Mar 2012 22:19:22 +0100 Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JLJGIG030293 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Mar 2012 22:19:17 +0100 Received: by qcsg15 with SMTP id g15so1877434qcs.41 for ; Mon, 19 Mar 2012 14:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=wjBUPjRN0mFkCwA0zyzCNdywPx6C8PsndIBjOKkMRM0=; b=KQ/M4uY4CkuIF2k+ZpY5cnoj09Q6oDGiRbiUzITtUhGhlDfF+CfuqkDfCwi8Xk5sMg w0fPNXt1QNPyS6WUnqUja1LjR070/VX8v/yYWpitZnqK/qkv+X98eVlREMc5OQLBFpni ByWxb0eyr5eF8tXDifVHgy3fQuchH+pw85fx/Dy4819TcUS7y3YSjlG+/R7ubj2QXIWy +xCUYnNWiaZWT+JWHLBGZTJCLn7vRy/W9KScYtireZVWA9ZXPUwFBN7p8e6XzqX/DLa4 leG6W6w6isD0wcb+PJx3ZRcw0HhCAJpZnIPrMFCGVvmHmPgiRlriAhOCbzXs5sEt7ZOc xHyg== Received: by 10.229.135.208 with SMTP id o16mr5088091qct.120.1332191950797; Mon, 19 Mar 2012 14:19:10 -0700 (PDT) Received: from localhost.localdomain (41333086.cst.lightpath.net. [65.51.48.134]) by mx.google.com with ESMTPS id hr2sm25476378qab.8.2012.03.19.14.19.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 14:19:08 -0700 (PDT) From: Joe Turpin To: libssh2 development Subject: [PATCH] userauth: Allow authentication keys to be passed in memory Date: Mon, 19 Mar 2012 17:18:34 -0400 Message-Id: <1332191914-6949-1-git-send-email-joe.turpin@gmail.com> X-Mailer: git-send-email 1.7.5.4 In-Reply-To: References: Cc: Joe Turpin X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Add a new user authentication API function that allows the client to pass a buffer containting the contents of the authentication key files. --- docs/libssh2_userauth_publickey_frommemory.3 | 55 ++++++ include/libssh2.h | 10 + src/crypto.h | 19 ++ src/hostkey.c | 68 ++++++++ src/libssh2_priv.h | 4 + src/openssl.c | 120 ++++++++++++++ src/userauth.c | 228 ++++++++++++++++++++++++++ 7 files changed, 504 insertions(+), 0 deletions(-) create mode 100644 docs/libssh2_userauth_publickey_frommemory.3 diff --git a/docs/libssh2_userauth_publickey_frommemory.3 b/docs/libssh2_userauth_publickey_frommemory.3 new file mode 100644 index 0000000..b217332 --- /dev/null +++ b/docs/libssh2_userauth_publickey_frommemory.3 @@ -0,0 +1,55 @@ +.TH libssh2_userauth_publickey_frommemory 3 "18 Jan 2012" "libssh2 1.3" "libssh2 manual" +.SH NAME +libssh2_userauth_publickey_frommemory - authenticate a session with a public key, read from memory +.SH SYNOPSIS +#include + +.nf +int libssh2_userauth_publickey_frommemory(LIBSSH2_SESSION *session, + const char *username, + unsigned int username_len, + const char *publickeydata, + size_t publickeydata_len + const char *privatekeydata, + size_t privatekeydata_len + const char *passphrase); +.SH DESCRIPTION +\fIsession\fP - Session instance as returned by +.BR libssh2_session_init_ex(3) + +\fIusername\fP - Remote user name to authenticate as. + +\fIusername_len\fP - Length of username. + +\fIpublickeydata\fP - Buffer containing the contents of a public key file. + +\fIpublickeydata_len\fP - Length of public key data. + +\fIprivatekeydata\fP - Buffer containing the contents of a private key file. + +\fIprivatekeydata_len\fP - Length of private key data. + +\fIpassphrase\fP - Passphrase to use when decoding private key file. + +Attempt public key authentication using a PEM encoded private key file stored in memory + +.SH RETURN VALUE +Return 0 on success or negative on failure. It returns +LIBSSH2_ERROR_EAGAIN when it would otherwise block. While +LIBSSH2_ERROR_EAGAIN is a negative number, it isn't really a failure per se. + +.SH ERRORS +\fILIBSSH2_ERROR_ALLOC\fP - An internal memory allocation call failed. + +\fILIBSSH2_ERROR_SOCKET_SEND\fP - Unable to send data on socket. + +\fILIBSSH2_ERROR_SOCKET_TIMEOUT\fP - + +\fILIBSSH2_ERROR_PUBLICKEY_UNVERIFIED\fP - The username/public key +combination was invalid. + +\fILIBSSH2_ERROR_AUTHENTICATION_FAILED\fP - Authentication using the supplied +public key was not accepted. + +.SH SEE ALSO +.BR libssh2_session_init_ex(3) diff --git a/include/libssh2.h b/include/libssh2.h index 5a22be2..ac1bfed 100644 --- a/include/libssh2.h +++ b/include/libssh2.h @@ -531,6 +531,16 @@ libssh2_userauth_publickey_fromfile_ex(LIBSSH2_SESSION *session, const char *privatekey, const char *passphrase); +LIBSSH2_API int +libssh2_userauth_publickey_frommemory(LIBSSH2_SESSION *session, + const char *username, + unsigned int username_len, + const char *publickeyfiledata, + size_t publickeyfiledata_len, + const char *privatekeyfiledata, + size_t privatekeyfiledata_len, + const char *passphrase); + #define libssh2_userauth_publickey_fromfile(session, username, publickey, \ privatekey, passphrase) \ libssh2_userauth_publickey_fromfile_ex((session), (username), \ diff --git a/src/crypto.h b/src/crypto.h index 8cf34f5..6e95e9a 100644 --- a/src/crypto.h +++ b/src/crypto.h @@ -64,6 +64,11 @@ int _libssh2_rsa_new_private(libssh2_rsa_ctx ** rsa, LIBSSH2_SESSION * session, const char *filename, unsigned const char *passphrase); +int _libssh2_rsa_new_private_frommemory(libssh2_rsa_ctx ** rsa, + LIBSSH2_SESSION * session, + const char *filedata, + size_t filedata_len, + unsigned const char *passphrase); int _libssh2_rsa_sha1_verify(libssh2_rsa_ctx * rsa, const unsigned char *sig, unsigned long sig_len, @@ -89,6 +94,11 @@ int _libssh2_dsa_new_private(libssh2_dsa_ctx ** dsa, LIBSSH2_SESSION * session, const char *filename, unsigned const char *passphrase); +int _libssh2_dsa_new_private_frommemory(libssh2_dsa_ctx ** dsa, + LIBSSH2_SESSION * session, + const char *filedata, + size_t filedata_len, + unsigned const char *passphrase); int _libssh2_dsa_sha1_verify(libssh2_dsa_ctx * dsactx, const unsigned char *sig, const unsigned char *m, unsigned long m_len); @@ -113,6 +123,15 @@ int _libssh2_pub_priv_keyfile(LIBSSH2_SESSION *session, const char *privatekey, const char *passphrase); +int _libssh2_pub_priv_keyfilememory(LIBSSH2_SESSION *session, + unsigned char **method, + size_t *method_len, + unsigned char **pubkeydata, + size_t *pubkeydata_len, + const char *privatekeydata, + size_t privatekeydata_len, + const char *passphrase); + void _libssh2_init_aes_ctr(void); #endif diff --git a/src/hostkey.c b/src/hostkey.c index 53f7479..69dbfb8 100644 --- a/src/hostkey.c +++ b/src/hostkey.c @@ -131,6 +131,39 @@ hostkey_method_ssh_rsa_initPEM(LIBSSH2_SESSION * session, } /* + * hostkey_method_ssh_rsa_initPEMFromMemory + * + * Load a Private Key from a memory + */ +static int +hostkey_method_ssh_rsa_initPEMFromMemory(LIBSSH2_SESSION * session, + const char *privkeyfiledata, + size_t privkeyfiledata_len, + unsigned const char *passphrase, + void **abstract) +{ + libssh2_rsa_ctx *rsactx; + int ret; + + if (*abstract) { + hostkey_method_ssh_rsa_dtor(session, abstract); + *abstract = NULL; + } + + ret = _libssh2_rsa_new_private_frommemory(&rsactx, session, + privkeyfiledata, + privkeyfiledata_len, + passphrase); + if (ret) { + return -1; + } + + *abstract = rsactx; + + return 0; +} + +/* * hostkey_method_ssh_rsa_sign * * Verify signature created by remote @@ -208,6 +241,7 @@ static const LIBSSH2_HOSTKEY_METHOD hostkey_method_ssh_rsa = { MD5_DIGEST_LENGTH, hostkey_method_ssh_rsa_init, hostkey_method_ssh_rsa_initPEM, + hostkey_method_ssh_rsa_initPEMFromMemory, hostkey_method_ssh_rsa_sig_verify, hostkey_method_ssh_rsa_signv, NULL, /* encrypt */ @@ -306,6 +340,39 @@ hostkey_method_ssh_dss_initPEM(LIBSSH2_SESSION * session, } /* + * hostkey_method_ssh_dss_initPEMFromMemory + * + * Load a Private Key from memory + */ +static int +hostkey_method_ssh_dss_initPEMFromMemory(LIBSSH2_SESSION * session, + const char *privkeyfiledata, + size_t privkeyfiledata_len, + unsigned const char *passphrase, + void **abstract) +{ + libssh2_dsa_ctx *dsactx; + int ret; + + if (*abstract) { + hostkey_method_ssh_dss_dtor(session, abstract); + *abstract = NULL; + } + + ret = _libssh2_dsa_new_private_frommemory(&dsactx, session, + privkeyfiledata, + privkeyfiledata_len, + passphrase); + if (ret) { + return -1; + } + + *abstract = dsactx; + + return 0; +} + +/* * libssh2_hostkey_method_ssh_dss_sign * * Verify signature created by remote @@ -392,6 +459,7 @@ static const LIBSSH2_HOSTKEY_METHOD hostkey_method_ssh_dss = { MD5_DIGEST_LENGTH, hostkey_method_ssh_dss_init, hostkey_method_ssh_dss_initPEM, + hostkey_method_ssh_dss_initPEMFromMemory, hostkey_method_ssh_dss_sig_verify, hostkey_method_ssh_dss_signv, NULL, /* encrypt */ diff --git a/src/libssh2_priv.h b/src/libssh2_priv.h index c670a16..6579b77 100644 --- a/src/libssh2_priv.h +++ b/src/libssh2_priv.h @@ -853,6 +853,10 @@ struct _LIBSSH2_HOSTKEY_METHOD size_t hostkey_data_len, void **abstract); int (*initPEM) (LIBSSH2_SESSION * session, const char *privkeyfile, unsigned const char *passphrase, void **abstract); + int (*initPEMFromMemory) (LIBSSH2_SESSION * session, + const char *privkeyfiledata, + size_t privkeyfiledata_len, + unsigned const char *passphrase, void **abstract); int (*sig_verify) (LIBSSH2_SESSION * session, const unsigned char *sig, size_t sig_len, const unsigned char *m, size_t m_len, void **abstract); diff --git a/src/openssl.c b/src/openssl.c index 481982c..3daf74a 100644 --- a/src/openssl.c +++ b/src/openssl.c @@ -386,6 +386,27 @@ passphrase_cb(char *buf, int size, int rwflag, char *passphrase) typedef void * (*pem_read_bio_func)(BIO *, void **, pem_password_cb *, void * u); +static int +read_private_key_from_memory(void ** key_ctx, + pem_read_bio_func read_private_key, + const char * filedata, + size_t filedata_len, + unsigned const char *passphrase) +{ + BIO * bp; + + *key_ctx = NULL; + + bp = BIO_new_mem_buf((void*)filedata, filedata_len); + if (!bp) { + return -1; + } + *key_ctx = read_private_key(bp, NULL, (pem_password_cb *) passphrase_cb, + (void *) passphrase); + + BIO_free(bp); + return (*key_ctx) ? 0 : -1; +} static int read_private_key_from_file(void ** key_ctx, @@ -410,6 +431,22 @@ read_private_key_from_file(void ** key_ctx, } int +_libssh2_rsa_new_private_frommemory(libssh2_rsa_ctx ** rsa, + LIBSSH2_SESSION * session, + const char *filedata, size_t filedata_len, + unsigned const char *passphrase) +{ + pem_read_bio_func read_rsa = + (pem_read_bio_func) &PEM_read_bio_RSAPrivateKey; + (void) session; + + _libssh2_init_if_needed (); + + return read_private_key_from_memory((void **) rsa, read_rsa, + filedata, filedata_len, passphrase); +} + +int _libssh2_rsa_new_private(libssh2_rsa_ctx ** rsa, LIBSSH2_SESSION * session, const char *filename, unsigned const char *passphrase) @@ -426,6 +463,22 @@ _libssh2_rsa_new_private(libssh2_rsa_ctx ** rsa, #if LIBSSH2_DSA int +_libssh2_dsa_new_private_frommemory(libssh2_dsa_ctx ** dsa, + LIBSSH2_SESSION * session, + const char *filedata, size_t filedata_len, + unsigned const char *passphrase) +{ + pem_read_bio_func read_dsa = + (pem_read_bio_func) &PEM_read_bio_DSAPrivateKey; + (void) session; + + _libssh2_init_if_needed (); + + return read_private_key_from_memory((void **) dsa, read_dsa, + filedata, filedata_len, passphrase); +} + +int _libssh2_dsa_new_private(libssh2_dsa_ctx ** dsa, LIBSSH2_SESSION * session, const char *filename, unsigned const char *passphrase) @@ -801,4 +854,71 @@ _libssh2_pub_priv_keyfile(LIBSSH2_SESSION *session, return st; } +int +_libssh2_pub_priv_keyfilememory(LIBSSH2_SESSION *session, + unsigned char **method, + size_t *method_len, + unsigned char **pubkeydata, + size_t *pubkeydata_len, + const char *privatekeydata, + size_t privatekeydata_len, + const char *passphrase) +{ + int st; + BIO* bp; + EVP_PKEY* pk; + + _libssh2_debug(session, + LIBSSH2_TRACE_AUTH, + "Computing public key from private key."); + + bp = BIO_new_mem_buf((void*)privatekeydata, privatekeydata_len); + if (!bp) { + return -1; + } + if (!EVP_get_cipherbyname("des")) { + /* If this cipher isn't loaded it's a pretty good indication that none + * are. I have *NO DOUBT* that there's a better way to deal with this + * ($#&%#$(%$#( Someone buy me an OpenSSL manual and I'll read up on + * it. + */ + OpenSSL_add_all_ciphers(); + } + BIO_reset(bp); + pk = PEM_read_bio_PrivateKey(bp, NULL, NULL, (void*)passphrase); + BIO_free(bp); + + if (pk == NULL) { + return _libssh2_error(session, + LIBSSH2_ERROR_FILE, + "Unable to extract public key " + "from private key file: " + "Wrong passphrase or invalid/unrecognized " + "private key file format"); + } + + switch (pk->type) { + case EVP_PKEY_RSA : + st = gen_publickey_from_rsa_evp( + session, method, method_len, pubkeydata, pubkeydata_len, pk); + break; + + case EVP_PKEY_DSA : + st = gen_publickey_from_dsa_evp( + session, method, method_len, pubkeydata, pubkeydata_len, pk); + break; + + default : + st = _libssh2_error(session, + LIBSSH2_ERROR_FILE, + "Unable to extract public key " + "from private key file: " + "Unsupported private key file format"); + break; + } + + EVP_PKEY_free(pk); + return st; +} + #endif /* !LIBSSH2_LIBGCRYPT */ diff --git a/src/userauth.c b/src/userauth.c index 3fcb200..c4b71f4 100644 --- a/src/userauth.c +++ b/src/userauth.c @@ -441,6 +441,74 @@ libssh2_userauth_password_ex(LIBSSH2_SESSION *session, const char *username, return rc; } +static int +memory_read_publickey(LIBSSH2_SESSION * session, unsigned char **method, + size_t *method_len, + unsigned char **pubkeydata, + size_t *pubkeydata_len, + const char *pubkeyfiledata, + size_t pubkeyfiledata_len) +{ + unsigned char *pubkey = NULL, *sp1, *sp2, *tmp; + size_t pubkey_len = pubkeyfiledata_len; + unsigned int tmp_len; + + if (pubkeyfiledata_len <= 1) { + return _libssh2_error(session, LIBSSH2_ERROR_FILE, + "Invalid data in public key file"); + } + + pubkey = LIBSSH2_ALLOC(session, pubkeyfiledata_len); + if (!pubkey) { + return _libssh2_error(session, LIBSSH2_ERROR_ALLOC, + "Unable to allocate memory for public key data"); + } + memcpy(pubkey, pubkeyfiledata, pubkeyfiledata_len); + + /* + * Remove trailing whitespace + */ + while (pubkey_len && isspace(pubkey[pubkey_len - 1])) + pubkey_len--; + + if (!pubkey_len) { + LIBSSH2_FREE(session, pubkey); + return _libssh2_error(session, LIBSSH2_ERROR_FILE, + "Missing public key data"); + } + + if ((sp1 = memchr(pubkey, ' ', pubkey_len)) == NULL) { + LIBSSH2_FREE(session, pubkey); + return _libssh2_error(session, LIBSSH2_ERROR_FILE, + "Invalid public key data"); + } + + sp1++; + + if ((sp2 = memchr(sp1, ' ', pubkey_len - (sp1 - pubkey - 1))) == NULL) { + /* Assume that the id string is missing, but that it's okay */ + sp2 = pubkey + pubkey_len; + } + + if (libssh2_base64_decode(session, (char **) &tmp, &tmp_len, + (char *) sp1, sp2 - sp1)) { + LIBSSH2_FREE(session, pubkey); + return _libssh2_error(session, LIBSSH2_ERROR_FILE, + "Invalid key data, not base64 encoded"); + } + + /* Wasting some bytes here (okay, more than some), but since it's likely + * to be freed soon anyway, we'll just avoid the extra free/alloc and call + * it a wash */ + *method = pubkey; + *method_len = sp1 - pubkey - 1; + + *pubkeydata = tmp; + *pubkeydata_len = tmp_len; + + return 0; +} + /* * file_read_publickey * @@ -543,7 +611,42 @@ file_read_publickey(LIBSSH2_SESSION * session, unsigned char **method, return 0; } +static int +memory_read_privatekey(LIBSSH2_SESSION * session, + const LIBSSH2_HOSTKEY_METHOD ** hostkey_method, + void **hostkey_abstract, + const unsigned char *method, int method_len, + const char *privkeyfiledata, size_t privkeyfiledata_len, + const char *passphrase) +{ + const LIBSSH2_HOSTKEY_METHOD **hostkey_methods_avail = + libssh2_hostkey_methods(); + *hostkey_method = NULL; + *hostkey_abstract = NULL; + while (*hostkey_methods_avail && (*hostkey_methods_avail)->name) { + if ((*hostkey_methods_avail)->initPEMFromMemory + && strncmp((*hostkey_methods_avail)->name, (const char *) method, + method_len) == 0) { + *hostkey_method = *hostkey_methods_avail; + break; + } + hostkey_methods_avail++; + } + if (!*hostkey_method) { + return _libssh2_error(session, LIBSSH2_ERROR_METHOD_NONE, + "No handler for specified private key"); + } + + if ((*hostkey_method)-> + initPEMFromMemory(session, privkeyfiledata, privkeyfiledata_len, + (unsigned char *) passphrase, hostkey_abstract)) { + return _libssh2_error(session, LIBSSH2_ERROR_FILE, + "Unable to initialize private key from file"); + } + + return 0; +} /* libssh2_file_read_privatekey * Read a PEM encoded private key from an id_??? style file @@ -586,12 +689,49 @@ file_read_privatekey(LIBSSH2_SESSION * session, return 0; } + struct privkey_file { const char *filename; const char *passphrase; }; static int +sign_frommemory(LIBSSH2_SESSION *session, unsigned char **sig, size_t *sig_len, + const unsigned char *data, size_t data_len, void **abstract) +{ + struct privkey_file *pk_file = (struct privkey_file *) (*abstract); + const LIBSSH2_HOSTKEY_METHOD *privkeyobj; + void *hostkey_abstract; + struct iovec datavec; + int rc; + + rc = memory_read_privatekey(session, &privkeyobj, &hostkey_abstract, + session->userauth_pblc_method, + session->userauth_pblc_method_len, + pk_file->filename, + strlen(pk_file->filename), + pk_file->passphrase); + if(rc) + return rc; + + datavec.iov_base = (void *)data; + datavec.iov_len = data_len; + + if (privkeyobj->signv(session, sig, sig_len, 1, &datavec, + &hostkey_abstract)) { + if (privkeyobj->dtor) { + privkeyobj->dtor(session, abstract); + } + return -1; + } + + if (privkeyobj->dtor) { + privkeyobj->dtor(session, &hostkey_abstract); + } + return 0; +} + +static int sign_fromfile(LIBSSH2_SESSION *session, unsigned char **sig, size_t *sig_len, const unsigned char *data, size_t data_len, void **abstract) { @@ -1212,6 +1352,64 @@ _libssh2_userauth_publickey(LIBSSH2_SESSION *session, } /* + * userauth_publickey_frommemory + * Authenticate using a keypair from memory + */ +static int +userauth_publickey_frommemory(LIBSSH2_SESSION *session, + const char *username, + size_t username_len, + const char *publickeydata, + size_t publickeydata_len, + const char *privatekeydata, + size_t privatekeydata_len, + const char *passphrase) +{ + unsigned char *pubkeydata = NULL; + size_t pubkeydata_len = 0; + struct privkey_file privkey_file; + void *abstract = &privkey_file; + int rc; + + privkey_file.filename = privatekeydata; + privkey_file.passphrase = passphrase; + + if (session->userauth_pblc_state == libssh2_NB_state_idle) { + if (publickeydata_len && publickeydata) { + rc = memory_read_publickey(session, &session->userauth_pblc_method, + &session->userauth_pblc_method_len, + &pubkeydata, &pubkeydata_len, + publickeydata, publickeydata_len); + if(rc) + return rc; + } + else if (privatekeydata_len && privatekeydata) { + /* Compute public key from private key. */ + if (_libssh2_pub_priv_keyfilememory(session, + &session->userauth_pblc_method, + &session->userauth_pblc_method_len, + &pubkeydata, &pubkeydata_len, + privatekeydata, + privatekeydata_len, passphrase)) + return _libssh2_error(session, LIBSSH2_ERROR_FILE, + "Unable to extract public key " + "from private key."); + } + else + return _libssh2_error(session, LIBSSH2_ERROR_FILE, + "Invalid data in public and private key."); + } + + rc = _libssh2_userauth_publickey(session, username, username_len, + pubkeydata, pubkeydata_len, + sign_frommemory, &abstract); + if(pubkeydata) + LIBSSH2_FREE(session, pubkeydata); + + return rc; +} + +/* * userauth_publickey_fromfile * Authenticate using a keypair found in the named files */ @@ -1263,6 +1461,36 @@ userauth_publickey_fromfile(LIBSSH2_SESSION *session, return rc; } +/* libssh2_userauth_publickey_frommemory + * Authenticate using a keypair from memory + */ +LIBSSH2_API int +libssh2_userauth_publickey_frommemory(LIBSSH2_SESSION *session, + const char *user, + unsigned int user_len, + const char *publickeyfiledata, + size_t publickeyfiledata_len, + const char *privatekeyfiledata, + size_t privatekeyfiledata_len, + const char *passphrase) +{ + int rc; + + if(NULL == passphrase) + /* if given a NULL pointer, make it point to a zero-length + string to save us from having to check this all over */ + passphrase=""; + + BLOCK_ADJUST(rc, session, + userauth_publickey_frommemory(session, user, user_len, + publickeyfiledata, + publickeyfiledata_len, + privatekeyfiledata, + privatekeyfiledata_len, + passphrase)); + return rc; +} + /* libssh2_userauth_publickey_fromfile_ex * Authenticate using a keypair found in the named files */ -- 1.7.5.4 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 22:21:26 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JLLPB1032347; Mon, 19 Mar 2012 22:21:25 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JLLNbQ032321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Mar 2012 22:21:23 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2JLLNTE032316 for ; Mon, 19 Mar 2012 22:21:23 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 19 Mar 2012 22:21:23 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: SCP Transfer example Hangs In-Reply-To: <1332184223.54080.YahooMailRC@web180405.mail.gq1.yahoo.com> Message-ID: References: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> <1332184223.54080.YahooMailRC@web180405.mail.gq1.yahoo.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On Mon, 19 Mar 2012, Armen Babakhanian wrote: > I'll do that certainly but I thought maybe someone else should run it and > confirm that it actually hangs before I continue to do that. I can confirm that this is a regression that I too can repeat! Just downloaded a 102400000 bytes file several times that stopped at 102399950 each time using current git. > btw, I tried different libraries before I switched to yours, and so far it > works great, except this little issue.Thanks for your effort. Thanks for the kind words! -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Mon Mar 19 22:39:12 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JLd04N011969; Mon, 19 Mar 2012 22:39:09 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2JLcwQA011954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Mar 2012 22:38:58 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2JLcwlv011951 for ; Mon, 19 Mar 2012 22:38:58 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 19 Mar 2012 22:38:58 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Re: SCP Transfer example Hangs In-Reply-To: Message-ID: References: <1332181689.60413.YahooMailRC@web180416.mail.gq1.yahoo.com> <1332184223.54080.YahooMailRC@web180405.mail.gq1.yahoo.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1129329158-299195234-1332193138=:13166" X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-299195234-1332193138=:13166 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 19 Mar 2012, Daniel Stenberg wrote: > I can confirm that this is a regression that I too can repeat! Just > downloaded a 102400000 bytes file several times that stopped at 102399950 > each time using current git. Hi again, Please try the attached patch. It seems to fix the issue for me, the logic makes perfect sense to me and I'm sorry for being the one who caused this regression... :-( -- / daniel.haxx.se --1129329158-299195234-1332193138=:13166 Content-Type: TEXT/x-diff; name=0001-channel_read-force-window-adjusts.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=0001-channel_read-force-window-adjusts.patch RnJvbSAyZWE0MGU2M2U4ZGFjNDI2ZjUzMzhkMTZkNWIyZjAwNmI1MTkzNWY1 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogRGFuaWVsIFN0ZW5i ZXJnIDxkYW5pZWxAaGF4eC5zZT4NCkRhdGU6IE1vbiwgMTkgTWFyIDIwMTIg MjI6MzQ6MDQgKzAxMDANClN1YmplY3Q6IFtQQVRDSF0gY2hhbm5lbF9yZWFk OiBmb3JjZSB3aW5kb3cgYWRqdXN0cyENCg0KaWYgdGhlcmUncyBub3QgZW5v dWdoIHJvb20gdG8gcmVjZWl2ZSB0aGUgZGF0YSB0aGF0J3MgYmVpbmcgcmVx dWVzdGVkLA0KdGhlIHdpbmRvdyBhZGp1c3RtZW50IG5lZWRzIHRvIGJlIHNl bnQgdG8gdGhlIHJlbW90ZSBhbmQgdGh1cyB0aGUgZm9yY2UNCm9wdGlvbiBo YXMgdG8gYmUgdXNlZC4gX2xpYnNzaDJfY2hhbm5lbF9yZWNlaXZlX3dpbmRv d19hZGp1c3QoKSB3b3VsZA0Kb3RoZXJ3aXNlICJxdWV1ZSIgc21hbGwgd2lu ZG93IGFkanVzdG1lbnRzIGZvciBhIGxhdGVyIHBhY2tldCBidXQgdGhhdA0K aXMgcmVhbGx5IHRlcnJpYmx5IGZvciB0aGUgc21hbGwgYnVmZmVyIHJlYWQg dGhhdCBmb3IgZXhhbXBsZSBpcyB0aGUNCmZpbmFsIGxpdHRsZSBwaWVjZSBv ZiBhIHZlcnkgbGFyZ2UgZmlsZSBhcyB0aGVuIHRoZXJlIGlzIG5vIGxvZ2lj YWwgbmV4dA0KcGFja2V0IQ0KDQpSZXBvcnRlZCBieTogQXJtZW4gQmFiYWto YW5pYW4NCkJ1ZzogaHR0cDovL3d3dy5saWJzc2gyLm9yZy9tYWlsL2xpYnNz aDItZGV2ZWwtYXJjaGl2ZS0yMDEyLTAzLzAxMzAuc2h0bWwNCi0tLQ0KIHNy Yy9jaGFubmVsLmMgfCAgICAyICstDQogMSBmaWxlcyBjaGFuZ2VkLCAxIGlu c2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9z cmMvY2hhbm5lbC5jIGIvc3JjL2NoYW5uZWwuYw0KaW5kZXggOWUyOTQ5Mi4u NTE4MWY2ZiAxMDA2NDQNCi0tLSBhL3NyYy9jaGFubmVsLmMNCisrKyBiL3Ny Yy9jaGFubmVsLmMNCkBAIC0xODk4LDcgKzE4OTgsNyBAQCBsaWJzc2gyX2No YW5uZWxfcmVhZF9leChMSUJTU0gyX0NIQU5ORUwgKmNoYW5uZWwsIGludCBz dHJlYW1faWQsIGNoYXIgKmJ1ZiwNCiAgICAgaWYoYnVmbGVuID4gcmVjdl93 aW5kb3cpIHsNCiAgICAgICAgIEJMT0NLX0FESlVTVChyYywgY2hhbm5lbC0+ c2Vzc2lvbiwNCiAgICAgICAgICAgICAgICAgICAgICBfbGlic3NoMl9jaGFu bmVsX3JlY2VpdmVfd2luZG93X2FkanVzdChjaGFubmVsLCBidWZsZW4sDQot ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMCwgTlVMTCkpOw0KKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEs IE5VTEwpKTsNCiAgICAgfQ0KIA0KICAgICBCTE9DS19BREpVU1QocmMsIGNo YW5uZWwtPnNlc3Npb24sDQotLSANCjEuNy45LjENCg0K --1129329158-299195234-1332193138=:13166 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel --1129329158-299195234-1332193138=:13166-- From libssh2-devel-bounces@cool.haxx.se Wed Mar 28 15:17:52 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDHFka005093; Wed, 28 Mar 2012 15:17:41 +0200 Received: from gourmet8.spamgourmet.com (gourmet7.spamgourmet.com [216.75.62.102]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDGmoH004688 for ; Wed, 28 Mar 2012 15:16:49 +0200 Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69) (envelope-from ) id 1SCsk4-0008QZ-Oz for libssh2-devel@cool.haxx.se; Wed, 28 Mar 2012 13:16:48 +0000 Received: from mail-iy0-f176.google.com ([209.85.210.176]) by gourmet7.spamgourmet.com with esmtp (Exim 4.69) (envelope-from ) id 1SCsk4-0008Q5-FB for ; Wed, 28 Mar 2012 13:16:48 +0000 Received: by iagw33 with SMTP id w33so1547730iag.7 for <>; Wed, 28 Mar 2012 06:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8VMgDpBSrX9vwHNqpNKQWB2gUfFheh8TyjfptgBYNwU=; b=hQ/cLhgcn13vzVjaeJu2psNYCfxPMgAq1R+cIJ8N8awfywOVvixV3zNQp/E5FTaxee yuS9hk5aS/M99hWVVDZ7G8LGEaWIjVCHLn3Tb+IHlmSWrEnlwxVNCQM948T6uQYohen/ 4W+SriioA/LxDpi5Zmq+n4b8OVtiGhj6SYG8YwxU2Sb+xctENYfqY/Mpf9YrKRFEf1zG 4MGaSaqNcWLYkXm/QBO3DBrEK8Tl2Ja7XXxyL7whZy1PBb5Qj8mS1aWOe8oPFIgRWW/U CPrbJs8leorMYdaqVecht1HV6rH9NFF8dinPbhBzlEP4Fqi34GktM5Xm24cJSGbS7IJo nQ6g== MIME-Version: 1.0 Received: by 10.50.154.167 with SMTP id vp7mr2044172igb.55.1332940608020; Wed, 28 Mar 2012 06:16:48 -0700 (PDT) Received: by 10.231.135.197 with HTTP; Wed, 28 Mar 2012 06:16:47 -0700 (PDT) Date: Wed, 28 Mar 2012 15:16:47 +0200 Message-ID: Subject: libssh2 not making on AIX5.2 - Undefined symbol: ._libssh_error From: libssh2.bullrunner@spamgourmet.com To: libssh2-devel@cool.haxx.se X-Spamgourmet: X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hi All, It looks like I am getting a rather unique error, given the low hit numbers on Google. I am trying to build libssh2 1.4.0 on AIX 5.2 and really struggling. Google has sent me on a good few wild goose chases, with days of installing and uninstalling various things, but keep coming back to the error below. Hopefully someone can help me because I desperately need to get this resolved so that I can move onto the build of cURL that people are shouting for. I'm not sure what all is needed for you guys to help, but I thought I would open with the below:- /tmp/libssh2/libssh2-1.4.0 >/usr/local/bin/make Making all in src make[1]: Entering directory `/tmp/libssh2/libssh2-1.4.0/src' /usr/local/bin/make all-am make[2]: Entering directory `/tmp/libssh2/libssh2-1.4.0/src' if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I../include -I../src -g -O2 -MT channel.lo -MD -MP -MF ".deps/channel.Tpo" -c -o channel.lo channel.c; \ then mv -f ".deps/channel.Tpo" ".deps/channel.Plo"; else rm -f ".deps/channel.Tpo"; exit 1; fi _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 28 15:29:23 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDTJX5015715; Wed, 28 Mar 2012 15:29:22 +0200 Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDS5JB015012 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 28 Mar 2012 15:28:08 +0200 Received: by qcsg15 with SMTP id g15so709392qcs.41 for ; Wed, 28 Mar 2012 06:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=HjOdxwUfmFAz/8Jj+e3vEAuuX9Q96GJ5w2R4AOZkc4U=; b=yleu6VLpP1ANPbwQiDO/Gl1A+2Klc8xdS19Fi5Giou3W0AgsmAk4arkU3MiA5wZkeP CABHrKdVZNgh0kghgJOTqhvC4JFKHCbFyZw1h3sIAFC0UZmc/URwPs3+38rULeZVnxXz Gac5zV9915NlWlW6ThnAhUo+/LOCtFVo4h4setAhb67tkll0ustM4bkaQ5ylNhR1P0bB 3PYNEQNDUNTXvVnlwDHtNQgT34216cecdkTVYl2YapiKN5tgwcdMtMtPAjf/7x5h6b7s Zow0iCUM0sqkCbTA6QS6praNPQpVWIGJ0L9tTiOkYG7362+RYTsTXkAqoazMSZVuVV8d uZEw== MIME-Version: 1.0 Received: by 10.229.137.65 with SMTP id v1mr3721899qct.114.1332941273616; Wed, 28 Mar 2012 06:27:53 -0700 (PDT) Received: by 10.229.144.211 with HTTP; Wed, 28 Mar 2012 06:27:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 14:27:53 +0100 X-Google-Sender-Auth: m6Wx0h_6ajjmNkzrxY7pifkoGtc Message-ID: Subject: Re: libssh2 not making on AIX5.2 - Undefined symbol: ._libssh_error From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 28 March 2012 14:16, wrote: > > I am trying to build libssh2 1.4.0 on AIX 5.2 and really struggling. It's not obvious from what you've posted but I'm guessing you're using the gcrypt backend. There was a bug in this in 1.4.0 which meant it called a function that didn't exists _libssh_error. Try the latest git HEAD and you should have better luck. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 28 15:34:15 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDYC8t018877; Wed, 28 Mar 2012 15:34:14 +0200 Received: from gourmet8.spamgourmet.com (gourmet7.spamgourmet.com [216.75.62.102]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDY9Hb018851 for ; Wed, 28 Mar 2012 15:34:09 +0200 Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69) (envelope-from ) id 1SCt0s-0007wJ-7B for libssh2-devel@cool.haxx.se; Wed, 28 Mar 2012 13:34:10 +0000 Received: from mail-lpp01m010-f48.google.com ([209.85.215.48]) by gourmet7.spamgourmet.com with esmtp (Exim 4.69) (envelope-from ) id 1SCt0r-0007vk-Qh for ; Wed, 28 Mar 2012 13:34:10 +0000 Received: by lagu2 with SMTP id u2so1177298lag.7 for <>; Wed, 28 Mar 2012 06:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=r6hla5il3qsOeXW0HInS6dNo13mY1nbb2fJ03nOcdfw=; b=kPqTp4RgyZYnjffZO5o5/PijISKmmoZY3iBZaX7xCFXXagqhe5eeY8MxWdPFWwV9lA v7waCh8F3IM7Om4mVxwcIe7yUtRjjftEZcYpw8Fd2Yy9ajw9r73XCqcvg7QOGol2nLdm vmw3aYMrOvgalpVCUZfwej+2K+EK8K+lMqKU+GURNdjEpSPr9AXus0211HgmDQRWbBse /ozt8FsdHPkr/mzy9hSboy+WPWz7JUTnNreoIl4j1/+jXAROmL5nXwgIAH3t+xCV06Ge 0qca1tH0AQMEWkMItsP7OlxjcsGMiJ3tMzybJGcmW98yPQdvA+gEEy4G2QfhJSJTVDj7 aicQ== MIME-Version: 1.0 Received: by 10.152.105.241 with SMTP id gp17mr25295516lab.21.1332941648486; Wed, 28 Mar 2012 06:34:08 -0700 (PDT) Received: by 10.112.109.7 with HTTP; Wed, 28 Mar 2012 06:34:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 15:34:08 +0200 Message-ID: Subject: Re: libssh2 not making on AIX5.2 - Undefined symbol: ._libssh_error (libssh2: message 1 of 20) From: libssh2.bullrunner@spamgourmet.com To: libssh2-devel@cool.haxx.se X-Spamgourmet: X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2SDY9Hb018851 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2SDYC8t018877 Hi, Sorry it looks like some of the info got lost. Here is the rest of my original email, and the important part, the error message libtool: link: /usr/bin/grep -E -e "^libssh2_.*" ".libs/libssh2.exp" > ".libs/libssh2.expT" libtool: link: mv -f ".libs/libssh2.expT" ".libs/libssh2.exp" libtool: link: gcc -shared -o .libs/libssh2.so.1 .libs/channel.o .libs/comp.o .libs/crypt.o .libs/hostkey.o .libs/kex.o .libs/mac.o .libs/misc.o .libs/packet.o .libs/publickey.o .libs/scp.o .libs/session.o .libs/sftp.o .libs/userauth.o .libs/transport.o .libs/version.o .libs/knownhost.o .libs/agent.o .libs/openssl.o .libs/libgcrypt.o .libs/pem.o .libs/keepalive.o .libs/global.o -Wl,-blibpath:/opt/freeware/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2:/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/../../..:/usr/lib:/lib -L/opt/freeware/lib -lgcrypt -lz -lc -Wl,-bnoentry -Wl,-bE:.libs/libssh2.exp -Wl,-bernotok ld: 0711-317 ERROR: Undefined symbol: ._libssh_error ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make[2]: *** [libssh2.la] Error 1 make[2]: Leaving directory `/tmp/libssh2/libssh2-1.4.0/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/libssh2/libssh2-1.4.0/src' make: *** [all-recursive] Error 1 On Wed, Mar 28, 2012 at 3:16 PM, <+libssh2+bullrunner+5eb356b9fd.libssh2.bullrunner#spamgourmet.com@spamgourmet.com> wrote: > Hi All, > > It looks like I am getting a rather unique error, given the low hit > numbers on Google. > > I am trying to build libssh2 1.4.0 on AIX 5.2 and really struggling. > Google has sent me on a good few wild goose chases, with days of > installing and uninstalling various things, but keep coming back to > the error below. > Hopefully someone can help me because I desperately need to get this > resolved so that I can move onto the build of cURL that people are > shouting for. > > I'm not sure what all is needed for you guys to help, but I thought I > would open with the below:- > > > > /tmp/libssh2/libssh2-1.4.0 >/usr/local/bin/make > Making all in src > make[1]: Entering directory `/tmp/libssh2/libssh2-1.4.0/src' > /usr/local/bin/make  all-am > make[2]: Entering directory `/tmp/libssh2/libssh2-1.4.0/src' > if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H > -I../include -I../src   -g -O2 -MT channel.lo -MD -MP -MF > ".deps/channel.Tpo" -c -o channel.lo channel.c; \ > then mv -f ".deps/channel.Tpo" ".deps/channel.Plo"; else rm -f > ".deps/channel.Tpo"; exit 1; fi > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 28 15:58:16 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDw8Hf004239; Wed, 28 Mar 2012 15:58:15 +0200 Received: from gourmet8.spamgourmet.com (gourmet7.spamgourmet.com [216.75.62.102]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SDw7q2004234 for ; Wed, 28 Mar 2012 15:58:07 +0200 Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69) (envelope-from ) id 1SCtO3-0008VG-Pr for libssh2-devel@cool.haxx.se; Wed, 28 Mar 2012 13:58:07 +0000 Received: from mail-lpp01m010-f48.google.com ([209.85.215.48]) by gourmet7.spamgourmet.com with esmtp (Exim 4.69) (envelope-from ) id 1SCtO3-0008Ub-DM for ; Wed, 28 Mar 2012 13:58:07 +0000 Received: by lagu2 with SMTP id u2so1200420lag.7 for <>; Wed, 28 Mar 2012 06:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=mtFt5UqEiU2n7w0GnsYpFjVROS5o/fDwDDbVvac16DA=; b=AO2TTruPpljYfMdFXTiwK6LZwBxwCPWMDH5FXCJePXDTtlpZqZJZRW0Vfjj3YGbIYc 3SPtJSZKJqYAyQ716WqaW/pucvTZa00MdfqGknzD2X9udyx+66Xqmi9IyaozloXp0m4m dvc3VENdEVuMrP5TX+zrlpTBHkH4Aie50iUtNNwgJl9+Vq1aZZ6JY8uYGjAYUoaQ4u0N 3n2o9AM5GSl6u7COyCwtJj00pnm5RN4NFObZRLIJbBwaxpDLQM9DumEvUt9PdBg/Aicx hQPFChXcT82pl2plOP2LYBjt4sKh82M8Ms+mp/+G3aYblfnjLTmVELEII1s4S74FHZWo wruQ== MIME-Version: 1.0 Received: by 10.152.105.241 with SMTP id gp17mr25390133lab.21.1332943086153; Wed, 28 Mar 2012 06:58:06 -0700 (PDT) Received: by 10.112.109.7 with HTTP; Wed, 28 Mar 2012 06:58:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 15:58:06 +0200 Message-ID: Subject: Re: libssh2 not making on AIX5.2 - Undefined symbol: ._libssh_error (libssh2: message 2 of 20) From: libssh2.bullrunner@spamgourmet.com To: libssh2-devel@cool.haxx.se X-Spamgourmet: X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2SDw7q2004234 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2SDw8Hf004239 Hi Alex, Thanx for your speedy response, you hit the nail on the head. Please excuse my newbie'ness, but how do I get the latest git HEAD? Thanx. On Wed, Mar 28, 2012 at 3:27 PM, Alexander Lamaison - swish@lammy.co.uk <+libssh2+bullrunner+fd10464135.swish#lammy.co.uk@spamgourmet.com> wrote: > On 28 March 2012 14:16,   wrote: >> >> I am trying to build libssh2 1.4.0 on AIX 5.2 and really struggling. > > It's not obvious from what you've posted but I'm guessing you're using > the gcrypt backend.  There was a bug in this in 1.4.0 which meant it > called a function that didn't exists _libssh_error.  Try the latest > git HEAD and you should have better luck. > > Alex > > -- > Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 28 16:10:25 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SEAI8F015106; Wed, 28 Mar 2012 16:10:24 +0200 Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SEAEJq015044 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 28 Mar 2012 16:10:17 +0200 Received: by qcsg15 with SMTP id g15so741748qcs.41 for ; Wed, 28 Mar 2012 07:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=DAv3ipJ1eg0wnRDD1ky0cFfGcS0EFBkcZXKMQoqSr9Y=; b=eA00bV8VRgBES3wvBcY3YAKgVuwTZZXo9MWhPvOhoVIW0dIODAXAG0potscmgzxWc0 4TSawENs/nZ9eubac7Jc1tdCavpGb8an5qSprJqtkd93TcY4JT43CQJAHua/cVCj+42R 0AXs1KPY4L/zE/PGd8NyvJT1GuaZoY9bwhIoRiSBmtGRcktWLLNZEP2keAXH2rYT9BG9 dwRI4+OSbKCqz18CCfx8+R0m+oVF2ajbNTLaarp1gt0MFy82BHKYmj4URq9urW01b3AV VNknKEbUmR4mzMWQFwOQj9H3bAY5YoqdXOuYaBGLlHmyvTZvjXEBFlnhmSok1loSFTRY f6NQ== MIME-Version: 1.0 Received: by 10.229.137.65 with SMTP id v1mr3786440qct.114.1332943810555; Wed, 28 Mar 2012 07:10:10 -0700 (PDT) Received: by 10.229.144.211 with HTTP; Wed, 28 Mar 2012 07:10:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 15:10:10 +0100 X-Google-Sender-Auth: dPVYHZRDBlLtsgzRWVdpysFNGDg Message-ID: Subject: Re: libssh2 not making on AIX5.2 - Undefined symbol: ._libssh_error (libssh2: message 2 of 20) From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 28 March 2012 14:58, wrote: > > Please excuse my newbie'ness, but how do I get the latest git HEAD? git clone git://git.libssh2.org/libssh2.git Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Mar 28 16:10:26 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SEAP9G015245; Wed, 28 Mar 2012 16:10:26 +0200 Received: from gourmet8.spamgourmet.com (gourmet7.spamgourmet.com [216.75.62.102]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SEAM2Z015167 for ; Wed, 28 Mar 2012 16:10:22 +0200 Received: from spamgourmet by gourmet7.spamgourmet.com with local (Exim 4.69) (envelope-from ) id 1SCtZu-0004Lf-8J for libssh2-devel@cool.haxx.se; Wed, 28 Mar 2012 14:10:22 +0000 Received: from mail-ey0-f176.google.com ([209.85.215.176]) by gourmet7.spamgourmet.com with esmtp (Exim 4.69) (envelope-from ) id 1SCtZt-0004LM-Ug for ; Wed, 28 Mar 2012 14:10:22 +0000 Received: by eaai1 with SMTP id i1so338057eaa.7 for <>; Wed, 28 Mar 2012 07:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=rrU4uLz2YGs4k8W/Qec0QFHzVTGebWZecccjTZCIzGs=; b=xJqQ75/n1teoiQ7CHLy8XzOUux1W1iKdX07XwIbfvMZ5XGRL4HqVLuul/5NMOkuEFG fs7sBzgy0gXFDgF7sMFCKEU323ceYOfMKyMlrZD2Rvfx/aszSvFNSmRjxrI43WdzVoOr CQPOHpFTnVM6MD8Izf3WtnNFQiIZdi88GIb0XKmSKUIig5B4lOZ74l+xnHwdssTmvSQA Jj+VDSwkHpyAwM5Ir5SwBrcg67I5P5c75H7vfSGOHAViA1U88RevQp4oHlr1SlIRvr5W 3X5dP2pRaOszb29yhBA0+g6DriODxDkp5CgbMfW6VNhP1m8tQd6Alovr4dYHZphaGFh1 wcbQ== MIME-Version: 1.0 Received: by 10.152.110.170 with SMTP id ib10mr25594790lab.7.1332943820900; Wed, 28 Mar 2012 07:10:20 -0700 (PDT) Received: by 10.112.109.7 with HTTP; Wed, 28 Mar 2012 07:10:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 16:10:20 +0200 Message-ID: Subject: Re: libssh2 not making on AIX5.2 - Undefined symbol: ._libssh_error (libssh2: message 4 of 20) (libssh2: message 2 of 20) From: libssh2.bullrunner@spamgourmet.com To: libssh2-devel@cool.haxx.se X-Spamgourmet: X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2SEAM2Z015167 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id q2SEAP9G015245 Don't worry, I came right. I found this patch and just edited the source manually http://git.libssh2.org/?p=libssh2.git;a=patch;h=b3ade9a63e881e69b4c9cfe7b5dbad78dcc4a0e0;js=1 I should have come here first instead of battling for days. Thanx Alex On Wed, Mar 28, 2012 at 3:58 PM, <+libssh2+bullrunner+5eb356b9fd.libssh2.bullrunner#spamgourmet.com@spamgourmet.com> wrote: > Hi Alex, > > Thanx for your speedy response, you hit the nail on the head. > > Please excuse my newbie'ness, but how do I get the latest git HEAD? > > Thanx. > > On Wed, Mar 28, 2012 at 3:27 PM, Alexander Lamaison - > swish@lammy.co.uk > <+libssh2+bullrunner+fd10464135.swish#lammy.co.uk@spamgourmet.com> > wrote: >> On 28 March 2012 14:16,   wrote: >>> >>> I am trying to build libssh2 1.4.0 on AIX 5.2 and really struggling. >> >> It's not obvious from what you've posted but I'm guessing you're using >> the gcrypt backend.  There was a bug in this in 1.4.0 which meant it >> called a function that didn't exists _libssh_error.  Try the latest >> git HEAD and you should have better luck. >> >> Alex >> >> -- >> Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) >> _______________________________________________ >> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel >> > > > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel > _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 29 00:22:07 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SMLdsh002161; Thu, 29 Mar 2012 00:22:01 +0200 Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2SMLZk7002124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 29 Mar 2012 00:21:37 +0200 Received: by pbcwz17 with SMTP id wz17so2504182pbc.41 for ; Wed, 28 Mar 2012 15:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=yl6lX5V4erNi6Qy+WfWVLIWUlir7un1yQnZ02v0g8yQ=; b=dQsAqsDgLnKJQUB0dObdzsidzG6WzT+L64DI/DWNrq2dTJRVs6MQV5PLAsMXCcki3x KfDPpNi7ObKB0IXnIhzUzDx9NZr5DSLeni6tF0SmQEzoogUWAow8zY98F4/cP0eEBXhC 451p6wdYloWeVMJ3kYOawSkjUwJIY1hpopr1IRZrXhzoMwXomcWNEF7UTenokJxAVNny AfGt6Zcj6EqRDGZQRy9e4qKmB8VVWcy8cBugzND7k8htl+6UEosanwJywBKAVFXG1Y4r v9MjoE5rXMNgfs2PV+4mQQWk9ZCy957gCwvSHfiQsEEmss6jcG+z8JlbnpUHgI9TVC8T ObXg== Received: by 10.68.202.167 with SMTP id kj7mr154513pbc.9.1332973291809; Wed, 28 Mar 2012 15:21:31 -0700 (PDT) Received: from freyja (radhermit.com. [74.207.248.182]) by mx.google.com with ESMTPS id l4sm3533152pbl.27.2012.03.28.15.21.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Mar 2012 15:21:30 -0700 (PDT) Date: Wed, 28 Mar 2012 15:21:26 -0700 From: Tim Harder To: libssh2-devel@cool.haxx.se Subject: [PATCH] Avoid leaking environment LDFLAGS in pkg-config file Message-ID: <20120328222126.GA1547@freyja> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se --- libssh2.pc.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libssh2.pc.in b/libssh2.pc.in index 637f5ed..acc77c2 100644 --- a/libssh2.pc.in +++ b/libssh2.pc.in @@ -11,6 +11,6 @@ Name: libssh2 URL: http://www.libssh2.org/ Description: Library for SSH-based communication Version: @LIBSSH2VER@ -Libs: -L${libdir} -lssh2 @LDFLAGS@ @LIBS@ +Libs: -L${libdir} -lssh2 @LIBS@ Libs.private: @LIBS@ Cflags: -I${includedir} -- 1.7.8.5 _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 29 02:19:37 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2T0JKAq011262; Thu, 29 Mar 2012 02:19:34 +0200 Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2T0JGfX011193 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 29 Mar 2012 02:19:17 +0200 Received: by pbcwz17 with SMTP id wz17so2650603pbc.41 for ; Wed, 28 Mar 2012 17:19:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=phLFoWaNA9oQa1ZgmBgLF5AyoVT1b+L2TmaxI/ZuC7w=; b=pOUYNXBxDpAFGgSMr28cuDXB4/4XCXs5iWrziZ4ndu9C08P8QCE/1+wPn6E6x/PSly qqlWfOuj7MSHY+6tDHC37BWxpUhYcecHFIjn1XDc6+ATdqf8cNbcOW0tIiFo51hYA9+6 EevlK/IR+7tBir14S3xORQUQ2QUKS9JRIa4ne3Bw3MqCUgVHmV0zIF+6FsEEaqXCsv1O wnXz8lFsVMJQ9bHk8V+eWhZEii1AYMs0afRg8cpJnMf4m81QXPJPZWziVNoSYil96mh6 jXRdxcmrWQp8ie6oW3hT/VZrdNTEUwEt9dzsLyZNBou9SxYfvnETPielb7RRkq+7XH5w VkuQ== MIME-Version: 1.0 Received: by 10.68.201.73 with SMTP id jy9mr763677pbc.35.1332980352074; Wed, 28 Mar 2012 17:19:12 -0700 (PDT) Received: by 10.68.130.230 with HTTP; Wed, 28 Mar 2012 17:19:12 -0700 (PDT) X-Originating-IP: [69.226.47.131] Date: Wed, 28 Mar 2012 17:19:12 -0700 Message-ID: Subject: libssh2_sftp_read reads a number of bytes smaller than both the file size and the specified buffer size From: Adam Craig To: libssh2-devel@cool.haxx.se X-Gm-Message-State: ALoCoQlgxsuORn9fQklZUBNuDJ3wxIRaHtpZWUlUfd+nOpPvmEIzfRkgxt6h/Q2U1xkPwF9Kvhuf X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se Hello Libssh2 Dev Mailing List, I am working on a cocoa application that uses libssh2 to SFTP files to and from a server. For the most part, I followed the example http://www.libssh2.org/examples/sftp.html but made a few changes. Most of these changes, such as always using public key authentication instead of password authentication and using the data to initialize an NSData object instead of writing it to a file once the read operations have finished, should not affect how much libssh2_sftp_read reads on a single call. The only relevant difference is that, instead of reading in data to one buffer and copying it to another after every call, my version uses a sliding window approach: 1. Allocate a buffer larger than the largest file the program should need to read. 2. Create a pointer to the start of the buffer. 3. Call libssh2_sftp_read(sftp_handle, [pointer to start of blank buffer], [size of blank buffer]); 4. a. If return value is positive, i. add the number of bytes read to the pointer so that it points to the start of the bytes that are still blank. ii. subtract the number of bytes read from the size of the blank buffer. iii. if buffer is more than half full, allocate a larger buffer, copy over the data already written, deallocate the old buffer, point the pointer to the start of the blank spaces in the new buffer, and set the size of the blank buffer to the number of bytes still blank in the new buffer. iv. return to step 3 with the new argument values. b. If return value is 0, stop and return the data wrapped in an NSData. c. If return value is negative, report the error and return nil (similar to null but for Cocoa objects). This is my version of the read function: in class header file: size_t max_file_size; in initialization method: max_file_size = 524288; file_buffer = (char *)malloc(max_file_size); method implementation: -(NSData *)readData:(NSString *)filePath error:(NSError **)error { NSData *data = nil; @try { *error = nil; //Did we remember to call libssh2_init elsewhere? if (![SFTPHandler globalsInited]) { //[...error handling...] return NO; } //We did the authentication and the creation of the sftp session handle in a previous method call and use this sftpConnected variable as a boolean to keep track of whether we are connected or not. if (!sftpConnected) { //[...error handling...] return nil; } sftppath = [filePath UTF8String]; sftp_handle = libssh2_sftp_open(sftp_session, sftppath, LIBSSH2_FXF_READ, 0); if (!sftp_handle) { //[...error handling...] return nil; } BOOL done = NO; char *dataEnd; int dataLength = 0; int spaceRemaining; dataEnd = file_buffer; do { //If we run out of room, replace the array to which dataStart points with a bigger array. spaceRemaining = max_file_size - dataLength; if (spaceRemaining < data_Length) {//if more than half full, NSLog(@"ran out of room, making bigger array"); size_t max_file_size_temp = 2*max_file_size; char *biggerArray = (char *)malloc(max_file_size_temp); if (!biggerArray) { //[...error handling...] done = YES; break; } //Copy over the data we already have. memcpy(biggerArray, file_buffer, dataLength); free(file_buffer); file_buffer = biggerArray; dataEnd = file_buffer + dataLength; spaceRemaining = max_file_size_temp - dataLength; max_file_size = max_file_size_temp; NSLog(@"max_file_size=%i", max_file_size); } //Note the return value is the number of bytes read. NSLog(@"about to read once: dataEnd=%i, spaceRemaining=%i", dataEnd, spaceRemaining); rc = libssh2_sftp_read(sftp_handle, dataEnd, spaceRemaining); NSLog(@"return value = %i", rc); if (rc > 0) { dataEnd += rc; dataLength += rc; NSLog(@"updated place markers: dataEnd=%i, dataLength=%i", dataEnd, dataLength); } else { //Note that we have it set to allow blocking, so we should not get L_BSSH2_ERROR_EAGAIN NSLog(@"no data returned this time"); done = YES; if (rc < 0) { //[...error handling...] } } } while (!done); NSLog(@"done reading data"); data = [NSData dataWithBytes:file_buffer length:dataLength]; NSLog(@"created data object for data, length=%i", [data length]); } @catch (NSException * e) { NSLog(@"exception while downloading %@", filePath); } @finally { libssh2_sftp_close(sftp_handle); NSLog(@"closed file handle"); } return data; } I have been testing this method with both small text files of a few kB each and Quicktime .mov files of up to 1MB. I am running the app on 64-bit Intel OS X 10.6.8 on the client side and communicating with a server running the standard linux sftp-server on Redhat Enterprise Linux Server 5.6. The version of libssh2 I am using is 1.4.0-20120229. For all files I have tested, the method downloads and returns the correct data, but it always returns it in chunks no larger than 2K, regardless of how large I make the buffer and regardless of the size of the file. More precisely, if the file is smaller than 2K, the first call downloads the complete file and returns the number of bytes in the file, but, if the file is larger than 2K, libssh2_sftp_read returns a value of 2000 after every call except for the second-to-last call, which returns (file size)%2000, and the last call, which returns 0, indicating we have read all the bytes in the file. At first, I thought it might be a peculiarity of the server's configuration, but I do not see any hard limit on sent packet size in sftp-server's documentation. Is this an inherent limitation of the libssh2_sftp_read method? I also wrote a write method along similar lines. It has a maximum packet size, and, if a file is larger than that size, will use the sliding window approach to upload one packet's worth at a time until it has a final piece smaller than the maximum size. size_t packet_size; in initialization method: packet_size = 524288; file_buffer = (char *)malloc(max_file_size);//see read method -(BOOL)writeData:(NSData *)data toRemoteFile:(NSString *)filePath error:(NSError **)error { BOOL success; @try { *error = nil; sftppath = [filePath UTF8String]; const char *dataPos = [data bytes]; const char *dataEnd = dataPos + [data length]; if (![SFTPHandler globalsInited]) { [...error handling...] return NO; } if (!sftpConnected) { [...error handling...] return NO; } sftp_handle = libssh2_sftp_open(sftp_session, sftppath, write_mode, permissions);//write_mode=LIBSSH2_FXF_WRITE|LIBSSH2_FXF_CREAT; permissions=LIBSSH2_SFTP_S_IRWXU|LIBSSH2_SFTP_S_IRGRP; User has full access. Group has read only access. if (!sftp_handle) { [...error handling...] return NO; } //Write a full packet until writing a full packet would take us over the file size. while (dataPos + max_file_size < dataEnd) { //write file rc = libssh2_sftp_write(sftp_handle, dataPos, max_file_size); //We allow blocking, so no LIBSSH2_ERROR_EAGAIN. if (rc <= 0) { [...error handling...] success = NO; break; } else { dataPos += rc; NSLog(@"complete packet written dataPos=%i, dataEnd=%i, rc=%i", dataPos, dataEnd, rc); //dataWritten += rc; } } if (*error == nil) {//When an error occurs, error gets set in the error handling code I have omitted. //Check that we still have data to write. if (dataPos < dataEnd) { //Write the last partial packet. NSLog(@"writing last partial packet, size=%i", (dataEnd - dataPos)); rc = libssh2_sftp_write(sftp_handle, dataPos, (dataEnd - dataPos)); NSLog(@"attempted write, return code=%i, packet_size=%i", rc, packet_size); if (rc < 0) { [...error handling...] success = NO; } else { NSLog(@"wrote last partial packet"); success = YES; } } } else { success = NO; } } @catch (NSException * e) { NSLog(@"exception while uploading %@:%@, %@", filePath, [e name], [e reason]); success = NO; } @finally { libssh2_sftp_close(sftp_handle); //NSLog(@"closed file"); } return success; } I am testing this with the same client macbook and server and the same version of libssh2. If I upload a file smaller than 30K, libssh2_sftp_write, the program tries to upload it all in one call, succeeds, and returns the correct number of bytes. If I upload a file larger than 30K but smaller than packet_size, it attempts to upload all the data in one call. The complete file appears on the server, but libssh2_sftp_write only returns 30000. If I upload a file larger than the packet size, each full-packet call returns 30000, causing the loop to slide the window forward by 30000. Once it gets to a point where fewer than packet_size bytes remains, it jumps to the last call and tries to upload all the remaining bytes. This call returns up to 30000. When I check the server, it has the complete file. It appears that the return value and the amount of data uploaded do not match. I would like to be able to download larger packets, but I am also wondering why the functions behave this way. Did I overlook something in the documentation or in an earlier mailing list post? Hoping that this is the correct place to send questions about libssh2 usage, Adam Craig _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Thu Mar 29 14:53:28 2012 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2TCqwBZ023503; Thu, 29 Mar 2012 14:53:20 +0200 Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2TCqtIh023427 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 29 Mar 2012 14:52:57 +0200 Received: by qatm19 with SMTP id m19so373770qat.13 for ; Thu, 29 Mar 2012 05:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=7FoZ2fxy0J2qvawqe0PrOAG9LggBr/wZaYjfOAgMnpY=; b=ZtckPPFDe0d7R3G4FfB1rB/pqB/SMpf7Xl32rLE/LCwwBZWOdojmV5aI5odjoEvw/R uaVKXiEHa4A6SNiNhUl0ORDpv9fQlwIK5Avtlx4Aof/ed0f9sPfBh9CUVsRgEvZKveI7 UqM8wZCchD+drJBIrDWXviPYNVsXf5PjBSer/QQDBHFgOXKV4J5MnO5YSE02FXgs0fpu xV3y15AwRdPbLtSc1Y/fZUJMPMD2Ypz8DQe/iEDT56umjvqtDJ66zfnlAtvi+XHEGNQj 1j4s++u8P7jJt5BUq9qYtdUOuYGG/SPxxTwPfeTZPOtRgmDC8nnrOh+Wis5XwoOmwPSx oaUg== MIME-Version: 1.0 Received: by 10.229.134.207 with SMTP id k15mr6323647qct.94.1333025569357; Thu, 29 Mar 2012 05:52:49 -0700 (PDT) Received: by 10.229.144.211 with HTTP; Thu, 29 Mar 2012 05:52:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Mar 2012 13:52:49 +0100 X-Google-Sender-Auth: tgX6nKyX1rHzLPPEkBM06DL7zZs Message-ID: Subject: Re: libssh2_sftp_read reads a number of bytes smaller than both the file size and the specified buffer size From: Alexander Lamaison To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.14 Precedence: list Reply-To: libssh2 development List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: libssh2-devel-bounces@cool.haxx.se On 29 March 2012 01:19, Adam Craig wrote: > Hello Libssh2 Dev Mailing List, > > I am working on a cocoa application that uses libssh2 to SFTP files to > and from a server. ... snip > I have been testing this method with both small text files of a few kB > each and Quicktime .mov files of up to 1MB. I am running the app on > 64-bit Intel OS X 10.6.8 on the client side and communicating with a > server running the standard linux sftp-server on Redhat Enterprise > Linux Server 5.6. The version of libssh2 I am using is 1.4.0-20120229. > > For all files I have tested, the method downloads and returns the > correct data, but it always returns it in chunks no larger than 2K, > regardless of how large I make the buffer and regardless of the size > of the file. More precisely, if the file is smaller than 2K, the first > call downloads the complete file and returns the number of bytes in > the file, but, if the file is larger than 2K, libssh2_sftp_read > returns a value of 2000 after every call except for the second-to-last > call, which returns (file size)%2000, and the last call, which returns > 0, indicating we have read all the bytes in the file. At first, I > thought it might be a peculiarity of the server's configuration, but I > do not see any hard limit on sent packet size in sftp-server's > documentation. Is this an inherent limitation of the libssh2_sftp_read > method? So just to summarise, you're not reporting that the transfer is incomplete? Just that you wish the transfer used bigger chunks at a time? This is a perfectly valid thing to report, I just want to check I'm understanding you correctly. ... snip > I am testing this with the same client macbook and server and the same > version of libssh2. If I upload a file smaller than 30K, > libssh2_sftp_write, the program tries to upload it all in one call, > succeeds, and returns the correct number of bytes. If I upload a file > larger than 30K but smaller than packet_size, it attempts to upload > all the data in one call. The complete file appears on the server, but > libssh2_sftp_write only returns 30000. If I upload a file larger than > the packet size, each full-packet call returns 30000, causing the loop > to slide the window forward by 30000. Once it gets to a point where > fewer than packet_size bytes remains, it jumps to the last call and > tries to upload all the remaining bytes. This call returns up to > 30000. When I check the server, it has the complete file. > It appears that the return value and the amount of data uploaded do not match. This sounds like the expected behaviour of libssh2's pipelined SFTP architecture. The return value doesn't have to correspond to the amount uploaded on _that_ call as long as the overall total is correct. The last call that doesn't appear to do anything allows libssh2 to do some housekeeping. > I would like to be able to download larger packets I'm not sure why yours are limited to 2K but I believe this is negotiated with the server (jump in here guys if I'm wrong) so it's possible your server is refusing to send bigger packets. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel