Problem with TELNET via a DECSERVER

[Chaim Budnick]

We are having a problemn with telnet connections breaking and then problems reconnecting.

Following are the show server output:

Network Access SW V2.4 BL50 for DS90M ROM 5.1 Uptime: 19 09:17:49

Address: 00-60-6D-93-B8-19 Name: DEC_GESHER1 Number: 0

Identification:

Circuit Timer: 80 Password Limit: 3
Console Port: 1 Prompt: Local>
Inactivity Timer: 30 Queue Limit: 100
Keepalive Timer: 20 Retransmit Limit: 8
Multicast Timer: 30 Session Limit: 64
Node Limit: 200 Software: MNENG3
TFTP Host: None

Service Groups: 0

Enabled Characteristics:
Announcements, Broadcast, Dump, Lock

===============================================
Following are the show port output:

Port 1: Server: DEC_GESHER1

Character Size: 8 Input Speed: 9600
Flow Control: XON Output Speed: 9600
Parity: None Signal Control: Disabled
Stop Bits: Dynamic

Access: Local Local Switch: None
Backwards Switch: None Name: PORT_1
Break: Local Session Limit: 4
Forwards Switch: None Type: Ansi
Default Protocol: Telnet Default Menu: None
Autolink Timer One:10 Two:10 Dialer Script: None

Preferred Service: 192.168.11.1
Authorized Groups: 0
(Current) Groups: 0

Enabled Characteristics:
Autobaud, Autoprompt, Broadcast, Failover, Input Flow Control, Lock,
Loss Notification, Message Codes, Output Flow Control, Verification
===============================================

Does anything look suspicious to anyone?

Thanks

Chaim

[Ian Miller. · Accepted solution]

the problem is with telnet sessions from this DECserver to other system?

[Chaim Budnick]

The ALPHA server is at site A. The DECSERVER and users are at site B. The users have Vts connected via the DECSERVER and they connect to the ALPHA OpenVMS system.

Chaim

[Antoniov.]

Hi Chaim,
your user have to type CONNECT command to open connection because you have not defined autoconnect characteristic.

Antonio Vigliotti

[Chaim Budnick]

You are correct, I failed to mention this. They do enter "C" and then the connection is established, albeit not always, and this is part of the problem.

Chaim

[Antoniov.]

Ok Chaim,
for autoconnect you can type (if I remember)
DEFINE PORT xx AUTOCONNECT
Before you have to set SYSTEM password.

Antonio Vigliotti

[Chaim Budnick]

Do you think that the lack of AUTOCONNECT is causing problems?

Chaim

[Antoniov.]

Hi Chaim,
Decserver works fine without autoconnect too but some user does no!
If your user are dummies you can meet some trouble without autoconnect; here there is a list of my trouble in past:
- Some user type C , Decserver search for service displaying ...
- Ctrl + Break (Ctrl + F4) return to decserver console; it's very difficult key combination but might happen :-(

You can leave console to evolute users because they can use multiple sessions. If you donìt need multiple session I hint set autoconnect.

Antonio Vigliott

[Chaim Budnick]

Thanks for your answers.

The users are aware of the dact that they MUST enter "C" and then they are connected.

At any rate, since I executed a LOGOUT PORT yesterday, the users have said that they are NOT having any apparent problems and are able to connect and establish the connection without it breaking.

Thanks to everyone for assistance!

Chaim

[Uwe Zessin]

Antonio gave a useful hint:
it is possible that the user had multiple sessions open and then ran into the maximum session limit for that port. A LOGOUT will kill all sessions. I think you can also set the session limit down to 1.

[Chaim Budnick]

Indeed the session limit for the port is 4.

What will I accomplish by setting the limit to 1, I didn't quite understand your comment regarding the session limit for the port?

Chaim

[Ian Miller.]

by reducing the session limit for each port to 1 then each user can only start one session. Your problem may be that too many sessions where started on that DECserver. By only allowing one session per user (which is often all that is needed) you can prevent this.

Users can create multiple sessions and not be aware if it sometimes. (some users are aware of very little :-)

[Uwe Zessin]

I meant this:
> Local Session Limit: 4

If you have a mix of inexperienced and more experienced users you can choose the limit per port, assuming that each user has a dedicated terminal for his own use.

[Chaim Budnick]

Thanks for the explanation!

Is there a way of telling how many sessions are currently open on the port.

I tried:

sho port 1 counts - but I don't see any counter for sessions.

Chaim

[Ian Miller.]

I think its 'show sessions all' to list open sessions.

[Tiina Ayris]

Hi Chaim -
>help show sess
SHOW/MONITOR SESSIONS

Use the SHOW SESSIONS command to display information about the current sessions
at a port.

{SHOW} SESSIONS [PORT port-list]
{MONITOR} [ALL ]
Hope this helps
Tiina

[Terry Yeomans]

Hi Chaim,
if you type SHO PORT 1 STA this should show you how many sessions have been connected.
Info and pointers:
If you are not using LAT to connect to the the server, then the Service groups etc can come off.
Have the ports been set to Telnet Listener at all ?
Terry.

[Chaim Budnick]

Yes, the port is set to TELNET

Chaim

[Martin Vorlaender]

There also is a TELNET connection limit built into TCP/IP Services on the VMS side. You can see the setting using

$ TCPIP
TCPIP> SHOW SERVICE TELNET /FULL

You can raise is with

TCPIP> SET SERVICE TELNET /LIMIT=
TCPIP> DISABLE SERVICE TELNET
TCPIP> ENABLE SERVICE TELNET

Be aware that the last two commands kill all open TELNET sessions!

HTH,
Martin

[Chaim Budnick]

This customer has implemented MULTINET and not TCPIP of HP.

Chaim

[Terry Yeomans]

Hi Chaim,
what I meant by Telnet Listener on ports is as follows:
change telnet list 2001 conn dis
change telnet list 2001 port 1 ena
change teln list 2001 type raw
change teln list 2001 conn ena
....and so on for each port. This may help.
Yours hopefully Terry.

[Ian Miller.]

telnet listener is used when connecting from vms to DECserver port not from DECserver to vms as in this case.

Are there any other network problems?

[Chaim Budnick]

Currently, the situation is stable!

Chaim

[Jan van den Ende]

Chaim,

to me it looks like you already solved the problem for the near future, but it MAY well return again.
We also sometimes have had similar issues with terminal servers (both at LAT and at TELNET). Logging out of a port (from within the server, priv'd action) usually helps for quite some time. If, at a particular server, it starts happening often/at different ports, then a reboot of the server is the thing to do (although, I don't recall that on DSxx servers, but it WAS a real issue at ChipComm).

hth

Cheers.

Have one on me.

Jan

[Ian Miller.]

some versions of DECserver software had memory leaks and needed regular reboots (just like a windows system :-) but I've not seen this on the version you have.