I replaced my laptop with a faster Windows 7 (32bit) machine I re-installed ABST 9.18.
I noticed when opening a session/connection to all my machines (Solaris, linux ssh2) it is noticably slower than on my old laptop with XP. I see messages on the ABST screen ending in "Success" , the lower
bottom right of the window has "Connecting..." There is a pause here that I didn't seem to have
with XP. I connect just fine after this and the software works great.
Has anyone else found a slow pause when connecting with Windows 7 that's wasn't there in XP?
I suspect maybe ABST has to load a DLL or something but its all connections..not just the first session/terminal one opens.
Thanks for any info...Absolute Telnet still rocks.
RM in NJ
I have a similar problem that started with the latest Windows Updates that were released on 2012-01-13 (did you replace your laptop before this date?)
Before the patches were applied all was well with AT 9.18 but no I have slowdowns and tunneling is close to useless... I'll see if I dare uninstalling the latest patches to see which KB is the culprit.
/msa
The pause or delay on Windows 7 seemed to be from when I installed ABS 9.18 on Windows7..it
was priori to 12-01-2011.
I'll check an sftp tranfer rate but as it is now I did not notice any slow down in my X tunneling or
terminals. The pause seems to be just when I go open a terminal/session. It's like on Windows
7 its doing soemthing extra during this connection phase.
I've seen delays introduce on the unix side related to X11 authentication and X11 forwarding. Check Options->Properties->Connection->SSH2->Forwarding. Turn off 'display remote X......' if you have it enabled.
If that doesn't work, turn off each of the forwarding options 'authentication agent forwarding', 'dynamic forwarding' to see where the delay may be introduced.
Let me know what you find out.
Those are reasonable suggestions ...let me give it a try to see if it helps. Only problem I forsee is
for many of the systems I need the tunnel X.
I'm not suggesting that turning off X forwarding is the ultimate solution, just a means to help narrow down what the problem is.
I have a linux system that exhibits a pause during login for one specific user. However, it is a result of a server condition where during the login process, a lock is attempted on the .Xauthority process prior to the start of the shell. When the lock cannot be achieved, the attempt eventually times out and the login proceeds. It is not a client-initiated wait, but rather a server-initiated one.
Identifying the cause of the wait will help you identify what your ultimate solution will be.
Being able to run sshd on the server in debug mode would aid in identifying the solution as well.
Brian
Nope turning off all those things made no difference.. I login...I see on the screen:
Connecting to 10.x.x.x:22
attempting 10.x.x.x:22... Success!
about 5-6 seconds go by..
Then I get my login box. On XP the login box appears instantaenously.
I turned the trace...after 5-6 seconds the following appears on the screen (with the login box poping up): (data all truncated for this posting)
SSH - PacketDecoder RECEIVED: 5353482D322E302D4F70656E5353485F352E310D0A
SSH - Sending version: 5353482D322E302D312E3831207373686C69623A204162736F6C75746554656C6E65740D0A
SSH - calling SetOutVersion
SSH - OutState is READY_TO_SEND_KEXINIT
SSH - PrepareKexPacket
SSH - supported kex algs
SSH - diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
SSH - supported hostkey algs
SSH - ssh-rsa,ssh-dss
SSH - supported encryption algs
SSH - aes256-cbc,aes128-cbc,3des-cbc
SSH - supported mac algs
SSH - hmac-sha1
SSH - supported compression algs
SSH - none,zlib@openssh.com,zlib
SSH - MessageEnd
SSH - Sending SSH_MSG_KEXINIT (296 bytes, seq nr 0)
Data: 147F7C0F244E3B37E7250737B74BE52333000000596469666669652D68656C6C6D616E2D67726F757
..
E7373682E636F6D2C7A6C69620000001A6E6F6E652C7A6C6962406F70656E7373682E636F6D2C7A6C696200000000000000000000000000
SSH - SetOutKexInitPacketSent
SSH - OutState is DOING_OUT_KEX
SSH - PacketDecoder RECEIVED: 0000030C0A142C28B002E829E45D56B957D846675C000000007E6469666669652D68656C6C6D616E2D67726F75702D65786368616E67652D7368613235362C6469666669652D68656C6C6D616E2D67726F75702D65786368616E67652D736861312C6469666669652D68656C6C6D616E2D67726F75703134....
6C6962406F70656E7373682E636F6D000000156E6F6E652C7A6C6962406F70656E7373682E636F6D0000000000000000000000000000000000000000000000
SSH - Received SSH_MSG_KEXINIT (769 bytes, seq nr 0)
Data: 142C28B002E829E45D56B957D846675C000000007E6469666669652D68656C6C6D616E2D67726F75702D65786368616E67652D7368613235362C6469666669652D68656C6C6D616E2D67726F75702D65786368616E67652D736861312C6469666669652D68656C6C6D616E2D67726F757031342D736861312C6469666669652D68656C6C6D616E2D67726F7570312D736861310000000F7373682D7273612C73
...
656E7373682E636F6D000000156E6F6E652C7A6C6962406F70656E7373682E636F6D00000000000000000000000000
SSH - Will act on first key exchange method packet
SSH - Sending SSH_MSG_KEX_30 (261 bytes, seq nr 1)
Data: 1E000001005037924EB6CD5393D5C5666BFD821B3F1C9BAD4A84D5B38B59F9B9C06B713100763FF13F139967B4211EBDD350FA738EFE3805268517DACF95F2F628D046F52AA5757B627598AD397FEF0EDD9769129424210649CE2C36D755EAC597CD6F0EC1BF9E22956AB097AE5418990DAAE9C2AE4B7B9DE7F63C15A4E065AB853EB741C348E5D12B4954F667950AA22F46CF260DD43D787872B8FD8D49C0966ED188FE881E0EE17097B56E96AE8E4BD85C3118D6
SSH - PacketDecoder RECEIVED: 0000023C0A1F00000095000000077373682D72736100000001230000008100AF7425BA1312F909CB680F93724C3C7DBE00C2B2AE7CE15F69B96C88FAC558E424EC8B17150B1F402A0A02E1640580AE6EE3DBD82A8DA00A712DE0117A3A2424B478EBD3194D175392E93BE1EB1046EBBAA45D50B0E59849BDBB106004A2A8F3F5FA96576F7B0E445DC0DDC6650EFA69A82F9AC8444C9F5C1E5E24F75DE6CFB3B0FFD8D541B16000000000000000000000000000C0A1500000000000000000000
SSH - Received SSH_MSG_KEX_31 (561 bytes, seq nr 1)
Data: 1F00000095000000077373682D72736100000001230000008100AF7425BA1312F909CB680F93724C3C7DBE00C2B2AE7CE15F69B96C88FAC558E424EC8B17150B1F402A0A02E1640580AE6EE3DBD82A8DA00A712DE0117A3A2424B478EBD3194D175392E93BE1EB1046EBBAA45D50B0E59849BD8F7003DD4A2A8F3F5FA96576F7B0E445DC0DDC6650EFA69A82F9AC8444C9F5C1E5E24F75DE6CFB3B0FFD8D541B16
SSH - Sending SSH_MSG_NEWKEYS (1 bytes, seq nr 2)
Data: 15
SSH - Sending SSH_MSG_SERVICE_REQUEST (17 bytes, seq nr 3)
Data: 050000000C7373682D7573657261757468
SSH - Received SSH_MSG_NEWKEYS (1 bytes, seq nr 2)
Data: 15
SSH - PacketDecoder RECEIVED: 960FB2BAA7C8B23E981DD545DE533C55117DB940FE3D8DCF9E55731D8E76F3512DBB09002022EDE6B104E29A2A6288D481557465
SSH - Received SSH_MSG_SERVICE_ACCEPT (17 bytes, seq nr 3)
Data: 060000000C7373682D7573657261757468
SSH - Sending SSH_MSG_DISCONNECT (24 bytes, seq nr 4)
Data: 010000000B0000000955736572206578697400000002656E
This is a faster notebook than one it replaced that ran XP.. the software all work..just can't figure out the annoying pause.
BTW: I tried some sftp transfers and the speeds are really fast... no connection slowdowns.
Here's a basic debug on the server side if I run a debug sshd on another port. The trace ends when my login window
pops up..
/usr/lib/ssh/sshd -d -D -p 1234
debug1: sshd version Sun_SSH_1.1.3
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 1234 on ::.
Server listening on :: port 1234.
debug1: Server will not fork when running in debugging mode.
Connection from 10.x.x.x port 52944
debug1: Client protocol version 2.0; client software version 1.81 sshlib: AbsoluteTelnet
debug1: no match: 1.81 sshlib: AbsoluteTelnet
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.3
monitor debug1: list_hostkey_types: ssh-rsa,ssh-dss
monitor debug1: reading the context from the child
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-cbc hmac-sha1 none
debug1: kex: server->client aes256-cbc hmac-sha1 none
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: en-CA,en-US,es,es-MX,fr,fr-CA,i-default
debug1: We proposed langtags, stoc: en-CA,en-US,es,es-MX,fr,fr-CA,i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 249/512
debug1: bits set: 1602/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1587/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
Good info, but it's hard for me to know what's going on with the server side unless you can tell me where (from the server point of view) the pause is. Another thing I'd like you to try is the newest version, just to make sure this hasn't been addressed already:
<old link removed> Please download version 9.48 or newer.
Brian
I tried the new version 9.48. Two problems..
1.) I had to use a demo license...My professional license apparently is too old to upgrade and work with
a newer version (jan 2010).
2.) The 9.48 version does not our of the box.. when logging in... I get the error:
"All configured authentication methods have failed."
If I configure it for keyboard-interactive login (this is Solaris 10 I'm logging into) I get a passord prompt
in the terminal.. typing here lets me in.
There is still a 5-6 second pause before the password prompt comes up (the terminal says connecting... in the
lower right for 5-6 seconds). The problem is still there.
Do you have any update on this?
I have not been able to reproduce.
Brian
Yes, a long pause still when logging into Suse Linux and Solaris 9 and 10 machines. It could be my PC , a dual core T500,
but I have only my a desktop running XP to compare it to. I've just learned to live with it.
-- sorry, wrong thread --
I'm still having this issue. I'm on the latest 9.49 pro, Win7 machine. telnet worked fine prior to my upgrade, now I have the long pause, which is rather annoying since it worked before.
Previous version was on the same machine. kind of frustrating in all honesty.
This problem has been solved. Try this:
<old link removed> Please download version 9.49 or newer.
Brian
