I am currently using version 1.77 and had previously used a different version. On the earlier version I could remain connected to my server indefinitely without problems. Now since the upgrade to version 1.77 after an inactive period of approx. 3 minutes I have to reconnect. Is there a setting somewhere that I have overlooked or is this a glitch, or is this on purpose. How can I get around this.
LonnieB
[size=1][ February 19, 2002, 04:22 PM: Message edited by: Brian T. Pence ][/size]
LonnieB,
There can be lots of reasons for timeouts. Without knowing your environment, it's hard to say what's affecting you. I don't believe I know of anything in any version of AbsoluteTelnet that would cause additional timeouts. Timeouts are usually a server or firewall thing. However, in version 1.81, the software can be configured to send keepalives which will keep your connection warm when not in use. Keepalives are enabled by default, so you should be able to just download the new software to take advantage of this feature. If you wish to disable keepalives or change the interval at which they are sent, you can access those settings at Options->Properties->Connection.
You can download the new software here:
Brian
Thanks,
The 1.81 version does appear to keep the connection alive. Until you mentioned it I had forgotten that I moved all my workstations behind a router. So many machines, so many changes, so much to do.
Thanks Again
LonnieB
Glad to hear it!!!
I'm having a similar problem, using 1.84 to connect to Cisco switches and routers. Keepalives are set to 30 seconds yet I still get disconnected after about 3 minutes. How can I fix this?
Hmmmm....
AbsoluteTelnet timeouts are implemented at the protocol level, intended to keep sockets active so firewalls, DUN, and poor network conditions will not cause connections to close.
You may be experiencing a higher level timeout similar to a UNIX Shell level timeout where the user interface itself is not receiving any keyboard input and is closing due to the inactivity. It's important to note that the shell or command line interface is *not* receiving input even when keepalives are turned on. Keepalives operate at the protocol level, keeping network connections active, but the shell or command line interface is completely unaware they even exist.
If your disconnects are at random times, there's likely something else occuring. If they occur at precisely X minutes after your last input, it could be a shell level timeout intentionally defined that way in your system. You may be able to change those settings, or the admins may have defined it that way on purpose. In UNIX, there are some shell variables you can change to set it.
The only way to send 'keepalives' if the timeout is at the shell level is to do something equivalent to hitting the enter key every thirty seconds. While effective, this 'injecting' of user input sometimes has a bad effect on the system at the other end (causing things to unnecessarily scroll every 30 seconds, etc....) I've tried to avoid this kind of keepalive, as it is usually considered a 'hack' and there are generally other ways around the problem. To test if this would work, hit only the 'return' key every 30 seconds of your session and see if the disconnect occurs.
Is any of this making sense in your situation?
That's exactly it. The switches are timing out at 10 minutes even though the default is supposed to be none.
I was hoping for a solution that didn't force me to modify the configs on all of the switches, but that looks like it'll be the best solution for now.
Thanks for your help.
No problem, glad I could help!!!
