I'm not sure if this is the same issue as [here](http://sshnet.codeplex.com/workitem/1436).
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 **
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 **
Oleg,
I'm afraid the 23468 build does not appear to deal with physical disconnects any differently. The IsConnected property still blocks and the tunnels still leave behind threads.
Regards,
Dan