Several patches to fix serious bugs are now available for download

Jun 4, 2012 at 7:55 PM

Hi to all,

for anyone interested, I've just uploaded several patches in the source code section. Those patches fixes several bugs of the library.I've decided to open this thread to let know the users this news since I'm not sure this project is still active (I only see unanswered threads).


Thanks to all

Coordinator
Jun 5, 2012 at 8:32 PM

Hi,

 

Thanks for submitting patches,

 

I was on vacation for past 3 weeks and didn't have an ability to answer any questions.

 

I will try to integrate them as soon as I can, hopefully by the end of the week.

Meanwhile I have a question, which patches I should consider, and are any of submitted patches contain previously submitted, as you mentioned in one of them?

 

Thanks,

Oleg

Jun 6, 2012 at 1:17 PM

Hi Oleg,

nice to see you. I hope you enjoyed your vacation.


Patch 12352 should be deleted because not working.

The following two patches should be applied:

12353

- in the SocketConnect method, after the EndConnect method, I added some validation code to determine whether the socket is still connected or not. If no data is available within 2 seconds, an exception is raised. (*)

- In the SocketReadLine method, if the server returns zero, it starts an infinite loop. To fix that, I have replaced all of the code of this method with a single call to the "NetworkStream.ReadLine" which already handle in an excellent way the reading of lines from a provided stream. It is also supposed to be faster because does not read a byte at a time like was doing the old method (plus all the additional checks).

12338

- IsConnected property returns always true even when the socket is disconnected.I added a further check which check whether the server is still connected or not. (*)

(*) This methods are only reliable when the server close/reset/terminate the connection "gracefully". Unplugged network/power cable won't be noticed. Making a nonblocking, zero-byte Send call is the preferred method because detect any kind of disconnection. I originally tried this implementation, but without success. Maybe unlike me you are able to implement this technique?

 

There are a few questions I would like to make:

1- I have seen that the library has an ASCIIEncoding class. Is there a particular reason on why you didn't use the already excellent ascii encoding available in the framework?

2-There are situations where an user (like me for example) only connects to a lan ssh server and don't need security but pure performance. I tried to implement the arcfour cipher (which appear to be the faster one), but the new version of the library stores all of the ciphers in the new CipherInfo class which requires the CipherMode (not supported from the Arcfour encrytion). 
Thanks

Coordinator
Jun 6, 2012 at 1:36 PM

Hi,

 

1. Yes, the reason for this class was to provide multiplatform support. Silverlight and WindowsPhone does not have this class available in there CLR so wanted to come up with something common for all environment without many #IF statements in the code.

2. I would like to implement more cipher algorithms but dont have much time for it now :( if you can make it somehow to work, feel free to give me the code and I will try to integrate it into library so it will work well with other classes.

 

I actually also have a question.

in 12353 patch.

Why do you want to check if its connecting immidiatly after it was trying to connect.

My thought of behaviour was, if it connects of fails to connect at this point then fine, then,lets say it connects but then drops the connection, then very next network operation, such as read or write, will throw system exception.

So you should always get some kind of exception if connection drops.

 

Thanks,

Oleg

Jun 6, 2012 at 4:37 PM

I understand. That's a great choice for multi platform support. I think that the performance in Windows may be better with its own class, but too many #if statements could eat the time gained from a faster encoding. You made the right decision, but if there are many other classes implemented only for multi platform support, you should consider to build two different binaries.

I think that right now the arcfour is the most needed cipher in matter of performance. Looking at the following benchmark, arcfour appear to be a much more faster alghorithm compared to blowfish (the faster one supported from ssh.net).

The arcfour alghorith is very easy and below you can see a primitive implementation:

Byte[] Key = { 25, 64, 1, 45, 54, 45 };
Byte[] Content = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

// encrypt
RC4(ref Content, Key);

// decrypt
RC4(ref Content, Key);


public void RC4(ref Byte[] bytes, Byte[] key)
{
    Byte[] s = new Byte[256];
    Byte[] k = new Byte[256];
    Byte temp;
    int i, j;

    for (i = 0; i < 256; i++)
    {
        s[i] = (Byte)i;
        k[i] = key[i % key.GetLength(0)];
    }

    j = 0;
    for (i = 0; i < 256; i++)
    {
        j = (j + s[i] + k[i]) % 256;
        temp = s[i];
        s[i] = s[j];
        s[j] = temp;
    }

    i = j = 0;
    for (int x = 0; x < bytes.GetLength(0); x++)
    {
        i = (i + 1) % 256;
        j = (j + s[i]) % 256;
        temp = s[i];
        s[i] = s[j];
        s[j] = temp;
        int t = (s[i] + s[j]) % 256;
        bytes[x] ^= s[t];
    }
}

The main problem is that I don't know how to integrate it into the CipherInfo class because this class is developed to work only with alghoritms which support cipher mode.

Regarding your question related to patch 12353, the main reason was to differentiate between a server that closed the connection and a server that is still connected but didn't returned any data. When you check the server string you trow the "The server string is null" message which don't says what's really happened. But you're right, at this point if the connection failed, we really don't need to know if the server is still alive or not. We could just change the exception message with something more appropriate like "Unable to connect: the server does not respond.".

Thanks