In the situation where a port forward has been established and actively used, therefore a listener thread has been created, if the network is disconnected (by pulling out the cable) and reconnected sometime later then the internal thread will remain there even after everything else has been disposed properly. This causes problems, especially when trying to exit the application since it will hang.
With a fair amount of Console.WriteLineing it was established that the internal listener thread, consisting mostly of the Bind function in ChannelDirectTcpip, eventually exits its main loop correctly but then stalls at this point forever (well at least until a kill -9 is issued):
```
System.Threading.WaitHandle.WaitAny(new WaitHandle[] { this._channelEof });
```
I do not know much about the inner workings of SSH.NET and therefore do not know the best solution to the problem, but a workaround that seems to do the job for us is to simply allow that wait to timeout:
```
System.Threading.WaitHandle.WaitAny(new WaitHandle[] { this._channelEof }, 5000);
```
After that, the inner thread exits properly and no more hangs on exit.
Comments: ** Comment from web user: teadriven **
Hi,
I wasn't suggesting the timeout as a solution, it was simply a hack to get it working for us in the meantime since our application should only be run on a local network for the now and therefore 5 seconds is reasonable.
I pulled down the source for 23481 and copied a build of the library over to my test bed (a server and a client VM, both linux, with simulated network cable disconnections to test the ability to maintain a tunnel).
Unfortunately there is still a runaway thread that causes the processor usage to ramp up when exiting the application.
Another similar effect is that the IsConnected property blocks for a very long time if the network cable is disconnected (it does not honour the ConnectionInfo.Timeout value). To help with that situation we have to launch a Task to check the connection and attempt a reconnect which means I can then Wait on the Task with a sensible timeout (yet another hack I'm afraid).
Regards,
Dan