The larger the inactivity timer, the longer FTP maintains sessions without timing out. Excessive inactive sessions might slow down performance, degrade security, or prevent other users from establishing sessions.

To increase the inactivity timer, change the value of the TCPIP$FTPD_IDLETIMEOUT logical name (default is 15 minutes).

Example:

$ DEFINE TCPIP$FTPD_IDLETIMEOUT 600

A.7 Printing: LPD

For LPD troubleshooting, use the following tools:

• Log file TCPIP$LPD_RCV_STARTUP.LOG
  All LPD receiver diagnostic messages are written to this file.
• Logical names TCPIP$LPD_RCV and TCPIP$LPD_DEBUG
  These system logical names can turn on all LPR/LPD diagnostic tests. They track what the LPD client sends compared to what the receiver receives.

The TCPIP$LPD_DEBUG and TCPIP$LPD_RCV logical names are independent, as follows:

• LPD_DEBUG
  • Applies to outbound jobs (LPD client).
  • Writes diagnostics to an LPD queue's log file.
• LPD_RCV
  • Applies to inbound jobs (LPD server).
  • Writes diagnostics to the receiver's log file, TCPIP$LPD_RCV_LOGFILE.LOG.

To define TCPIP$LPD_DEBUG and TCPIP$LPD_RCV, enter:

$ DEFINE /SYSTEM LPD_RCV 7 $ DEFINE /SYSTEM LPD_DEBUG 7

If you have problems, turn on all the LPR/LPD diagnostics. Define TCPIP$LPD_DEBUG and TCPIP$LPD_RCV as 15. However, leaving these diagnostics on during normal use might impact the performance of LPD and produce large log files.

TCPIP$LPD_DEBUG and TCPIP$LPD_RCV are bit-mapped values. The low-order three bits turn on all diagnostics generated by either the sender or the receiver.

If you set the fourth bit, the LPD symbiont logs each buffer that it sends over the TCP/IP link, and the LPD receiver logs each buffer that it receives from the TCP/IP link. The log files let you see exactly what the LPD is sending (for outbound jobs) and receiving (for inbound jobs).

To set the fourth bit, enter:

$ DEFINE /SYSTEM LPD_RCV 8 $ DEFINE /SYSTEM LPD_DEBUG 8

A.8 Printing: TELNETSYM

To avoid potential problems with TELNET printing, be aware of the following situations and guidelines.

A.8.1 Using TCPIP$TELNETSYM for the First Time

If you use the public domain TELNET symbiont and want to switch to the TELNET symbiont, remember to change the value of /PROCESSOR on the TELNET symbiont queues. When you do this, include any command procedures that start up the queues. Change:

/PROCESSOR=TELNETSYM

to:

/PROCESSOR=TCPIP$TELNETSYM

A.8.2 Printing to DIGITAL Terminal Servers

When you print to a DECserver system, ensure that:

• Input flow control for the port you are printing to is set to DISABLED. Enter:

  > CHANGE PORT port INPUT FLOW DISABLED

• The TELNET server for the terminal server port is properly set. Enter:

  > CHANGE PORT port - _> TELNET SERVER NEWLINE TO HOST <CRLF>

When you print a job to a TELNETSYM queue, a link must be established between the queue and the printer. If there is high contention for the printer, it might be busy, causing the first attempt at link-establishment to fail.

TELNETSYM continues to try to establish the link, according to the retry interval logical name TCPIP$TELNETSYM_RETRY_INTERVAL. Until the link is established, the execution queue stalls. When the link comes up, the job prints. A "stalled" TELNETSYM queue is not necessarily an error.

If the queue stalls while printing a job, the printer is probably out of paper.

If TELNETSYM causes a print queue to fail, reset the queue. Enter the following command:

$ STOP /QUEUE /RESET queue_name

A.8.4 TELNETSYM Logging

OPCOM messages sent by TELNETSYM include the name of the execution queue. In addition, each TELNETSYM queue has a log file named TCPIP$TELNETSYM_qname.LOG.

If you define the logical name TCPIP$TELNETSYM_SCRATCH, the log files are stored in the TCPIP$TELNETSYM_SCRATCH directory.

If you do not define TCPIP$TELNETSYM_SCRATCH, the log files go into TCPIP$LPD_SPOOL.

If TCPIP$LPD_SPOOL is not defined, the log files go into SYS$SPECIFIC:[SYSEXE].

A.8.5 Format Problems

To track down problems with wrong formatting on the printed page (for example, "garbage" for a graphics file or unwanted blank pages), use Bit 2 of the the TELNETSYM logical name TCPIP$TELNETSYM_DEBUG. Defining TCPIP$TELNETSYM_DEBUG helps determine whether the source of the problem is TELNETSYM. Follow these steps:

1. Define TCPIP$TELNETSYM_DEBUG as 4 in the system table. Enter:

   $ DEFINE /SYSTEM TCPIP$TELNETSYM_DEBUG 4 $ STOP /QUEUE /RESET TELNETSYM_qname $ START /QUEUE TELNETSYM_qname

2. Print the job that does not print properly.
3. Look at the TELNETSYM log file for the queue.
   This file has messages that show you every byte sent over the link to the printer, such as control characters and setup/reset modules.
   If the raw TCP logical name is not defined, you see doubled IAC characters (hexadecimal FF).
   If you print /PASSALL with the raw TCP logical name not defined, the job starts with the TELNET options negotiation sequence "do binary, will binary".
4. Identify the problem. Either fix it or report it to your DIGITAL support representative.
5. Start the TELNETSYM queue.

TELNETSYM logs control characters and nonprinting characters by preceding the hexadecimal value of the byte with a backslash. For example, this sequence:

Carriage Control Form Feed Carriage Control Line Feed Tab the text "Use Your Screen Saver to Conserve Energy." Carriage Return Line Feed

is logged as:

\0D\0C\0D\0A\09Use Your Screen Saver to Conserve Energy.\0D\0A

The "do binary, will binary" sequence starting off a /PASSALL job appears as:

\FF\FD\00\FF\FB\00

A.9 PPP

To troubleshoot PPP problems, check the configuration against the following criteria:

• Does the cable work?
• Is the modem configured correctly? Are the DIP switch settings on the modem set correctly? Are the modem's software settings correct?
• Are all clients and dialup providers using unique addresses?
• If you detect trouble with the modem, try switching to another modem.
• If you are having trouble establishing a PPP connection, try entering the SET HOST/DTE command then log in to the system (a basic test to make sure you can log in to the system). Then test to make sure the modem commands work. Try dialing out; does the modem answer?
• Enter the DCL command REPLY/ENABLE to receive OPCOM messages. (Requires OPER privilege.)
• After a software upgrade, be sure to reboot and restart TCP/IP Services.
• Terminate any leftover virtual terminal sessions.
• Be sure ipforwarding and ipgateway are set to 1:

  $ sysconfig:==$SYS$SYSTEM:TCPIP$SYSCONFIG.EXE $ sysconfig -r inet ipforwarding=1 $ sysconfig -r inet ipgateway=1

• When you try to set host to the OpenVMS system, you might be exceeding the security level. To check and then delete, if necessary, enter the following commands (requires SECURITY privilege):

  $ SHOW INTRUSION $ DELETE/INTRUSION your_information

• You might not be able to ping the system if the serial line is tied up with a large FTP operation.
• Make sure you specify the /TYPE_AHEAD qualifier when you enter the SET TERMINAL command to set up an asynchronous port.
• If your host is configured as an OpenVMS PPP client, you need NETMBX and OPER privileges to establish a successful connection and display OPCOM messages. Without these privileges, error messages similar to the following display after you enter the CONNECT command:

  $ PPPD PPPD> CONNECT %PPPD-I-CONNECTTERM, converting connection on device _TTA0: to a Point-to-Point connection %PPPD-E-CALLBACKERR, error calling network callback %SYSTEM-F-NOPRIV, insufficient privilege or object protection violation %PPPD-F-ABORT, fatal error encountered; operation terminated

  
  Note that the extraneous data in this sample is an ASCII representation of IP packets transmitting over the open line.
  PPP sets up a default route on the client if one did not exist. Typically a default route exists if another interface exists on the client.

To debug SLIP problems, use the following methods:

• From another window, enter a TCPTRACE command to see packets going in and out of the system.
• Watch the modem's Send and Receive data LEDs as you attempt communication with the TELNET or PING commands.
• Display a count of the packets being sent and received on the problem interface, in full screen format, updated every second. Enter:

  TCPIP> SHOW INTERFACE SLn /CONTINUOUS=1

To narrow down the cause of an SMTP problem, follow these steps:

1. Check the directory SYS$SPECIFIC:[TCPIP_SMTP] for the following log files:
   • TCPIP$SMTP_LOGFILE.LOG
     Monitors the symbiont (queue activity).
   • TCPIP$SMTP_RECV_LOGFILE.LOG
     Is created with every message received.
   
   Purge this directory regularly.
2. Use the logical name TCPIP$SMTP_LOG_LEVEL debugging tool to define one of the following values:

   Value	Description
   0 or undefined	No logging
   1	Log daily activities (similar to UNIX sendmail)
   2	Log relevant headers
   5	Log full debugging messages (same as smb_debug)

3. Check the mail in the TCPIP_SMTP account.
   Lost mail is delivered to the Postmaster's mailbox (TCPIP_SMTP). Forward SMTP mail to the SYSTEM account for monitoring. By default, there is no remote login allowed into TCPIP_SMTP.
4. Check the directory SYS$SPECIFIC:[TCPIP_SMTP] for lost mail.
   If a mail message was undeliverable, and the error message was also undeliverable, an SMTP temporary file is placed in this directory, not in the queue.
5. Check the consistency of the SMTP queues against the directories with the SMTP utility files.
   Enter the ANALYZE MAIL command (see Section A.11.1).

The ANALYZE MAIL command verifies the consistency of the SMTP queues with SMTP control files. ANALYZE MAIL does the following:

• It checks that all the current entries in the SMTP queues have a supporting control file in the mail directory of a user. You can specify a user or analyze the mail of all users.
• It checks that there are no lost control files in the SMTP working directory.
• The /DELETE qualifier deletes each control file lacking a corresponding queue entry.
• The /REPAIR qualifier fixes these errors:
  • Resubmits for delivery each valid control file in the SMTP directory with no entry in an SMTP queue.
  • Deletes each invalid control file (fails the internal consistency check) and the corresponding queue entry.
  • Either requeues or deletes messages placed on hold.

Example 1:
This command encounters a problem, displays a description and solution, and then requests confirmation before fixing each record.

TCPIP> ANALYZE MAIL /REPAIR /CONFIRM %TCPIP-E-ANA_SUP_BADIICGSIZE, Problem: Bad initial inode cell group size: bad_value Solution: Will be replaced by default size: good_value CONFIRM [Y/N/G]:

Example 2:
This command creates a summary of SMTP entries and control files for user DRAKE.

TCPIP> ANALYZE MAIL DRAKE %TCPIP-I-ANA_RUNING, ANALYZE runs on node DODO %TCPIP-I-ANA_NOENTR, no queue entry found for file NEST3$:[DRAKE]93042311394417_DRAKE.UCX_DODO;1 %TCPIP-I-ANA_COMPLE, ANALYZE completed on node DODO %TCPIP-I-ANA_FEPAIR, found 0 file-queue entry pairs %TCPIP-I-ANA_DELQEN, deleted 0 queue entries %TCPIP-I-ANA_FILNOQ, found 1 files with no queue entries %TCPIP-I-ANA_FILHLD, holding 0 files in directory %TCPIP-I-ANA_FILDEL, deleted 0 files from the Postmaster directory %TCPIP-I-ANA_SUBFIL, submitted 0 files to the generic queue %TCPIP-I-ANA_FILACE, encountered 0 file access errors %TCPIP-I-ANA_NONCFF, found 0 non-unknown files in Postmaster directory %TCPIP-I-ANA_FILCOR, found 0 corrupted CF files in Postmaster directory

Example 3:
This command:

• Creates a summary of SMTP entries and control files for user DRAKE.
• Requeues control files lacking corresponding queue entries.
• Deletes control files created before November 24, 1997.

TCPIP> ANALYZE MAIL DRAKE /REPAIR /DELETE=BEFORE=24-NOV-1997

A.12 SNMP

To make sure that SNMP functions correctly on your system, follow the guidelines in this section.

A.12.1 Guidelines for Enabling Set Commands

To ensure that the master agent processes SNMP set commands from SNMP clients correctly:

• On an OpenVMS server, configure SNMP with the /FLAGS=SETS qualifier to the management command SET CONFIGURATION SNMP or by enabling SNMP during the configuration procedure (TCPIP$CONFIG) and answering YES to the question Do you want to allow clients modify (SET) access?
• Make sure that the SNMP client is configured to enter set commands correctly and to handle data types and sizes as required to change the values of eSNMP variables.
• Make sure that the SNMP client uses a valid community name that has write access on the OpenVMS SNMP server.
• Make sure that the eSNMP 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.

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

• One of conditions listed above was not met.
• The commmunity name is invalid. Check to make sure uppercase or lowercase letters are specified correctly.
• SNMP is not running on the system.
• There are network, delay, or timeout problems.
• Communities with write access are not defined on the server.
• The SNMP configuration is correct, but SNMP was not restarted after changes were made.

When you enter the SET CONFIGURATION SNMP command and qualifiers, take the following information into consideration:

• SNMP functions without the need to configure flags for set commands (/FLAGS=SETS) and authentication traps (FLAGS=AUTHEN_TRAPS). Note that when you enter the SHOW CONFIGURATION SNMP command, the keywords associated with these flags are displayed as follows:

  Flags: AuthenTraps Sets

• The /FLAGS=SETS qualifier is required to enable SNMP client set command requests. If set commands are not enabled, the client receives a "no such variable" message, even if WRITE requirements are met. (See the command guidelines in Section A.12.2.)
• The /FLAGS=AUTHEN_TRAPS qualifier allows the SNMP master to send trap messages to specified trap community addresses when MIB access with a community name is not supported by the agent. This also allows the master to send trap messages when the agent does not grant the host the access required for a request (for example, READ for a Get request or WRITE for a Set request).
• If you do not include the /FLAGS=SETS, /FLAGS=AUTHEN_TRAPS, or /LOCATION=options qualifiers, SNMP functions but the following error message displays when you enter the SHOW CONFIGURATION SNMP/FULL command. For example:

  TCPIP> SHOW CONFIGURATION SNMP/FULL %TCPIP-E-CONFIGERROR, Error processing CONFIGURATION request -RMS-E-RNF, record not found Community Type Address_list public Read 0.0.0.0

• If you do not include the /LOCATION=options or /CONTACT=name qualifier, SNMP functions but the following information displays when you enter 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)

  
  Note that if you enabled SNMP when you had a previous version of TCP/IP Services installed, you might need to specify NOTHIRD through NOSIXTH to remove existing location information.

• 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.

The SNMP MIB browser supplied with TCP/IP Services returns the following error messages. You might see other messages, depending on your configuration or related network operation.

Invalid host argument: agent,

Invalid operation,

Invalid wait_seconds_max argument: 0,

Invalid max_repetitions argument: 0,

Invalid port argument: 0,

Invalid version argument: 0,

Invalid variable list,

The following sections describe ways to troubleshoot problems associated with using the POP server. Some of these include:

• Reviewing error and OPCOM messages sent to the log file
• Simulating a POP client and entering XTND commands

Many of the problems encountered using POP pertain to failed or misinterpreted commands or authorization errors. Therefore, you should review the messages provided by the POP server as the first step toward solving problems.

The POP server logs command error and OPCOM (authorization) messages. By default, the POP server sends informative error messages to the client about specific errors. If the SERVICE database log option REJECT is set, the POP server sends OPCOM messages when it rejects POP client commands due to authorization failures. These errors include the receipt of a client's USER command with an invalid user name or a PASS command with an invalid password.

By default, OPCOM messages are displayed on the client system and are listed in the log file. To disable OPCOM messages, disable the REJECT logging option for the POP service as follows:

$ TCPIP SET SERVICE POP/LOG=NOREJECT