VanDyke Software Forums

VanDyke Software Forums (https://forums.vandyke.com/index.php)
-   SecureCRT on the Mac (https://forums.vandyke.com/forumdisplay.php?f=24)
-   -   Session does not close/disconnect immediately when network interrupted (https://forums.vandyke.com/showthread.php?t=14410)

mfatty 01-29-2021 03:17 PM

Session does not close/disconnect immediately when network interrupted
 
Let's say I have a few ssh sessions going.


Then my internet dies for a minute or my VPN disconnects or something.
SecureCRT still shows green check mark that denotes connected. But really, it's not connected because the network is down. SecureCRT has not detected that the ssh session broken. I cannot interact with the device anymore. So yes, ssh session is broken as expected. But securecrt has not closed/disconnected from the session. I don't mean close the tab/window, I mean close the TCP connection because there is no internet.


If I wait for a while, let's say after 5 minutes or so, SecureCRT will eventually detect the network interruption and disconnect/close automatically. But why does it take so long?


If I don't want to wait for 5 minutes for SecureCRT to autodetect interruption, I manually disconnect the ssh session (right click, disconnect). And then try re-connecting. Then it takes a couple of minutes trying to connect. Then reports something "Could not connect to Firewall". I think it's saying could not connect to my jumphost. Then I click on Enter and it immediately connects.



This is very disturbing because it happens quite often. Every day when I have network interruptions.



Version 8.7.3 (build 2279)
p, li { white-space: pre-wrap; }

jdev 01-29-2021 03:45 PM

Hello mfatty,

If SecureCRT doesn't reflect a network disconnect in the status of an open tab/tile/connection, it is because the operating system's TCP/IP stack hasn't yet provided SecureCRT with any notification of the connection having gone down.

If you want to accelerate the ability to have a downed connection be detected more quickly in SecureCRT, open your session options, navigate to the Terminal category and enable the anti-idle Send protocol NO-OP option; specify how many seconds you'd like to wait at a minimum.
Note that when the connection is good, this will mean that SecureCRT will be sending packets unnecessarily, but if you don't want SecureCRT to be beholden to notifications from the operating system, this one way to work around the OS failing to provide timely notification of a TCP connection having gone down.
Make this change to both your jump host session and other sessions and see how well things work for you.

Let us know what you discover.

--Jake


All times are GMT -6. The time now is 12:01 PM.