When you enter the SHOW CONFIGURATION SNMP command to display your current SNMP configuration, the information associated with the /FLAGS=options qualifier is displayed as follows:

Flags: AuthenTraps Sets

SNMP will function even if you do not include the /FLAGS=SETS and /FLAGS=AUTHEN_TRAPS qualifiers.

To remove flags that were set previously, enter the following commands:

TCPIP> SET CONFIGURATION /FLAGS=NOSETS TCPIP> SET CONFIGURATION /FLAGS=NOAUTHEN_TRAPS

Alternatively, you can display configuration information in the SNMP configuration file (SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT). The configuration file displays more information than the SHOW CONFIGURATION SNMP command when multiple types of traps or addresses for them have been defined. For example:

$ TYPE SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$VMS_SNMP_CONF.DAT trap V1 elmginkgo 15.9.0.200 community alternate 15.4.3.2 read community public 0.0.0.0 read community TRAPIT 1.2.4.5 write trap v2c TRAPIT 1.2.4.5 community rw 10.1.1.3 write community rw 15.9.0.200 write

Note that the first two lines of the configuration file are not displayed by the following SHOW CONFIGURATION SNMP/FULL command:

TCPIP> SHOW CONFIGURATION SNMP/FULL Community Type Address_list public Read 0.0.0.0 TRAPIT Read Write Trap 1.2.4.5 rw Read Write 10.1.1.3, 15.9.0.200

14.6.5.2.1 Specifying Location and Contact Information

To specify the location and contact information, include the /LOCATION and /CONTACT qualifiers on the SET CONFIGURATION SNMP command line.

If you do not specify the location and contact information, it is displayed as "not defined" by the SHOW CONFIGURATION SNMP/FULL command. For example:

TCPIP> SHOW CONFIGURATION SNMP/FULL SNMP Configuration Flags: Sets Contact: not defined Location: not defined

To remove a previously specified location, enter:

TCPIP> SET CONFIGURATION SNMP /LOCATION=(NOFIRST,NOSECOND)

Once you specify a contact name using /CONTACT=name, you can change the name but you cannot remove it. If you enter /CONTACT=" ", the previously specified contact name remains in effect.

14.6.5.2.2 Verifying Community Information

To display the community strings for the OpenVMS host, enter the following command:

TCPIP> SHOW CONFIGURATION SNMP /FULL

Also, check the community configuration in the TCPIP$VMS_SNMP_CONF.DAT file, as described in Table 14-4.

Make sure that the community string used in the messages matches a valid community of the appropriate type on the server. Check also that the MIB variable is defined with write access and implemented as such in the subagent. Note that in OpenVMS standard MIBS, the Set command is not implemented for some variables defined as writable in the MIB II and Host Resources MIB.

For example, the community must be configured as /TYPE=(READ,WRITE) to process set requests.

If SNMP is not responding to set commands or to other requests:

• One of conditions listed above has not been met.
• The commmunity name is invalid. Check to make sure uppercase or lowercase letters are specified correctly. Community names are case sensitive.
• SNMP is not running on the system.
• There are network, delay, or timeout problems.
• The community address was specified incorrectly.
• Communities with write access are not defined on the server.
• The "public" community configuration was not specified as /TYPE=READ with address 0.0.0.0.
• The SNMP configuration is correct, but SNMP was not restarted after changes were made.

By default, SNMP sends Version 2 traps, which can be configured using either the TCPIP$CONFIG.COM procedure or the SET CONFIGURATION SNMP command. You can modify SNMP to send Version 1 traps by default, using the trap option described in Table 14-4.

You can implement individual SNMP Version 1 traps even if Version 2 traps are set by default. Add a line for each trap destination to the TCPIP$VMS_SNMP_CONF.DAT file using the following format of the trap option:

trap v1 community IP-address[:port]

When SNMP Version 1 traps are set by default, you can send SNMP Version 2 traps by adding a line to the TCPIP$VMS_SNMP_CONF.DAT file for each Version 2 trap destination using the following format of the trap option:

trap v2c community IP-address[:port]

In these formats:

• community specifies the community name.
• IP-address specifies the IP address of host that is listening for traps.
• port specifies the port number. The default port number is 162.

Regardless of the default trap type, you can control the trap type for each trap destination using the appropriate tag ( v1 or v2c ). For example, the following entries in the TCPIP$VMS_SNMP_CONF.DAT file will cause a Version 1 trap to go to the host with the IP address 120.2.1.2 (community name v1type), and a Version 2 trap to go to the host with the IP address 120.2.2.2 (community name v2type). Both traps will go to the well-known port 162:

trap v1 v1type 120.1.2.1 trap v2c v2type 12.2.2.2

14.6.6 Solving Management Client Response Problems

When an SNMP client is not getting a response to set , get , getnext , or getbulk requests, even though the SNMP server is configured and running, the problem might be with the operation of the subagent or in the transmission of the query or response message. To test, follow these guidelines:

1. Confirm that TCP/IP Services is running on your host. Enter:

   TCPIP> SHOW INTERFACE

   • If TCP/IP Services is not running, a response similar to the following is displayed:

     %TCPIP-E-INTEERROR, error processing interface request -TCPIP-E-NOTSTARTED, TCP/IP Services is not running

   • If TCP/IP Services is running, a response similar to the following is displayed:

     Packets Interface IP_Addr Network mask Receive Send MTU WE0 126.65.100.68 255.255.0.0 20298 5 1500 WF0 126.65.100.108 255.255.0.0 20290 2 4470 LO0 127.0.0.1 255.0.0.0 3290 3290 0

2. To ensure the successful startup of the SNMP master agent and subagents and the operation of the TCPIP$SNMP_REQUEST utility (MIB browser), confirm that the BIND resolver has been configured correctly by entering the following command:

   TCPIP> SHOW NAME_SERVICE

   
   Refer to Appendix D for information about configuring the BIND resolver.

3. Check the status of the SNMP service using the following DCL command:

   SHOW LOGICAL/TABLE=TCPIP$STARTUP_TABLE.

   
   This command shows when each TCP/IP Services service startup completed and which user performed each startup. If the SNMP service is not listed, it was either shut down or it was not started.

4. Use the MIB browser on the host to retrieve the OID in question, as described in Compaq TCP/IP Services for OpenVMS SNMP Programming and Reference.
5. If the local query is successful, use a MIB browser from another host. This is useful when timeout problems indicate that network delays are the cause of the problem.
6. Check the log files for any problems associated with SNMP startup. For detailed information, start the SNMP components separately with tracing enabled, as described in Section 14.6.4.
7. Use a protocol analyzer to intercept messages going to the target. The TCPTRACE utility is available on OpenVMS hosts. Enter the DCL command HELP TCPTRACE for information about how to use this utility. For the failing message:
   • Confirm the community configuration, as described in Section 14.6.5.2.2. Make sure the default community is configured correctly. For example, make sure that a read-only community name, such as "public," is not being used for set requests. For more information about community names, refer to the Compaq TCP/IP Services for OpenVMS SNMP Programming and Reference guide.
   • Check to make sure the client used the correct query format.
8. Check for problems with ownership, protections, or installation of images, using standard OpenVMS DCL commands, such as DIRECTORY and INSTALL.
   For example, the following message indicates that one of these factors is a possible problem:

   WARNING: select returned -1 on snmpd sockets: not owner

   
   The owner for all SNMP executables should be [SYSTEM]. At a minimum, the protection should be set to S:RWED,O:RWED,G:RE,W:RE.

9. If you cannot get a response for MIB variables handled by certain subagents, verify that the subagents are running by entering the following command:

   $ SHOW SYSTEM

   
   Check for the following processes:

   • TCPIP$SNMP_n (master agent)
   • TCPIP$OS_MIBS (standard subagent)
   • TCPIP$HR_MIB (standard subagent)
   
   See the Compaq TCP/IP Services for OpenVMS SNMP Programming and Reference guide for descriptions of these processes.
   Also check for custom subagents whose process names appear after RUN commands in the following command procedure:
   SYS$SYSDEVICE:[TCPIP$SNMP]TCPIP$EXTENSION_MIB_RUN.COM.
   If these processes and additional subagents follow the model of the Chess example, they should be in LEF state. Excessive time in HIB state indicates a problem. If the processes are not there, check log files for the possible cause of abnormal termination. Note that you must run the SYS$STARTUP:TCPIP$SNMP_SHUTDOWN.COM procedure in order to see entries in the latest .LOG and .ERR files. If a query on members of the hrFSTable group results in no response or in a "no such name" response, the problem might be one of the following:
   • No devices are mounted through NFS.
   • Access to mount information is not available because the proxy is not set up to allow the TCPIP$HR_MIB subagent to access NFS-mounted disks.
   
   Additional problems occur if file protections or installation privileges were changed on SYS$SYSTEM:TCPIP$HR_MIB.EXE.

If queries from a client to an OpenVMS SNMP server are consistently timing out, consider solutions on either the client or server side. For information about checking the client side, refer to the Compaq TCP/IP Services for OpenVMS SNMP Programming and Reference guide.

On the server:

• Adjust the default timeout value for master agent/subagent communication by redefining the system logical TCPIP$ESNMP_DEFAULT_TIMEOUT, as described in Table 14-5.
• Analyze the performance of slow areas of subagent code to improve the speed of those areas.
• Split up one subagent into multiple subagents, each handling a subset of the original OID tree.
• Adjust the timeout for individual subagents using esnmp_init() , as described in the Compaq TCP/IP Services for OpenVMS SNMP Programming and Reference guide.

Before making extensive modifications to either the client or the server, consider analyzing the network load for congestion problems.

14.6.7 Disabling SNMP OPCOM Messages

To disable OPCOM messages for SNMP, enter the following command sequence:

TCPIP> SET SERVICE SNMP /LOG=NOALL TCPIP> DISABLE SERVICE SNMP TCPIP> ENABLE SERVICE SNMP

Be aware that when you disable OPCOM messages, you may be suppressing information that is useful for solving problems.

Part 4 describes how to set up popular networking end-user applications and includes the following chapters:

• Chapter 15, Configuring and Managing TELNET, describes how to set your host as a TELNET server, allowing users on remote hosts to establish login sessions.
• Chapter 16, Configuring and Managing FTP, describes how to set up your host as a FTP server, allowing users on remote hosts to transfer files.
• Chapter 17, Remote (R) Commands, describes how to set up the server implementations of the popular Berkeley Remote (R) commands that enable remote file copying (RCP), remote logins (RLOGIN), remote command execution (RSH and REXEC), and remote management of magnetic tape and CD-ROM (RMT/RCD) drives.
• Chapter 18, Configuring and Managing SMTP, Chapter 19, Configuring and Managing the POP Server, and Chapter 20, Configuring and Managing the IMAP Server, describe how to configure and manage the components that allow users to send and receive internet electronic mail.
• Chapter 21, Configuring XDMCP-Compatible X Displays, describes how to configure an XDMCP-compatible X display using the TCP/IP Services XDM server.

The TCP/IP Services product includes and implementation of the TELNET end-user application.

This chapter describes how to set up your host as a TELNET server.

For information about using TELNET, see the HP TCP/IP Services for OpenVMS User's Guide. For information about using the TELNET print symbiont, see Chapter 25.

This chapter describes:

• How to manage the TELNET service ( Section 15.1)
• How to solve TELNET problems ( Section 15.2)

Managing TELNET includes the following tasks:

• Setting up user accounts
• Creating and deleting sessions
• Displaying login messages

The TELNET service can be shut down and started independently of TCP/IP Services. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

• SYS$STARTUP:TCPIP$TELNET_STARTUP.COM allows you to start up TELNET independently.
• SYS$STARTUP:TCPIP$TELNET_SHUTDOWN.COM allows you to shut down TELNET independently.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$TELNET_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when TELNET is started.
• SYS$STARTUP:TCPIP$TELNET_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when TELNET is shut down.

Table 15-1 lists the logical names you can use in managing the TELNET service.

Table 15-1 TELNET Logical Names

Logical Name	Description
TCPIP$TELNET_NO_REM_ID	Disables the intrusion detection mechanism used by DECnet network login logicals SYS$REM_ID, SYS$REM_NODE, SYS$NODE_FULLNAME. When this logical is set to TRUE, the SYS$REM* logicals are not set, thus bypassing intrusion-detection on logins. By default, this logical is not set.
TCPIP$TELNET_VTA	Enables TELNET virtual terminals.

15.1.3 Setting Up User Accounts

Hosts typically run a TELNET server with TELNET client software. Users on client hosts need valid accounts on server hosts before using TELNET to establish a remote session.

If your local host is to be a TELNET server, create OpenVMS accounts for remote users. You can create several individual accounts or one account that many remote users will share.

15.1.4 Creating and Deleting Sessions

You can create and delete TELNET sessions from within a command procedure or interactively. Enter the DCL command TELNET with the /CREATE_SESSION or /DELETE_SESSION qualifier. These qualifiers have the same function as the following commands:

TELNET> CREATE_SESSION host port dev-unit

TELNET> DELETE_SESSION dev-unit

For example:

$ TELNET /CREATE_SESSION TS405 2002 902

You can create a TELNET device that times out after a specified idle period then reconnects when data is written to it. Use the /TIMEOUT qualifier to specify the idle time and the reconnection interval, as described in the following table:

Qualifier	Description
/TIMEOUT	Creates a TELNET device that has the following connection attributes: NOIDLE---The connection is broken when the device is finally deassigned. The device will automatically reconnect when data is written to it. IDLE---Specifies the idle time for the device (in the format hh:mm:ss). Note that the time has a granularity of 1 second. If the device is idle for at least the specified amount of time, then the connection will be broken. "Idle" means that the device has neither received nor sent any data for the idle period. NORECONNECTION---The device does not automatically retry reconnections if they fail. RECONNECTION---When data is written to the device and it is not connected, this value determines the interval between reconnection attempts. For example, if an application writes to a TN with a RECONNECTION value of 0:1:00 and the first connection attempt fails, subsequent connection attempts will be made in 1-minute intervals.
/NOTIMEOUT	Creates a TELNET device that breaks the connection when the device is finally deassigned (the last channel assignment is deassigned).

15.1.5 Displaying Login Messages

To display login and logout messages at the operator's console and log file, enter:

TCPIP> SET SERVICE TELNET /LOG=(LOGIN,LOGOUT)

15.1.6 TELNET Client (TN3270)

IBM 3270 Information Display System (IDS) terminal emulation (TN3270) lets users make connections to hosts that use IBM 3270 model terminals.

TN3270 has default IBM 3270 IDS function assignments for DIGITAL keyboards. In addition, users can make their own assignments and might ask you for help. TCP/IP Services provides EBCDIC-to-DMCS and DMCS-to-EBCDIC translation tables you can customize. Appendix B describes how to customize and rebuild these translation tables.

For more information about using TN3270, enter the following DCL command:

$ HELP TN3270

15.1.7 Configuring and Managing the Kerberos TELNET Server

Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography. Kerberos uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. The TCP/IP TELNET service uses Kerberos to make sure the identity of any user who requests access to a remote host is authentic.

TCP/IP Services supports Kerberos security for TELNET connections, providing a Kerberos TELNET server and a Kerberos TELNET client.

Before you can use the Kerberos TELNET client, the OpenVMS Security Client software must be configured on the OpenVMS system. For more information about installing and configuring the OpenVMS Security Client software, see the HP Open Source Security for OpenVMS, Volume 3: Kerberos manual.

It is assumed that anyone using the Kerberos security features in TCP/IP has expert knowledge of Kerberos.

For information about using the Kerberos TELNET client, refer to the HP TCP/IP Services for OpenVMS User's Guide.

15.1.7.1 Configuring the Kerberos TELNET Server

TCP/IP Services supports a separate Kerberos TELNET server, in addition to the standard TCP/IP TELNET server.

You can enable the TELNET server with Kerberos support by selecting the Kerberos TELNET server from the TCPIP$CONFIG.COM command procedure, as described in the HP TCP/IP Services for OpenVMS Installation and Configuration guide.