Eduardo Valdes | 4 Jan 21:06 2011

Re: libssh 0.4.7

Does anybody have a link to a windows build of 0.4.7? The version found here: http://winkde.org/pub/kde/ports/win32/releases/nightly/latest/ is 0.4.6 I believe.

Thanks.

On Tue, Dec 28, 2010 at 4:13 PM, Andreas Schneider <asn-JhEiV406HZ1g9hUCZPvPmw@public.gmane.org> wrote:
Hi,

we've released libssh 0.4.7 with several bugfixes.

http://www.libssh.org/2010/12/28/libssh-0-4-7/

Please report bugs to http://red.libssh.org/

Cheers,


       -- andreas



--
Eddy Valdes
Project Manager
Atronix Engineering
evaldes <at> atronixengineering.com

Mark Riordan | 7 Jan 00:17 2011

libssh 0.4.7 vs compression

Is anyone else having problems with libssh 0.4.7 with compression
turned on?

In my testing, the server closes the connection right after key
negotiation if I enable compression.  However, the session proceeds
normally if I don't enable compression.
If I switch back to the 0.4.6 DLL (I'm using Windows), compression
works.  

I can't see any significant source code changes between 0.4.6 and 0.4.7
source that would account for this.  

I compared Wireshark traces between the two versions and the only 
significant difference I can see (before the server sends a FIN)
is that with 0.4.7, both the client and server send New Keys requests,
whereas with 0.4.6, only the server does.

Before I pursue this further, I'd like to know whether anyone else
has tested 0.4.7 with compression.

Thanks.

/mrr

Aris Adamantiadis | 7 Jan 10:51 2011
Picon

Re: libssh 0.4.7 vs compression

Le 07/01/11 00:17, Mark Riordan a écrit :
> Is anyone else having problems with libssh 0.4.7 with compression
> turned on?
> 
> In my testing, the server closes the connection right after key
> negotiation if I enable compression.  However, the session proceeds
> normally if I don't enable compression.
> If I switch back to the 0.4.6 DLL (I'm using Windows), compression
> works.  
> 
> I can't see any significant source code changes between 0.4.6 and 0.4.7
> source that would account for this.  
> 
> I compared Wireshark traces between the two versions and the only 
> significant difference I can see (before the server sends a FIN)
> is that with 0.4.7, both the client and server send New Keys requests,
> whereas with 0.4.6, only the server does.
> 
> Before I pursue this further, I'd like to know whether anyone else
> has tested 0.4.7 with compression.
> 
> Thanks.
> 
> /mrr
> 
> 
> 
Hi Mark,

The behavior you describe looks like a compression mismatch : libssh
thinks there is no compression (none) and server thinks there is
compression after key exchange (zlib). (or quite the opposite)

I just looked at the git logs, indeed there is no obvious change that
would produce that behavior.

Having a verbose log of what happens would be useful. Could you generate
it using ssh_options_set(session, SSH_OPTIONS_LOG_VERBOSITY) set ?
The wireshark traces would be useful as well. If there is any kind of
error message shown on the ssh server, I'd like to see it too.

Thanks,

Aris

Andreas Schneider | 7 Jan 16:13 2011

Re: libssh 0.4.7 vs compression

On Friday 07 January 2011 00:17:37 you wrote:
> I compared Wireshark traces between the two versions and the only
> significant difference I can see (before the server sends a FIN)
> is that with 0.4.7, both the client and server send New Keys requests,
> whereas with 0.4.6, only the server does.
> 
> Before I pursue this further, I'd like to know whether anyone else
> has tested 0.4.7 with compression.

Hi Mark,

could you do a git bisect to find the culprit?

git clone git://git.libssh.org/projects/libssh.git
cd libssh
git checkout -b v0-4 origin/v0-4

git bisect start
git bisect bad
git bisect good release-0-4-7

<build libssh and test>

If it works: git bisect good
If it fails: git bisect bad

It shows you the patch which broke it in ~5 steps.

http://book.git-scm.com/5_finding_issues_-_git_bisect.html

	-- andreas

Mark Riordan | 8 Jan 20:34 2011

RE: libssh 0.4.7 vs compression

Never mind - it was a build error.

Originally I didn't think a problem like this could be caused by a 
build error, but I was wrong.  
I had troubles getting CMake to find ZLIB on Windows, even when I
(allegedly) included the correct zlib paths in FindZLIB.cmake.
I ended up hard-coding some settings in FindZLIB.cmake, and the
resulting DLL did not include support for zlib.
Apparently, however, it did negotiate zlib support, thereby setting
up the failure I observed.

On Linux, FindZLIB.cmake did work correctly, and the resulting
libssh.so did work OK with compression.

Sorry for the false alarm!

/mrr

>> I compared Wireshark traces between the two versions and the only
>> significant difference I can see (before the server sends a FIN)
>> is that with 0.4.7, both the client and server send New Keys requests,
>> whereas with 0.4.6, only the server does.
>> 
>> Before I pursue this further, I'd like to know whether anyone else
>> has tested 0.4.7 with compression.
andreas:
> Hi Mark,
>
> could you do a git bisect to find the culprit?
>
> git clone git://git.libssh.org/projects/libssh.git
> cd libssh
> git checkout -b v0-4 origin/v0-4
>
> git bisect start
> git bisect bad
> git bisect good release-0-4-7
> 
> <build libssh and test>
>
> If it works: git bisect good
> If it fails: git bisect bad
> 
> It shows you the patch which broke it in ~5 steps.
>
> http://book.git-scm.com/5_finding_issues_-_git_bisect.html

Aris Adamantiadis | 8 Jan 20:57 2011
Picon

Re: libssh 0.4.7 vs compression

Good :)
Then I think we can release 0.4.8, we were waiting for your feedback
before doing it.

Thanks,

Aris

Le 08/01/11 20:34, Mark Riordan a écrit :
> Never mind - it was a build error.
> 
> Originally I didn't think a problem like this could be caused by a 
> build error, but I was wrong.  
> I had troubles getting CMake to find ZLIB on Windows, even when I
> (allegedly) included the correct zlib paths in FindZLIB.cmake.
> I ended up hard-coding some settings in FindZLIB.cmake, and the
> resulting DLL did not include support for zlib.
> Apparently, however, it did negotiate zlib support, thereby setting
> up the failure I observed.
> 
> On Linux, FindZLIB.cmake did work correctly, and the resulting
> libssh.so did work OK with compression.
> 
> Sorry for the false alarm!
> 
> /mrr
> 
>>> I compared Wireshark traces between the two versions and the only
>>> significant difference I can see (before the server sends a FIN)
>>> is that with 0.4.7, both the client and server send New Keys requests,
>>> whereas with 0.4.6, only the server does.
>>>
>>> Before I pursue this further, I'd like to know whether anyone else
>>> has tested 0.4.7 with compression.
> andreas:
>> Hi Mark,
>>
>> could you do a git bisect to find the culprit?
>>
>> git clone git://git.libssh.org/projects/libssh.git
>> cd libssh
>> git checkout -b v0-4 origin/v0-4
>>
>> git bisect start
>> git bisect bad
>> git bisect good release-0-4-7
>>
>> <build libssh and test>
>>
>> If it works: git bisect good
>> If it fails: git bisect bad
>>
>> It shows you the patch which broke it in ~5 steps.
>>
>> http://book.git-scm.com/5_finding_issues_-_git_bisect.html
> 
> 
> 
> 

Nikhil Agrawal | 12 Jan 08:08 2011
Picon

Getting mkdir command result

Hi,

I am using libssh to run mkdir on remote machine. In case mkdir fails, I want to receive/get error in my client so i can take measures. I am getting OK as return code in all cases and don’t get to know if mkdir successfully ran or not. Please Suggest.

Thanks!


Rocky Wang | 12 Jan 09:27 2011
Picon

Re: Getting mkdir command result

2011/1/12 Nikhil Agrawal <mrnikhilagrawal@...>:
> Hi,
>
> I am using libssh to run mkdir on remote machine. In case mkdir fails, I
> want to receive/get error in my client so i can take measures. I am getting
> OK as return code in all cases and don’t get to know if mkdir successfully
> ran or not. Please Suggest.
>
> Thanks!
>

hi Nikhil

how about take the return code of the command , and judge if it equals to 0

mkdir: cannot create directory `xxx': File exists
$echo $?
1

Juster.Wang

Aris Adamantiadis | 12 Jan 10:05 2011
Picon

Re: Getting mkdir command result

Le 12/01/11 08:08, Nikhil Agrawal a écrit :
> Hi,
> 
> I am using libssh to run mkdir on remote machine. In case mkdir fails, I
> want to receive/get error in my client so i can take measures. I am
> getting OK as return code in all cases and don’t get to know if mkdir
> successfully ran or not. Please Suggest.
> 
> Thanks!
> 
> 
Hi Nikhil,

I suggest that you check the return code, either using Rocky's method,
or by using ssh_channel_get_exit_status() (you may have to wait that the
channel is closed for this).
You can check in the stderr stream
(ssh_channel_read(channel,dest,len,1); since the error message of mkdir
will be written to stderr and not stdout.

Another solution, that I really advise you use, is to use the sftp
subsystem which has reliable functions to manipulate remote filesystems.

Kind regards,

Aris

Nikhil Agrawal | 12 Jan 10:43 2011
Picon

Re: Getting mkdir command result

When using ssh_channel_request_exec, it always returned success even if mkdir fails and no error identified in ssh_get_error.


But setting stderr to 1 and parsing returned buffer, resolves my problem.

Many Thanks!

Regards,
Nikhil

On Wed, Jan 12, 2011 at 2:35 PM, Aris Adamantiadis <aris-i6OHhdEGaX/VvMwE1J0m0w@public.gmane.org> wrote:
Le 12/01/11 08:08, Nikhil Agrawal a écrit :
> Hi,
>
> I am using libssh to run mkdir on remote machine. In case mkdir fails, I
> want to receive/get error in my client so i can take measures. I am
> getting OK as return code in all cases and don’t get to know if mkdir
> successfully ran or not. Please Suggest.
>
> Thanks!
>
>
Hi Nikhil,

I suggest that you check the return code, either using Rocky's method,
or by using ssh_channel_get_exit_status() (you may have to wait that the
channel is closed for this).
You can check in the stderr stream
(ssh_channel_read(channel,dest,len,1); since the error message of mkdir
will be written to stderr and not stdout.

Another solution, that I really advise you use, is to use the sftp
subsystem which has reliable functions to manipulate remote filesystems.

Kind regards,

Aris



Gmane