Telnet On VMS

[echan]

I have a VMS system running OpenVms 7.3.2 on an Alpha hardware. Rebooted the machine. I can't telnet to that machine remotely, i.e. from another machine. If however, I telnet from within the same machine, using another DECTerm from its desktop, I was able to successfully connect to itself.

When I executed the command:

$ ucx enable service telnet

I get a reply back from the system as follows:

%TCPIP-I-SERVSTARTED, TELNET service already started

Then, I executed the command:

$ ux show service telnet/full

This was the ouput:

Service: TELNET

                                                  State:              Enabled

Port:                23                      Protocol:       TCP                      Address: 0.0.0.0

Inactivity:           1                      User_name: not defined        Process: not defined

Limit:        10000                      Active:                                         Peak: 0

File:               not defined

Flags:           Listen Rtty IPv6

Socket Opts:       Keepalive Rcheck Schedk

   Receiver:          3000       Send:                      3000

Log Opts:             Actv Dactv Conn Error Logi Logo Mdfy Rjct

   File:                    not defined

Security

   Reject msg: not defined

   Accept host: 0.0.0.0

  Accept netw: 0.0.0.0

I need help really bad...can someone give me some sheds!!! please....Thanks!

Elizabeth Chan

[Steven Schweda]

> I have a VMS system running OpenVms 7.3.2 on an Alpha hardware.

      tcpip show version

> I can't telnet to that machine remotely, [...]

   "I can't" is not a useful problem description.  It does not say what
you did.  It does not say what happened when you did it.  As usual,
showing actual commands with their actual output can be more helpful
than vague descriptions or interpretations.

> [...] i.e. from another machine.

   Not a very detailed description of the other machine, either.

> If however, I telnet [...]

   Again, with my weak psychic powers, I don't know exactly what you
did, or exactly what happened when you did it.

> This was the ouput:

   I see no obvious problems there.

   Is Telnet the only service with a problem?  (Does, say, FTP work
better?  Ping?)

[Maurizio De Tommaso_]

I agree with Mr. Steven Schweda, few information here.

Can you connect to the OpenVMS server using other protocols such as Decnet or Lat ?

Are you able to ping the AlphaServer ?

Any problem at OSI Data Link Layered ?

$ mc lancp sho dev xxx /count  (where xxx is your network device )

BTW, try to connect the OpenVMS server with telnet from a client in the same subnet. If you can, then you could have a problem with the routing tables and/or default gateway :

$ tcpip show route
$ tcpip show route/def

In case, give us more detailed description of your problem.

[Hoff]

Please read the TCP/IP Services configuration manual.  VMS is not an operating system where you can "wing it" with particular chances of success, and the manuals will save you time and effort and confusion and particularly for a task as commonplace as configuring and starting telnet.  In particular here, I don't know where that "UCX" verb arose (that's the old name of theproduct, and exists for compatibility with older software) nor the "enable service telnet" syntax, but that's not typical for configuring and starting telnet; this implies some older knowledge of TCP/IP Services from somewhere, or maybe some confused directions from somewhere.   The TCP/IP shelf is available via here:  http://www.hp.com/go/openvms/doc  There's a chapter in the TCP/IP Services configuration and management manual on getting telnet going.

The configuration documentation will point you to @SYS$MANAGER:TCPIP$CONFIG and related set-up, and potentially at some manual set-up.  (That manual set-up is less common with the telnet server, but more common with many of the other servers.)

When it comes to networking, the old Russian proverb "trust, but verify" is key.  While the network folks are knowledgeable and mean well, many of the devices they are working with are seemingly expressly designed to cause confusion, and to introduce communications errors.  Always verify the network connections, and the networking set-up.

And for completeness, telnet is wildly insecure, and ssh would be a better choice.

[Dennis Handly]

>the old Russian proverb "trust, but verify"

I thought that was Ronnie's.  But perhaps that why he used it.  ;-)

http://en.wikipedia.org/wiki/Trust,_but_verify

[Pavani21]

Hi, we have a similar situation here where we are not able to telnet from the AWS cloud server to the guest operating system i.e. openVMS via charon emulator.

How the route was created as mentioned in the earlier replies.

can you please let us know the steps you followed to resolve the issue.

[Steven Schweda]

> [...] we have a similar situation [...]

   No, you don't.  "Alpha hardware" v. "charon emulator"  Different
problem.  Start your own new thread.

> How the route was created as mentioned in the earlier replies.

   "the earlier replies" tell me nothing about your (emulated) network
configuration or about your routes.  Start your own new thread.

   And when you do start your own new thread, you might include some
basic information about _your_ system, what you're doing, and what
happens when you do it.