Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > Secure Shell

Reply
 
Thread Tools Display Modes
  #1  
Old 04-29-2019, 06:00 AM
Dhawi Dhawi is offline
Registered User
 
Join Date: Apr 2019
Posts: 2
The semaphore timeout period has expired !

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.
Reply With Quote
  #2  
Old 04-29-2019, 12:30 PM
berdmann berdmann is offline
VanDyke Technical Support
 
Join Date: Aug 2017
Posts: 255
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.
__________________
Thanks,
--Brittney

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #3  
Old 08-27-2019, 10:18 AM
gregg gregg is offline
Registered User
 
Join Date: Oct 2010
Posts: 53
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.

Last edited by gregg; 08-27-2019 at 10:21 AM. Reason: embelishments
Reply With Quote
  #4  
Old 08-27-2019, 12:50 PM
berdmann berdmann is offline
VanDyke Technical Support
 
Join Date: Aug 2017
Posts: 255
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.
__________________
Thanks,
--Brittney

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #5  
Old 11-08-2019, 04:18 AM
Dhawi Dhawi is offline
Registered User
 
Join Date: Apr 2019
Posts: 2
Quote:
Originally Posted by Dhawi View Post
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).
Reply With Quote
Reply

Tags
semaphore , timeout


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 10:49 PM.