This project is read-only.

Possible bug discovered

May 27, 2012 at 12:29 AM
Edited May 27, 2012 at 1:06 AM

Hi to all and congratulations to developer for this great library.
In my C# application I runs a small server with the only purpose to redirect traffic to an OpenSSH server located in a portable device.
If I connect to this forwarding server from another application, the connection succeds.
If I try to connect on the same application where the server is running, the connection fails and SSH.NET returns "An existing connection was forcibly closed by the remote host" (connectionReset).

The connection appear to drop after SSH_MSG_NEWKEYS:

SshNet.Logging Verbose: 1 : Initiating connect to '127.0.0.1:22'.
SshNet.Logging Verbose: 1 : Server version '2.0' on 'OpenSSH_5.8'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'KeyExchangeInitMessage': 'SSH_MSG_KEXINIT'.
SshNet.Logging Verbose: 1 : SendMessage to server 'KeyExchangeInitMessage': 'SSH_MSG_KEXINIT'.
SshNet.Logging Verbose: 1 : SendMessage to server 'KeyExchangeDhGroupExchangeRequest': 'SSH_MSG_KEX_DH_GEX_REQUEST'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'KeyExchangeDhGroupExchangeGroup': 'SSH_MSG_KEX_DH_GEX_GROUP'.
SshNet.Logging Verbose: 1 : SendMessage to server 'KeyExchangeDhGroupExchangeInit': 'SSH_MSG_KEX_DH_GEX_INIT'.
SshNet.Logging Verbose: 1 : ReceiveMessage from server: 'KeyExchangeDhGroupExchangeReply': 'SSH_MSG_KEX_DH_GEX_REPLY'.
The thread '<No Name>' (0x12d0) has exited with code 0 (0x0).
The thread '<No Name>' (0xe60) has exited with code 0 (0x0).
SshNet.Logging Verbose: 1 : SendMessage to server 'NewKeysMessage': 'SSH_MSG_NEWKEYS'.
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in System.dll
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in Renci.SshNet.dll
The thread '<No Name>' (0x1030) has exited with code 0 (0x0).
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in Renci.SshNet.dll

Looking at the code I have seen that the exception occurs in the "WaitHandle" routine where the returned index is zero.

Well, initially I was pretty sure that there was something wrong with my server, but, with my big suprise, I was able to succesfully connect with two different commercial libraries (chilkat and WeOnlyDoSSH).
It is clear now that there's something wrong in how SSH.NET handles the connection when it connect to a server running on the same domain.
I'm not sure if this could be the cause of the problem, but I noticed that SSH.NET, during the connection phase, sends a double amount of data respect to others libraries.
This happen also with AES128 as algorithm.
Could be that the server decide to close the connection after realizing that the client continues to send lots of data?
Is this the normal behaviour also with file transfers? I ask this because some users in the forum were reporting very slow transfers compared to other libraries.
Anyway, I never trusted the system.threading syncronization context and I'm pretty sure that it can easily generate this kind of problems. If you accepts suggestions on improvements, my suggestion is to totally remove this pattern and let do the job directly to the socket class which already handle everything related to timeout, async patterns and everything else.

What's I really don't understand is why the connection succeds if server and client are located in two different applications.

Maybe I just need to configure something and that I don't have any problem with other libraries because they do this under the hood ?

Thanks