SCO

jgt,
Since running the other Terminal emulation software the link has stayed up all day. I have not changed anything in the default configuration on the ICE terminal package except for the terminal type for SCO ANSI and the screen lines needed to be 25 instead of the default 24. Nothing has been changed on the SCO Server right now. I will continue to let it run for a few days and see what happens.
I appreciate all of the help and guidance that I have received

I have tried to install the other Terminal Emulator program and it worked well for 1 day, and as of today the Server has disconnected the Terminal Emulator ICE TCP Plus about 5 times.
In answer to jgt there is no firewall or router in between the users and the SCO system.
Would anyone have any ideas why the telnet session just terminates. It appears to be coming from the server. Is there any debug or monitoring I can turn on to get the information as to why the connection is being terminated?
I appreciate any help.
Thank you

Do you have devices with static ip addresses within the DHCP range?

Changing telnet client will almost certainly not fix this problem for you. That s a red herring.

My question for you - is this actually a new problem for your users or is this an old recurring problem which your users have lived with for a long time? If it is a new problem, what has changed?

jgt,
I have checked an no there are no static addresses in the DHCP range. I have done a span port to wireshark trace the data in and out of the server and do not see any conflicts, nor am I seeing any of the windows clients responding with duplicate IP address errors.

fpmurphy,
Thank you I have been trying to go over what could have changed in the last month when this appears to have started, as it is new. The only difference at the moment is that the user computers used to be static IP addresses and I have replaced a number of them as they were old. When I found out they were static I changed them to DHCP (I changed them because I found that the wireless was issuing DHCP addresses in the static range and so I changed all devices to static except for the servers and routers). Could changing the user computers to DHCP effect the server telnet connections? Could SCO block connections from specific addresses? If it were to block connections from certain IP addresses I would have though it would block the connection totally and I would not be able to connect at all. This allows the connection and then disconnects anywhere from 1 minute to hours later.
The second change was to add a new printer to the SCO server but all was working fine for a week after this printer was added and I don't see how adding a network printer would have affected the Telnet connections but I am not a SCO Admin to say the least. This is baffling me.
The SCO server is over 20 years old and I am wondering if the NIC card is acting up after all of these years?
I am looking at the wireshark traces to see which end is definitely sending the disconnect. Would anyone know if I should be looking for a disconnect from the Telnet data payload or is it just a matter of the TCP Reset (RST) or Finished (FIN) Flags? Or am I looking too deep for a simple problem?
Thank you all for your contributions.

In your original post you said that your system was release 6.
SCO had a version 5.0.6 issued about 1998, and a release 6.0.0 issued in 2006.
The command "uname -X" will display the release details.
Can you also post (partial) contents of /usr/adm/messages, showing a portion of the file that shows the hardware installed. This will be the same information that shows on the screen when the system boots.
Also, can you run "custom" and take a screen shot of the software installed, to confirm if all patches have been applied.

In 2 similar setups with 5.0.5 I restricted the DHCP pool used by the wireless to something like 10 possible addresses then went static with everything else.

I could see the disconnects as a possible router issue when using DHCP assigned addresses.

I've used TinyTerm over the years, never have had any issues in the 8 installations it was installed in.