The semaphore timeout period has expired !

[Dhawi]

Hi,

I have an issue where i am not able to connect using SSH to a remote device

I can telnet port 22 and it is open and i can connect to device GUI console on different port and it is working

i check previous posts on this forum but non of them helped me

[LOCAL] : SSH2Core version 7.3.0.1034
[LOCAL] : Connecting to x.x.x.x:22 ...
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
SecureCRT - Version 7.3.7 (x64 build 1034)
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = 'SSH-2.0-OpenSSH_5.3'
[LOCAL] : CAP : Remote can re-key
[LOCAL] : CAP : Remote sends language in password change requests
[LOCAL] : CAP : Remote sends algorithm name in PK_OK packets
[LOCAL] : CAP : Remote sends algorithm name in public key packets
[LOCAL] : CAP : Remote sends algorithm name in signatures
[LOCAL] : CAP : Remote sends error text in open failure packets
[LOCAL] : CAP : Remote sends name in service accept packets
[LOCAL] : CAP : Remote includes port number in x11 open packets
[LOCAL] : CAP : Remote uses 160 bit keys for SHA1 MAC
[LOCAL] : CAP : Remote supports new diffie-hellman group exchange messages
[LOCAL] : CAP : Remote correctly handles unknown SFTP extensions
[LOCAL] : CAP : Remote correctly encodes OID for gssapi
[LOCAL] : CAP : Remote correctly uses connected addresses in forwarded-tcpip requests
[LOCAL] : CAP : Remote can do SFTP version 4
[LOCAL] : CAP : Remote x.509v3 uses ASN.1 encoding for DSA signatures
[LOCAL] : CAP : Remote correctly handles zlib@openssh.com
[LOCAL] : SEND : KEXINIT
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_CLOSED
[LOCAL] : Connected for 18 seconds, 0 bytes sent, 21 bytes received

[LOCAL] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : The semaphore timeout period has expired.

The semaphore timeout period has expired.

[berdmann]

Hi Dhawi,

The "semaphore timeout period has expired" error is a generic network error, and usually indicates a problem with the machine that SecureCRT is running on or a problem with the machine's network configuration.

Individuals seeing this problem indicated that the problems were related to one or more of the following issues:

- DHCP assigning network addresses (some resolved by going static).
- Slow networks.
- Sometimes disc problems, or file retrieval problems.
- Reports of port scanners or other network security tools probing the network.
- Difficulty connecting to specific ports on a non-loopback network interface.
- Wireless networks.

This issue cannot be resolved in SecureCRT. I recommend reaching out to your network administrators to troubleshoot this behavior further.

[gregg]

I feel like I'm seeing this "The semaphore timeout period has expired." frequently since upgrading.

I'm having difficulty narrowing down the issue because I was previously running WinXP and whatever sCRT was max for that OS and basically never got this semaphore disconnect. I pretty much leave my sessions open 24x7 for months.

Finally wanting the new sCRT features (yay paste dialog!), I upgraded (rebuilt) the jump box to Win7 x64 (VM on ESXI 6.5.0) and also put a recent 64bit version of sCRT on there (currently 8.5.3).

The interesting thing is, not all active sessions get this semaphore disconnect, in fact, connections to the _same_ host remain active and open, while other tabs to same host get disconnected (my guess is cloned sessions are all the disconnected ones). Typically overnight and I come back in the morning and have to reconnect several sessions.

It's a wired connection, and everything is over the same vpn.

Not always, maybe a couple times a week.

Anyway, it probably "is me, not you" but just not sure where to poke.

[berdmann]

Hi Gregg,

The error you are seeing is coming to SecureCRT from the operating system's networking system. It's notifying SecureCRT that there was a problem with the connection.

Unfortunately, SecureCRT cannot force the system to not report this error; nor can SecureCRT force the connection to remain open or otherwise coerce the network connection to behave itself. SecureCRT is simply notified that the connection was closed, and the reason given to SecureCRT is as earlier noted.

Because this error is merely *reported to* SecureCRT (instead of being *generated by* SecureCRT), you will need to engage in troubleshooting the cause of this error in places outside of SecureCRT's immediate control.

[Dhawi]

Originally Posted by Dhawi

Hi,

I have an issue where i am not able to connect using SSH to a remote device

I can telnet port 22 and it is open and i can connect to device GUI console on different port and it is working

i check previous posts on this forum but non of them helped me

[LOCAL] : SSH2Core version 7.3.0.1034
[LOCAL] : Connecting to x.x.x.x:22 ...
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
SecureCRT - Version 7.3.7 (x64 build 1034)
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = 'SSH-2.0-OpenSSH_5.3'
[LOCAL] : CAP : Remote can re-key
[LOCAL] : CAP : Remote sends language in password change requests
[LOCAL] : CAP : Remote sends algorithm name in PK_OK packets
[LOCAL] : CAP : Remote sends algorithm name in public key packets
[LOCAL] : CAP : Remote sends algorithm name in signatures
[LOCAL] : CAP : Remote sends error text in open failure packets
[LOCAL] : CAP : Remote sends name in service accept packets
[LOCAL] : CAP : Remote includes port number in x11 open packets
[LOCAL] : CAP : Remote uses 160 bit keys for SHA1 MAC
[LOCAL] : CAP : Remote supports new diffie-hellman group exchange messages
[LOCAL] : CAP : Remote correctly handles unknown SFTP extensions
[LOCAL] : CAP : Remote correctly encodes OID for gssapi
[LOCAL] : CAP : Remote correctly uses connected addresses in forwarded-tcpip requests
[LOCAL] : CAP : Remote can do SFTP version 4
[LOCAL] : CAP : Remote x.509v3 uses ASN.1 encoding for DSA signatures
[LOCAL] : CAP : Remote correctly handles zlib@openssh.com
[LOCAL] : SEND : KEXINIT
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_CLOSED
[LOCAL] : Connected for 18 seconds, 0 bytes sent, 21 bytes received

[LOCAL] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : The semaphore timeout period has expired.

The semaphore timeout period has expired.

issue fixed and it was due to firewall (application control which was blocking SSH).