Build 808: Error with tab close button.

[jad]

I've encountered something new in Build 808...although I cannot say whether it is new or existed in B1 and B2 as I did not try this scenario with the prior betas.

While working with one of our console servers, I had previously opened multiple tabs of different connections. One of the new tabs was a connection to a specific port the console server, whose username includes the port name to which we are connecting (e.g. root:portname).

My default window titlebar setting is "%s (%u@%h:%p)" which will give me a tab name such as "Consoles (root:portname@conserver:22)". Exiting from the port is simply done by closing the connection, so I clicked on the red X button in the tab bar to close the tab.

The connection did not close, and I was subsequently prevented from interacting with that tab in any way. All I/O was ignored, and no commands (disconnect, close) were honored. Yet the connection was still open as verified by the console server in another tab. All other tabs are unaffected by the frozen tab.

This only occurs if I try to close or disconnect tabs that were logged in with SSH with the username such as the above (username:portname). Other tabs are not affected by this bug. Any further information necessary in debugging this problem can be provided upon request.


Cheers,
Jason

[Maureen]

Thanks for reporting this. I'm having trouble reproducing the behavior you described. Could you please send your session .INI file to me at Maureen.Jett@vandyke.com. It also might be helpful to see what the trace ouput says. To turn on trace output, select "Trace Options" from the File menu before connecting.

Maureen

[jad]

Here is the output from the trace:

SecureCRT - Version 5.0.0 (build 808)
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT.
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = "SSH-1.99-OpenSSH_3.6.1p2 - code level 3.7.1p1"
[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] : GSS : Requesting full delegation
[LOCAL] : GSS : [Kerberos] SPN : host@labcon1.appl.ge.com
[LOCAL] : GSS : [Kerberos] Disabling gss mechanism
[LOCAL] : GSS : [Kerberos] InitializeSecurityContext() failed.
[LOCAL] : GSS : [Kerberos] No authority could be contacted for authentication.
[LOCAL] : SEND : KEXINIT
[LOCAL] : RECV : Read kexinit
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE.
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
[LOCAL] : Selected Kex Method = diffie-hellman-group-exchange-sha1
[LOCAL] : Available Remote Host Key Algos = ssh-rsa,ssh-dss
[LOCAL] : Selected Host Key Algo = ssh-dss
[LOCAL] : Available Remote Send Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Send Cipher = aes256-cbc
[LOCAL] : Available Remote Recv Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Recv Cipher = aes256-cbc
[LOCAL] : Available Remote Send Macs = hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Send Mac = hmac-sha1
[LOCAL] : Available Remote Recv Macs = hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Recv Mac = hmac-sha1
[LOCAL] : Available Remote Compressors = none
[LOCAL] : Selected Compressor = none
[LOCAL] : Available Remote Decompressors = none
[LOCAL] : Selected Decompressor = none
[LOCAL] : SEND : KEXDH_GEX_REQUEST
[LOCAL] : RECV : KEXDH_GEX_GROUP
[LOCAL] : RECV : DH Prime is 1535 bits
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : RECV : KEXDH_REPLY
[LOCAL] : SEND : NEWKEYS
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_EXPECT_NEWKEYS.
[LOCAL] : RECV : NEWKEYS
[LOCAL] : Changing state from STATE_EXPECT_NEWKEYS to STATE_CONNECTION.
[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth]
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : SENT : USERAUTH_REQUEST [none]
[LOCAL] : RECV : AUTH_SUCCESS
[LOCAL] : SEND: Pty Request (row: 60, col: 132)
[LOCAL] : RECV: pty request succeeded
[LOCAL] : SEND: x11 forwarding request
[LOCAL] : RECV: x11 request failed
[LOCAL] : SEND: agent forwarding request
[LOCAL] : RECV: agent request succeeded
[LOCAL] : SEND: shell request
[LOCAL] : RECV: shell request succeeded

The session is a simple SSH2 connect. Username is username:portname, in this case root:ttyS1. I cannot provide raw session logs as my test scenario produces no output, and the raw log contains nothing. However, as soon as I hit the tab close button, I get the following in my syslog on the far end server:

Mar 28 11:32:06 src_dev_log@labcon1 sshd[620]: error: channel 0: chan_shutdown_read: shutdown() failed for fd7 [i0 o1]: Socket operation on non-socket

It may not be much, but it is at least something to go on. The far end server is OpenSSH 3.8.x on the Cyclades Alterpath console servers.


Cheers,
Jason

[duaner]

"Build 808" ? Is there I new beta out?
(I don't see it on the "Beta build numbers" post nor anything new on the download page, http://vandyke.com/download/securecrt/beta.html ).

[jad]

It is an interim build I've been testing in response to several of the issues I and others raised here in the forum.

Cheers,
Jason

[jad]

I've installed B3. This issue is still occurring. I'm not certain it is a purely Van Dyke issue given the trace output above from the server in question (particularly about trying to make a close_socket call on a file handle), but SCRT's response (i.e. not disconnecting when asked and apparently being stuck in some reponse-wait loop) might be something to look at.