Telnet sessions to 5.06 is are timing out. Need SCO Pro!

[bmcgrathPIX]

I have a serious problem, and i unfortunately am not a UNIX guy, so please have mercy...
We have a VAR that supplies us with an application package that runs on SCO openserver 5.06. Out useres use terminal emulators (J River DejaWinT, Transoft UGI) to connect to the SCO box via telnet sessions. Users at our remote offices (which are connected by VPN, but Cisco is adament that the WAN routers and such are not the cause of this) are noticing that something is disconnecting their session when they leave it idle for a while, say an hour or more. I cannot pinpoint if this happens exactly in a hour, but i think it may be somewhat random.

Can anything in SCO be made to do this? Our VAR says no, but i would think something could make this happen. This all seems to have started when that VAR did a migration to a new server..leading me to believe it could be SCO, as it is the only thing that has changed.

Your help would be appreciated beyond belief!

Help me prove that VAR wrong!

 

[PHV]

idleout is maybe running on the SCO box.

Hope This Help
PH.

 

[bmcgrathPIX]

They swear that nothing has been set up to do this, and i am told "idleout" is not enabled by default. is there a syslog or something that i can look at to see if this is active and causing issues?

 

[PHV]

Take a look at the /usr/spool/locks directory and see if a file named like LCK..idleout exists.
If not, the culprit is probably a router or a modem.

Hope This Help
PH.

 

[cdlvj]

<<Cisco is adament that the WAN routers and such are not the cause of this) >>

Had the same situation years back with ISP adament that the routers were not the culprit, WELL it turns out that the router was droping the connection after 1 hour.

What kind of line is this? T1? ISDN?

 

[apeasecpc]

Is your vpn all cisco? Also, what are your timeout settings for re-keying on the cisco vpn? Re-keying sometimes takes time to process, and the terminal software might be interpreting the interruption as a loss of connection. I recommend longer time periods between Re-keying.

Does the problem ever happen when the terminal is not idle (i.e. while running reports or data entry)?

I have some people who vpn telnet to my sco box and there have been occasional dropped connections, but I figure thats due to heavy internet traffic for the most part.

 

[bmcgrathPIX]

the problem is that we have multiple users in this remote office. 1 user will go to lunch and leave his PC while the other user keeps inputing, running print jobs, etc. from another PC. only the user who left their session idle will timeout, the other will not. If their is a re-keying issue, im not sure but i dont think the other user would continue to be able to work? the WAN is all cisco, and is all on site (no ISP operated equip), IPSEC VPN's over (gasp) ADSL. the problem is that this hasnt happened in the 2 years the VPN have been working, only after the SCO migration can we recall this happening.

regarding the locks directory mentioned above...this is the output i get:
# cd /usr/spool/locks
# pwd
/var/opt/K/SCO/tcp/2.1.1Ga/usr/spool/locks
# ls
#

does this mean nothing is in this directory? (again, i dont know UNIX, i am a windows guy)

 

[PHV]

Yes, your /usr/spool/locks directory seems empty.
Another possibility is that the remote PC drops the link on the NIC when it enters PowerSave mode. This is an option generally found in the last tab of the NIC's properties sheet.

Hope This Help
PH.

 

[apeasecpc]

What were you using before SCO? Were your users telneting into the old system also, or did they have some other kind of application? You should check the terminal software and see if it has some kind of timeout settings also.

 

[bmcgrathPIX]

I have checked all APM features, and turned everything off. We were using the same OS before, we just got a new server. the terminal software hasn't changed for a couple of years, and this problem is onyl a couple pf months old at most. there are no timeout settings on the term emulators. Could the NIC on the SCO server be dropping the connection?

 

[tshot]

Frpom wjhat u have said, i understand that only remote users are facing this proble,

if or if not in both the case list all possibilites and then start elimintaing one by one.
Possible culprits are
1. SCO
2. ROUTERS
3. TEMINAL EMULATOR



i.e try logging as one of the users locally and leave it for > 1 hr. U should do this 1) on ur server 2) on a PC with emulator.

Leave CISCO to the end




----------------
ur feedback is a very welcome desire

 

[bmcgrathPIX]

Today I am running a Hyperterminal session idle along with the ICE.TCP emulator. both are connected to the same server. I dont see any settings in ICE.TCP or HyperTerminal to indicate the presence of any timeout features, so hopefully we can eliminate the clients if both telnet sessions drop on idle. I still have Cisco looking into the issue. I will keep posted.

I appreciate everyone who is helping with this! Thanks!

 

[bmcgrathPIX]

Well, both sessions disconnected at the same time (approx 5-10 minutes of idle), so i guess we can rule out terminal emulation software as the cause. I am going to establish a connection to a windows terminal server through hyperterminal to see if that times out as well...then i will know for sure if its SCO or Cisco.

 

[apeasecpc]

Try two sessions again, only this time don't start them at the same time. If both still disconnect at the same time it is not a timeout issue, and is most likely related to your cisco re-keying, network overload, or a bad nic on the server.

 

[JimFarmer]

Some how you are having a communications outage that is being restored. Try running a ping of your unix box from the PC's and see if that keeps them alive...ping -n 10000 ipaddressofunixbox. Run this while you are telenetted in and see if the problem disappears. If it does you are looking at some lapse....

Some switch's forget a box if it is inactive for a period of time, also routers may drop circuits, or are their dialup data circuits in here? Do local stations have timeout's?

 

[cajuntank]

I am running into the same issue... Have a SCO 5.0.6 server with workstations connecting fine to it on it's own subnet. On another sub-net over a VPN connection those pc's will timeout after 10 minutes or so of being idle. From reading through the previous posts to this problem, all troubleshooting was done. Going across some Lantronix serial to ethernet works fine since it converts back to serial on the Unix server side. My feeling is that there is some setting or patch that needs to be applied to the SCO box for IP connection on remote subnets to not idleout. Also, when these connections idleout, a new connection has to be established causing additional license usage. Does anyone know what we might need to look at (I too am not a Unix guy, so be gentle)?

 

[motoslide]

The best solution I've found is to use a Terminal Emulation package that offers a "keepalive" setting. This just sends a null packet at intervals of your choosing (every 30 seconds, for example). Try a download of AnzioLite (free to use for 60 days). Configure it for the desired terminal type and host IP. Once connected, click on "Communicate --> Network --> Stayalive" and set the value to 30.
This should solve your problem, and we've had good results using the emulation package in general.

You should be able to get the download here:

http://www.anzio.com

You might see if your current emulation package has a similar setting.

 

[KenCunningham]

Alternatively, set up your own keepalive script to echo something to /dev/null at regular intervals. Put the script in the .profile in a permanent loop which will remain active for the user's session. Not sure if this will 'fool' the culprit, but worth a try?

 

[stanhubble]

Another Alternative.....

Have the sco system check on the clients sooner...
inconfig -v

and look at the tcp_keep_intvl, tcp_nkeep and tcp_keepidle.

tcp_keepidle this by default is set to something like 2 hours but can be set as low as 300 seconds. this value is how long a session is idle before the tcp stack sends out a "are you still there?". tcp_nkeep is how many to send out, and tcp_keep_intvl is how long to wait in between.

this is usually used to detect when a client has gone away, but it should provide enough traffic to keep the inbetween devices active.

 

[spsims]

You're right - it is the routers.

Add this command to your router(s) running Cisco IOS with the firewall feature enabled.

IP INSPECT TCP IDLE-TIME 28800

This changes the default TCP idle connection time from one hour to 8 hours. After 8 hours an idle telnet (or any TCP) session will be dropped.

Hopefully this will help someone....