ADSL Telnet Disconnect

[tomkonec]

This problem is a UK based problem - not sure if ADSL is different in each conuntry.

We have remote users at Site A who telnet from Windows XP PCs into a SCO Open Server 5.0.6 box at Site B via the internet. Site A and B have ADSL connections.

Everything was working fine until we changed from an ADSL connection with a 20:1 contention ratio to one with a 50:1 contention ratio at site A. Since then, when one of the Windows users does not press any keys on their telnet session for more than around 5 minutes, they are disconnected from their Unix application and have to reconnect.

The process of the SCO box is still "active", ie when you do a who, it is still there.

I think that my SCO box may need some configuration changes to keep alive the telnt session for longer? Any advice or pointers will be appreciated.

 

[Annihilannic]

Unless you are specifically running idleout SCO should not disconnect them. In any case, since the processes are still hanging around it seems like as far as SCO is concerned the connections are still active. It sounds to me more like a problem with the telnet clients.

You could experiment with the keep alive options (see the telnetd man page) and/or inconfig, but I think they have reasonable defaults and are already enabled. Annihilannic.

 

[apeasecpc]

If I am understanding your description correctly, you changed the ADSL settings on the terminal side at site A, but did not change anything at the UNIX side at site B, and since the change you are experiencing idle terminal disconnects at site A, but the processes remain open on the UNIX side at site B.

I agree with Annihilannic. This problem is not on the side of the SCO box. You should recheck the ADSL settings at site A, and the settings for the terminal software at site A.

 

[tomkonec]

If this helps, there is a SCO box at Site A purely used for Vision FS. When I telnet from SCO @ Site A to SCO at Site B I also get the same disconnection problem.

Is there any way to tune the telnet session on the SCO box at site A in order to diagnose the problem.

 

[dconman]

Depending on your router their may be a timeout function you have to increase. With the MultiTech routers we had to do this for some of our customers. After Five or ten minutes of Idle time we would have to remove the user from the SCO box and restart the VPN pipeline in the router. We uploaded the most recent patch and changed the idle time to like 500 minutes. That fixed us. The Crux is that it was not the SCO box but the router gear that was killing the user.

 

[itcamefrommars]

I have an extremely similar problem.

Posted it here two weeks ago.

How does the telnet client disconnect.
With my problem, the screen writes just stop, and the processes update to any commands I enter. Just i'll have a blank screen.

Is this a router to router VPN or is the Server Static?
What brand routers are you using?

Please let me know.... trying to understand a similar problem.

 

[tomkonec]

I have experienced this now with three clients:

1. Another SCO box. Upon disconnect I will be returned to the previous shell
2. ICE TCP Pro. Upon disconnect my Windows session will disappear (as the client thinks the session has finished)
3. Tiny Term. Upon disconnect it will give an error message.
In all cases the client will think that the server is no longer there. Other clients at the same site, who have pressed keys in the last "x" minutes will carry on working fine.
We are using a Alcatel Speedtouch 510 at the remote site and a standard BT supplied ADSL router. I have asked the router supplier whether there is any specific timeout setting and they say that there is not.

 

[apeasecpc]

What happens when you do a telnet from site B to the SCO Box at site A? Are you using DHCP or fixed IP addresses for the windows machines? Do you have any other sites that are telnetting to site A, and if so do they have the same problem?

 

[tomkonec]

What happens when you do a telnet from site B to the SCO Box at site A? Are you using DHCP or fixed IP addresses for the windows machines? Do you have any other sites that are telnetting to site A, and if so do they have the same problem?

When I telnet from Site B SCO server to Site A's SCO server, I do NOT get disconnected.

The Windows PCs at Site A use DHCP, however the Unix server at Site A has a fixed IP and has the same disconnect problem.

I do not have anyone else connecting to the SCO server at Site A, as site B is the head office. I have another site (Site C) that connects to Site B, and they do not have the problem.

Can I also add that I have the same router & ADSL service at home (Speedtouch 510 & BT "wires only" ADSL) and get the same disconnect problem with telnet to the SCO box. I have only been getting this problem since changing the ADSL service and installing my own router. However..at home I also use a Citrix ICA connection to Citrix Metaframe 1.8 server and have no disconnection problems at all!

 

[apeasecpc]

I am a little unclear, did you install or upgrade your home setup at the same time as the site A upgrade, or is your home setup the same as before you began experiencing the problem?

Is it possible that your home setup is being routed through site A before going to site B?

When you changed the site A concentration ratio did you also change the router?

I presume the Citrix Metaframe server is also located at site B. Is your ICA connection using TCP/IP only?

 

[tomkonec]

Actually my home ADSL/router is totally separate to the Site A/B/C scenario. The common factor is that at home I changed from a BT Business (20:1) ADSL to a "wires only" (50:1) ADSL with a Alcatel router. I connect from home to our office Unix server (Site A/B/C is a client) and since changing get the same disconnect problem.

"When you changed the site A concentration ratio did you also change the router?" - Is that the same as contention ratio? if so, yes we went BT router + 20:1 to Alcatel Speedtouch 510 + 50:1.

"I presume the Citrix Metaframe server is also located at site B. Is your ICA connection using TCP/IP only? " - Citrix server is at our office (nothing to do with Site A/B/C) and yes it is using TCP/IP only (no HTTP). Site A/B/C do not have Citrix at all so I have no comparison.

 

[tomkonec]

Turns out that it is a router configuration problem! I got one of my techies to turn off part of the firewall functionality that comes installed with the router by default and everything is fine now