-
-
Notifications
You must be signed in to change notification settings - Fork 939
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SshOperationTimeoutException disposing stream for connection that was already terminated by server #335
Comments
Are you sure you are using 2016.1.0 (RTM), and not one of the betas? I fixed an issue in Channel in beta4, and improved robustness even more recently (currently in the develop branch, and will be in the upcoming 2017.0.0-beta1 release). |
I started with beta 5, and then I upgraded to the RTM and saw it there too. There must be something else going on with our setup if you're not seeing it, but I'm not sure what at this time. When I can find some time, I'll try to look into it further. For now, I downgraded to avoid the problem. |
Would it be possible for you to build SSH.NET from source (the develop branch)? I'd really like to fix this issue. |
Thanks for being willing to help out with this. I just downloaded the latest source and was still able to reproduce it. Now what? |
I suppose it's because the (SSH) server does not send a SSH_MSG_CHANNEL_CLOSE message before rebooting. What SSH server are you testing against? See this page for instructions on how you can obtain that info. In previous versions of SSH.NET we were not waiting for the SSH_MSG_CHANNEL_CLOSE message. That explains why you only see this issue with 2016.1.0. I'll add extra tracing to allow us to get more information, and let you know when I've committed these changes. |
SSH-2.0-dropbear_2012.55 |
@JasonQG I cannot reproduce this issue using dropbear version 2013.60. Can you share the minimal code you need to reproduce this issue? Do you get the error consistently, or once every x number of times? |
It happens consistently. There's nothing particularly special about the code. Just a command that resets and then a Dispose(). I suppose maybe the way the system is resetting isn't giving dropbear a chance to send the channel close message maybe? |
Yes, that was indeed was I was thinking. Is it ok if I just add some |
Of course. Please go ahead |
I've added a cwl-tracing branch that - as the name says - adds some When run against OpenSSH_6.6.1p1, I get the following output:
Please provide your exact result. |
This is what I got: [30] Disposing ShellStream. |
@JasonQG This confirms that the server does not always send a SSH_MSG_CHANNEL_CLOSE message before the socket is closed. I'm adding a ChannelCloseTimeout property on ConnectionInfo that allows you to control how long you want to wait for the server to send a SSH_MSG_CHANNEL_CLOSE. The default value is 1 second. |
@JasonQG Please build SSH.NET from the develop branch, and confirm that this fixes the problem for you. You can use the ChannelCloseTimeout to reduce or remove the wait completely when closing the channel. |
Confirmed that this fixes it for me. Thanks! |
Any idea when this fix will land in stable release? |
Hi, Any help from anyone who faced similar issue earlier and solved it would be greatly appreciated. Thanks and Regards, |
@drieseng I get same error. However, it happens when Shell stream is open and also it happens inconsistently. I am posting in this thread to know if it could be a similar issue and that upgrading to 2020.0.0-beta1 would be worth an effort? I am on v2016.1.0 integrated into a .NET Standard 2.0 library
Thank you! Cheers |
Since upgrading to 2016.1.0, I'm getting the below exception. Right before the stream was disposed, a command was sent to reboot the server, thus terminating the SSH connection on the server side. The same code worked with 2016.0.0.
The text was updated successfully, but these errors were encountered: