Zugg Software :: View topic - [3.06] SSH and Telnet connection delays/application freeze

Posted: Tue Apr 28, 2009 11:32 pm

I mentioned this in a previous post (here), but I thought I would bring it up again because it seems important.

I am testing TeSSH out in my work environment, and anytime I open a telnet or SSH session towards other machines I get a 10 to 20 second delay before it will complete the connection. I believe you mentioned in the other thread that it was an SSH negotiation problem, but telnet has the same problem in my case.

- With telnet, it doesn't prompt me for my login user/pass until after the delay.
- With SSH, the popup window allows me to enter the user/pass as normal before trying to connect and hitting the delay.

I saw these same problems when connecting to a Solaris system as well as Win2k, Win2003, and WinXP (and even when telnetting into a serial port server).

I hope we can solve this because I just can't use TeSSH with this problem (and I really really want to). I open many connections to different systems regularly, and the delay is killer.

Note: I haven't seen any other telnet/ssh clients have this problem running from the same system and connecting to the same locations.

Edit: In case the extra detail is useful -- I just realized I also do get a printout with the remote system's "Authorized use only etc etc etc.." warning message *before* I hit the delay and application freeze when I connect to the Solaris server (the other machines don't have any such message usually). That message prints before the login prompt.

Posted: Wed Apr 29, 2009 8:10 pm

Posted: Fri Sep 11, 2009 7:59 pm

Sorry I vanished for so long without replying -- got busy at work and forgot about trying to use TeSSH again until recently.

Our security policies at work won't allow me to give you any access to our systems here, so I ran a couple tests while running wireshark to capture the packets while trying to telnet into another system.

I am sending the .pcap files (can view with Wireshark) to sales@zuggsoft.com. There are two files, one log while using TeSSH, and another while using Putty.

Comments about the capture logs:

It seems that packets 11 and 12 with Putty are equivalent to packets 10 and 11 with TeSSH (where the "login name:" prompt is transmitted).

At this point, I can start typing the login credentials immediately with Putty, but I have a ~20 second delay with TeSSH where the entire application is frozen. Also the "login name:" prompt (and all the other text from earlier packets) is not yet printed to the output window.

It appears that TeSSH is expecting something and hangs until it either receives it or after a timeout delay, but I'm just guessing here.

After the 20 second delay, 4 more packets are sent/received and then the "login name:" prompt is finally displayed and I can begin typing to log in.

The test here is using telnet, but I see the same problem with SSH.

Posted: Mon Sep 14, 2009 4:42 pm

Thanks for sending the capture logs. I received them in email. I'll need to get the WireShark program in order to read them.

It's interesting that you said that the problem happens in Telnet in addition to SSH. The Telnet uses a completely different socket library system in TeSSH/CMUD compared to the SSH connection. So this helps rule out any problem in the SSH implementation and points to some other issue.

It's probably going to be hard for me to debug this without access to a server that shows the problem, so if anyone else has this problem and can create a login for me to test, I'd really appreciate it. Since I cannot reproduce this with any of my test servers, my guess is that it's something related to a specific firewall or security setup on your network, but that doesn't explain how PuTTY would work and TeSSH wouldn't. Unless PuTTY has added some sort of kludge to handle this specific situation somehow.

But I'll still take a look at the logs within a couple of weeks and let you know what I find. It's definitely something I'd like to clear up before the TeSSH public release if I can.

Posted: Mon Sep 14, 2009 7:39 pm

OK, I downloaded WireShark and have taken a quick look at the packet dumps.

The main difference that I see is that in packet #4 PUTTY is initially sending a bunch of Telnet options to tell the server what it supports. Then the server responds to this in packet #5.

TeSSH doesn't send any initial telnet options...it waits to hear from the server about what the server wants the client to do. In packet #4 of the TeSSH dump, you see the server sending it's initial telnet option requests. TeSSH answers the WILL requests one by one in packets #12 and #14.

But I can see that there is a 20 second delay before TeSSH is sending these option answers, which is quite odd. Seems like TeSSH should have responded immediately to the initial request around packet #6 or so.

I'm going to need to try to write a simple little Telnet server myself and get it to send these exact packets to debug this and figure out the problem. It definitely seems like a problem on the TeSSH end though. It will take a while for me to get to this since I have some family visiting for the next couple of weeks, but I'll keep you posted.

Thanks again for sending the detailed network dumps.

Posted: Fri Oct 23, 2009 8:39 pm

I'm still completely stumped by this.

I have written my own Telnet server that sends the exact same packets that you showed me in your WireShark dumps. And I do not get *any* delays.

Instead of the WireShark dumps, it would still be useful for you to post the output of the TeSSH Script Debugger Window.

1) Run TeSSH
2) Click the Open Offline action for your session
3) Select the Script Debugger from the Window menu
4) Turn on all options in the Messages menu of the script debugger
5) Now select File/Reconnect from the main TeSSH window.

Copy and paste whatever gets displayed in the Script Debugger window and post it to this forum within [code] tags so I can see it.

Otherwise I will not be able to fix this until somebody can provide me with a server login that demonstrates the problem.

Posted: Wed Nov 11, 2009 10:01 pm

I just did a bit more testing and have some new detail to add.

As a simplified test, I ran the built-in Windows telnet server on the following:

1. On my work Vista notebook computer (as normal).
2. On a virtual machine running WinXP. (The VM had it's virtual network adapter turned off, so it was disconnected from my work LAN.)

(Note: The telnet server can be enabled and started in the Administrative Tools-->Services section of the Control Panel.)

On each setup, I then tried connecting via telnet to localhost.

Results:

1. On Vista, putty had no problems but TeSSH shows the delay.
2. On WinXP virtual machine, neither putty nor TeSSH had the delay problem.

This makes me wonder if it is a Vista problem, or a problem with my particular laptop or environment at work (which would be strange because putty is OK).

Script debugger output is below:

Vista:
Note: The entire TeSSH application including script debugger window is locked up during the 21 sec delay.

Posted: Thu Nov 12, 2009 2:11 am

Have you tried using the instructions on This Page using the netsh command in Vista to see if that is related to the problem at all? I know that autotuning was enabled in Vista by default and has been the cause of some pretty weird problems. I still don't know how PuTTY would get around it, but maybe they found a hack.

In any case, I will try running the telnet server on my Vista machine to see if I also get the delay. I'll let you know.

Posted: Thu Nov 12, 2009 5:11 pm

Here are my tcp settings in Vista before changing anything:

Posted: Tue Jan 26, 2010 7:59 pm

I am trying to work on this bug this week, and still cannot reproduce anything. I ran the Windows Telnet server on my Vista (and also Win7) machines and didn't get any delays. Here are my Vista tcp settings:

Posted: Tue Jan 26, 2010 8:19 pm

Well, that didn't do it. I learned how to change both the Scaling State and Auto-Tuning options. I set them to the same as your posted settings. I still didn't get any delay. Perhaps there are some other TCP settings that are effecting this? Can you try dumping all of your options using

C:\>netsh dump >netdump.txt

and email it to me? I'm still really really perplexed about all of this, but am still worried that it's a potential serious issue for the upcoming Public version.

Posted: Wed Jan 27, 2010 8:59 pm

Ok, I just emailed the netsh dump to you.

Posted: Wed Jan 27, 2010 9:11 pm

Got it. Unfortunately it's exactly the same as my Vista netsh dump here. So whatever is causing this, it's not within the Windows network driver specifically.

I'm completely stumped on this. Unfortunately, I'm going to just need to let this go for now. If lots of other people run into this problem with the Public version then maybe we'll be able to collect enough data to determine the cause of the problem. It certainly seems to be related to the local machine rather than the remote server. So this is going to be a very tough one to track down.

If you can think of anything else to try on your end, let me know.

Posted: Wed Feb 03, 2010 1:52 am

I just figured out the cause of the problem!:)

It's caused by TeSSH auto-checking for updates at www.zuggsoft.com, combined with not having the WWW proxy settings filled out if it's needed for external connections.

Without the WWW proxy set up in TeSSH, even manually going to Help -> "Check for New Version" will cause the freeze in my network environment.

Connections to systems in my local office network do not need the proxy defined.

When I define the WWW proxy, the problem disappears and nothing freezes.

Note: I replied to your last email with a longer description.

I also noticed another minor problem -- The popup window that appears when a manual version check fails is a bit out-of-date...

Part of it says:

Posted: Wed Feb 03, 2010 5:21 pm

Cool! Yes, that makes complete sense...I should have thought about that. I will get that fixed for the next version. Thanks very much for tracking this down.

Posted: Sat Feb 06, 2010 3:54 am

Should be fixed now in v3.14, so let me know.

Posted: Sun Feb 07, 2010 10:50 pm

The application freeze in TeSSH when connecting without my WWW proxy set is gone now.

However, it will still freeze the whole app when I manually use Help --> Check for New Version.

It's definitely just a minor problem now, but a popup window where you cancel the check would seem more polished.