______________________________________________ DECserver 300 Version 2.2A DECserver 700 Version 1.1A DECserver 90TL Version 1.1A Release Notes for OpenVMS February 1994 This version of the DECserver Software Release Notes contains information about enhancements, known problems, and workarounds in the DECserver 300 Version 2.2A software, the DECserver 700 Version 1.1A software, and the DECserver 90TL Version 1.1A software.. The Release Notes should be distributed to the server manager(s), load host system manager(s), and any other individuals responsible for server maintenance. SOFTWARE VERSION: DECserver 300, Version 2.2A for OpenVMS DECserver 700, Version 1.1A for OpenVMS DECserver 90TL, Version 1.1A for OpenVMS ________________________________________________________________ Contents Contents Contents 1 DECserver 300 V2.2A/DECserver 700 V1.1A/DECserver 90TL V1.1A Specifics............ 1 1.1 Identification of Software Version ........... 1 1.2 Additional DCL files for DECserver Management.................................... 1 1.2.1 When to Use the New DCL Command Files...... 2 1.2.2 DSV$CONFIGURE.COM.......................... 2 1.2.3 DSVCONFIG_IMPORT.COM....................... 4 1.2.4 DSV$STARTUP.COM............................ 7 1.2.5 How to Use the New DCL Command Files....... 7 1.2.6 Additional Notes on the New DCL Files...... 8 1.3 DNS Changes .................................. 8 1.4 Bugfixes ..................................... 9 2 Full SNMP Support............................... 15 3 How to Report a Problem......................... 16 3.1 Documentation Problems ....................... 16 3.2 Severe Errors ................................ 17 4 Known Problems.................................. 18 4.1 VMS INSTALLATION GUIDE ....................... 18 4.2 SNMP ......................................... 18 4.3 SLIP ......................................... 18 4.4 TELNET REMOTE CONSOLE ........................ 19 4.5 PING ......................................... 19 4.6 DNS .......................................... 19 4.7 TELNET ....................................... 20 4.8 Other Known Problems ......................... 20 5 Potentially Confusing Behavior.................. 22 6 Known Problems With Other Telnet Implementations................................. 25 7 Modems.......................................... 28 7.1 Recommended Configuration Characteristics .... 29 iii __________________________________________________________ February 1994 February 1994 February 1994 Digital Equipment Corporation 1994. All Rights Reserved. ___________________ [TM]ULTRIX is also a trademark of Digital Equipment Corporation [TM]MS-DOS is a trademark of Microsoft Corporation This document was prepared using VAX DOCUMENT, Version 2.1. 1 DECserver 300 V2.2A/DECserver 700 V1.1A/DECserver 90TL V1.1A 1 DECserver 300 V2.2A/DECserver 700 V1.1A/DECserver 90TL V1.1A 1 DECserver 300 V2.2A/DECserver 700 V1.1A/DECserver 90TL V1.1A Specifics Specifics Specifics The purpose of this section is to describe differences between this release and the previous release of the DECserver software. 1.1 Identification of Software Version 1.1 Identification of Software Version 1.1 Identification of Software Version In keeping with past naming conventions, the DECserver software image included in this release kit is titled MNENG1.SYS. This may cause some confusion in environments having multiple load hosts unless all load hosts are updated with this version of software. To verify that a server has been loaded with the patched software, connect to the server and enter the SHOW SERVER command at the local prompt. Local> SHOW SERVER This will display server characteristics. The first line of the display contains revision information and will indicate that the DECserver software is "V2.2A BL45-4" for the DECserver 300, "V1.1A BL45-12" for the DECserver 700, or "V1.1A BL45-11" for the DECserver 90. 1.2 Additional DCL files for DECserver Management 1.2 Additional DCL files for DECserver Management 1.2 Additional DCL files for DECserver Management Previous versions of the DECserver software kit contained several DCL command files intended to facilitate the management of DECservers. Among these files was DSVCONFIG.COM which offered a semi-automated method of modifying the DECnet database. As changes were being made to the NCP database, the information was also being stored in a data file DSVCONFIG.DAT. This information could be used at a later time to restore the database. Like previous kits, this kit contains DSVCONFIG.COM. However, it also contains three new DCL command files for use on systems supporting DECnet/OSI. The new files are: o DSV$CONFIGURE.COM o DSVCONFIG_IMPORT.COM o DSV$STARTUP.COM 1 1.2.1 When to Use the New DCL Command Files 1.2.1 When to Use the New DCL Command Files 1.2.1 When to Use the New DCL Command Files DSV$CONFIGURE.COM DSV$STARTUP.COM, and DSVCONFIG_ IMPORT.COM are intended for installations which are not using TSM as a management tool meet one or both of the ___ and following criteria: o DECnet/OSI is supported o The DECserver Network Access Software kit has been previously been installed DECnet/OSI uses NCL to maintain the MOP database. DSVCONFIG.COM does not support NCL commands but DSV$CONFIGURE.COM does. DSV$CONFIGURE.COM is backward compatible in that it also supports NCP for DECnet Phase IV but there is no requirement for DECnet Phase IV users to transition from DSVCONFIG.COM or TSM for DECserver management. DECserver Network Access Software is a Digital product used on DS700s and DS90Ms having more than 1 megabyte of memory. It is also used on the DECserver 900TM. It is similar to the DECserver software but offers more functionality and protocols. In situations where both products exist on the same load host, all DECserver management must use the Network Access Software tools. 1.2.2 DSV$CONFIGURE.COM 1.2.2 DSV$CONFIGURE.COM 1.2.2 DSV$CONFIGURE.COM DSV$CONFIGURE.COM is a DCL command file similar to DSVCONFIG.COM in that it facilitates the addition and modification of DECserver information by acting as a user interface to either NCP (DECnet Phase IV) or NCL (DECnet/OSI). The following example shows how to invoke DSV$CONFIGURE.COM. $ @sys$common:[decserver]dsv$configure %DSV-I-IDENT, executing DSV$CONFIGURE version V1.0-009 -DSV-I-HELP, type ? at any time for help DSV> ? The valid commands at the DSV> prompt are: 2 ADD - Add a server to the system MODIFY - Modify an existing server's information SET - Synonym for MODIFY DELETE - Remove a comm. server from the system LIST - Display information on one or all server SHOW - Synonym for LIST CONNECT - Connect to a server via remote console USE - Synonym for CONNECT EXIT - Exit this procedure DSV> The following example shows the ADD command on a DECnet /OSI system. In this example, the symbol [RETURN] without a value indicates the selection of the default value. $ @sys$common:[decserver]dsv$configure.com %DSV-I-IDENT, executing DSV$CONFIGURE version V1.0-009 -DSV-I-HELP, type ? at any time for help DSV> add _Server Name: brds1 _Ethernet Address: 08-00-2b-25-0d-29 _Server Type: ds300 _Service Circuit [SVA-0]:[RETURN] _Maintenance Password [none]:[RETURN] _Dump File [MOP$LOAD:DS3BRDS1.DMP]:[RETURN] _Load Image [MOP$LOAD:SH1601ENG.SYS]:[RETURN] Node Volatile Characteristics as of 7-FEB-1994 17:56:38 Remote node = 13.8 (BRDS1) Service circuit = SVA-0 Service password = 0000000000000000 Hardware address = 08-00-2B-25-0D-29 Load file = MOM$LOAD:SH1601ENG.SYS Dump file = MOM$LOAD:DS3BRDS1.DMP DSV> EXIT $ 3 In addition to modifying the DECnet database, the DECserver information is also being stored in DSV$SERVER_ DEFINE.COM in the form of NCP or NCL commands. DSV$SERVER_ DEFINE.COM can then be invoked, if the need arises, to restore the DECserver information to the DECnet database. Note that DSV$CONFIGURE.COM should not be used if TSM is being used to manage the DECserver database. 1.2.3 DSVCONFIG_IMPORT.COM 1.2.3 DSVCONFIG_IMPORT.COM 1.2.3 DSVCONFIG_IMPORT.COM This DCL command file is used when transitioning from DECnet Phase IV to DECnet/OSI. Its purpose is to import the DECserver information stored in DSVCONFIG.DAT to DSV$SERVER_DEFINE.COM. DSV$SERVER_DEFINE.COM is a DCL command file created and modified by DSV$CONFIGURE.COM. It contains either the NCP (DECnet Phase IV) or NCL commands (DECnet/OSI) required to restore DECserver information in the DECnet database. The following example shows DSVCONFIG_IMPORT.COM being used. In this example, there is no data in DSVCONFIG.DAT so DSVCONFIG_IMPORT.COM simply prints several informational messages and exits. Note that in this case no changes are made to either the DECnet database or DSV$SERVER_DEFINE.COM. @sys$common:[decserver]dsvconfig_import.com Introduction Previous versions of the DECserver software kit included a DCL procedure, DSVCONFIG.COM, which was used to store information about communications servers in a data file called DSVCONFIG.DAT. Recently DSV$CONFIGURE.COM has been introduced to provide similar functionality for systems which support DECnet OSI. This command file imports the DSVCONFIG.DAT file into a file titled DSV$SERVER_DEFINE.COM SYS$SYSROOT:[DECSERVER]DSVCONFIG.DAT does not exist. There is nothing to import. Import not performed $ 4 In the following example, DSVCONFIG.DAT contains data which is ported to DSV$SERVER_DEFINE.COM. In this example, DSV$CONFIGURE.COM is being used to create the initial version of DSV$SERVER_DEFINE.COM. Note that once the information has been ported, the DCL script is re-named to DSVCONFIG_IMPORT_COM.OLD. This is done because invoking DSVCONFIG_IMPORT.COM multiple times could result in duplicate nodes being added to DSV$SERVER_DEFINE.COM. This would not adversely affect the DECnet database but it would increase the execution time of DSV$SERVER_DEFINE.COM and DSV$CONFIGURE.COM $ @sys$common:[decserver]dsvconfig_import.com Introduction Previous versions of the DECserver software kit included a DCL procedure, DSVCONFIG.COM, which was used to store information about communications servers in a data file called DSVCONFIG.DAT. Recently DSV$CONFIGURE.COM has been introduced to provide similar functionality for systems which support DECnet OSI. This command file imports the DSVCONFIG.DAT file into a file titled DSV$SERVER_DEFINE.COM - CAUTION - An affirmative answer to the following question will invoke SYS$SYSROOT:[DECSERVER]DSV$CONFIGURE.COM to import the data found in SYS$SYSROOT:[DECSERVER]DSVCONFIG.DAT to SYS$MANAGER: DSV$SERVER_DEFINE.COM. Once the information has been imported, this command file will be renamed to SYS$COMMON:[DECSERVER] DSVCONFIG_IMPORT_COM.OLD. The use of DSVCONFIG.COM should then be discontinued. Do you want to continue importing DSVCONFIG.DAT to the new format?: y %DSV-I-IDENT, executing DSV$CONFIGURE version V1.0-009 Node Volatile Characteristics as of 28-JAN-1994 16:16:57 Remote node = 13.22 (BRDS1) 5 Service circuit = SVA-0 Service password = 0000000000000000 Hardware address = 08-00-2B-25-0D-29 Load file = MOM$LOAD:SH1601ENG.SYS Dump file = MOM$LOAD:DS3BRDS1.DMP %RENAME-I-RENAMED, SYS$COMMON:[DECSERVER]DSVCONFIG_IMPORT.COM;1 renamed to SYS$COMMON:[DECSERVER]DSVCONFIG_IMPORT_COM.OLD;2 Import complete $ Prior to making any changes, DSVCONFIG_IMPORT.COM will verify that DSV$DEFINE_SERVER.COM does not already exist. If DSV$DEFINE_SERVER.COM does exist, an informational message will be printed and you will be prompted to continue. At this point you should use DSV$CONFIGURE.COM to list the DECserver information present in DSV$DEFINE_ SERVER.COM. Next, use DSVCONFIG.COM to remove any servers already found in DSV$SERVER_DEFINE.COM from DSVCONFIG.DAT. Then restart DSVCONFIG_IMPORT.COM. The following example shows what happens when DSVCONFIG_IMPORT.COM detects the existence of DSV$SERVER_DEFINE.COM. $ @sys$common:[decserver]dsvconfig_import.com Introduction Previous versions of the DECserver software kit included a DCL procedure, DSVCONFIG.COM, which was used to store information about communications servers in a data file called DSVCONFIG.DAT. Recently DSV$CONFIGURE.COM has been introduced to provide similar functionality for systems which support DECnet OSI. This command file imports the DSVCONFIG.DAT file into a file titled DSV$SERVER_DEFINE.COM File SYS$COMMON:[SYSMGR]DSV$SERVER_DEFINE.COM already exist. This indicates DSVCONFIG.DAT may have already been imported. Do you wish to continue?: n Import not performed $ 6 1.2.4 DSV$STARTUP.COM 1.2.4 DSV$STARTUP.COM 1.2.4 DSV$STARTUP.COM This procedure includes the SYS$SYSROOT:[DECSERVER] directory specification in the MOM$LOAD or MOP$LOAD logical name search list and loads all communications server information into the volatile MOP database. DSV$SYSTARTUP.COM should be included in the system startup file. If you have other directories of MOP load images or dump files, be sure to place the customized DEFINE/SYSTEM commands for MOM$LOAD, MOP$LOAD, and/or MOP$DUMP ahead of the execution of DSV$STARTUP.COM. 1.2.5 How to Use the New DCL Command Files 1.2.5 How to Use the New DCL Command Files 1.2.5 How to Use the New DCL Command Files To use the new DECserver management tools, do the following: Install the software kit using the normal DECserver installation procedure. The installation is similar to previous DECserver software kit installations. For systems using DECnet/OSI, the instructions displayed following the installation differ from those displayed on DECnet Phase IV systems. The new instructions direct you to modify the system startup file to include DSV$STARTUP.COM and to configure the DECservers by invoking DSVCONFIG_IMPORT.COM and, if new servers are being added, DSV$CONFIGURE.COM. Do the following: 1. Invoke DSV$STARTUP.COM to create the required directories. If this step fails, correct the problem and repeat this step before proceeding. 2. Invoke DSVCONFIG_IMPORT.COM to port the data contained DSVCONFIG.DAT to DSV$SERVER_DEFINE.COM. Note that if the port succeeds, DSVCONFIG_IMPORT.COM will be renamed to DSVCONFIG_IMPORT_COM.OLD. This is done to prevent you from doing the import more than once. 3. Invoke DSV$CONFIGURE.COM to add any DECservers which were not included in DSVCONFIG.DAT 4. Verify that the new DECserver image can be downline loaded by booting one DECserver. Refer to the section on DECserver specifics to determine if the proper image has been loaded. 7 5. Modify the system startup file as directed by the installation procedure. 1.2.6 Additional Notes on the New DCL Files 1.2.6 Additional Notes on the New DCL Files 1.2.6 Additional Notes on the New DCL Files You should be aware of the following: 1. The use of DSVCONFIG.COM, DSV$CONFIGURE.COM, and TSM as DECserver management tools are mutually exclusive. 2. DSVCONFIG.COM or DSV$CONFIGURE.COM can fail in such a way that information would not be added to the DECnet database. If this should happen, verify that the local database (DSVCONFIG.DAT for DSVCONFIG.COM or DSV$SERVER_DEFINE.COM for DSV$CONFIGURE.COM) has not been updated with the DECserver information. Search the local database by using the appropriate list command for the configurator being used. 3. The default image name supplied by DSV$CONFIGURE.COM is WWENG1.SYS for the DS700 and MNENG1.SYS for the DS90TL and DS90M. Be sure to specify a load image name if the Network Access Software is to be loaded. 4. This kit contains a new version of DSVCONFIG.COM which now allows server names to begin with any alphabetic character. The previous version of DSVCONFIG.COM did not allow server names which began with either A or Z. 1.3 DNS Changes 1.3 DNS Changes 1.3 DNS Changes There are two new values accepted by the SET|DEFINE| CHANGE INTERNET NAME RESOLUTION MODE command in this release. These new modes are (1) STUB and (2) SLAVE. These are in addition to the existing modes LOCAL, REMOTE, and ORDERED. The STUB resolution mode relies entirely on recursive name service from the internet name servers that are locally configured. This means name servers that are entered as SET|DEFINE|CHANGE INTERNET NAMESERVER commands. The DNS cache is disabled, in that no internet name servers or hosts will be learned. In addition, locally configured entries in the DNS cache, i.e. those entered by SET|DEFINE|CHANGE INTERNET HOST commands, are ignored. STUB mode requires that the locally configured name server(s) act as forwarders and provide recursive name resolution service. 8 SLAVE mode behaves the same as STUB mode, except that in SLAVE mode, locally configured entries in the DNS cache, i.e. those entered by SET|DEFINE|CHANGE INTERNET HOST commands, are utilized and will over-ride responses from the name servers, if those responses are in conflict with the locally configured host address information. The DNS cache remains disabled with respect to learned host addresses, however. 1.4 Bugfixes 1.4 Bugfixes 1.4 Bugfixes This section lists problems fixed in this release of the DECserver software. Note that the term "memory leak" is used in several of the following problem descriptions. "Memory leak" refers to an irreversible reduction in the size of the server's free memory pool. It is from this pool that the server allocates the memory required to process user commands and connect requests. As the pool diminishes, the server's performance degrades. Please note that following list of bugfixes encompasses all the fixes added since the last release. o TGV/Multinet print spooler requests to a Telnet Listener were aborted and not resubmitted to TGV's print spooler if the target port on the server was busy. To remedy the situation, a change has been made to the software such that the server will ignore Telnet connection requests to busy ports. TGV will retry the connection under this condition and eventually time out and resubmit the job to the spooler if the port remains busy. It is expected that other host implementations will also resubmit the jobs under the new patch conditions. o Reading the server counters via the MOP protocol caused a memory leak. The source of the leak has been found and corrected. o Occasionally ports running multisessions caused the server to crash with various crash codes. In most instances, the crash code was related to memory allocation and deallocation failures (crash code 968 through 975). The problem was induced when sessions failed to terminate properly due to a loss of communication between the server and the terminal. The 9 problem has been corrected by forcing the completion of session termination in cases where the server does not receive a response to a CLOSE SESSION command. o Ports running multisessions caused the server to crash when switching between sessions. The crash would only occur if the port had it's DEFAULT PROTOCOL set to ANY and an attempt was made to connect to a host with a name greater than 16 characters. For example the connect command: Local> Telnet myhost.mysite.mycompany.com issued in TD/SMP session 1 would cause the box to crash if the user switched to TD/SMP session 2 and then switched back to session 1. This version of software corrects the problem. o On ports with MODEM CONTROL or SIGNAL CONTROL enabled, a reverse LAT connect request made within 5 seconds of the port being logged out would fail. All subsequent connect requests made within 5 seconds of each other would also fail. The problem was caused by a 5 second delay used by the server to allow the port's modem signals to cycle. During this period the server would begin the process of connecting to the port but would not respond to the host causing the host to time out and re-issue the request with a new request ID. After 5 seconds, the server would respond but would use the original request ID causing the host to reject the connection. Rejecting the connection would cause the 5 second timer to be restarted. The problem has been fixed by allowing the server to send a reject response to all connect request made during the 5 second modem cycle period. o Host-initiated connections to ports with MODEM CONTROL or SIGNAL CONTROL ENABLED were terminated within 2 minutes of establishing the connection. The problem was caused by an inactivity timer not being cleared properly. This has been fixed. o The SHOW PORT STATUS command did not give remote node or port information on reverse LAT connections. This version of software corrects the problem. 10 o Servers using DNS were unable to resolve Internet host names if the server's learned nameserver data base contained ROOT nameservers and the ROOT nameservers were unreachable. When the learned nameserver data base contained ROOT nameservers, DNS would not query the LOCAL servers. The problem has been fixed. o If a MOP request for Ethernet counters failed due to insufficient memory, the server crashed with a memory parity error (290 crash code). The problem has been corrected. o Successive remote connect requests to 2 or more ports having modem control enabled conflicted with each other, causing one or more of the ports to hang. For example, a host application attempting to connect to modems on ports 2, 3, and 4 could establish all 3 connections but might not be able to communicate with one or more of the modems. A show port status command such as: Local> SHOW PORT 2,3,4 STATUS would indicate that the ports were CONNECTED and that neither the inputs nor the outputs were XOFFed. Attempting to release the port by terminating the connection from the host end would cause the port to enter a DISCONNECTING state. In this state, the only way to free the port would be to log it out from another port or cycle the modem signals. o A memory leak could result from TD/SMP users setting the port's MULTISESSION characteristic to DISABLED. The problem would only occur if the port type was ANSI. o A memory leak could result from aborting a connect request (typically by entering the [BREAK] key) before the connection was fully established. o A TD/SMP problem characterized as either a hung port or spurious output characters being displayed was corrected. The problem would occur when a port with no active sessions was logged out (either by a privileged user at another port or by the INACTIVITY timer). The output queue of TD/SMP commands (the protocol used between the terminal and the server) would get flushed. 11 This would result in various situations including spurious characters output on the screen or potentially hung ports. o On ports with MULTISESSIONS enabled and a preferred session defined, the user could be returned to the local prompt (Local>) after terminating the host session. This has been fixed. o In cases where the user had multiple sessions to a host and was running an application that manipulated the user's terminal screen, switching back and forth between these sessions would cause a protocol error and cause entire LAT circuits to be torn down. This bug has been fixed. o Under certain circumstances, a server port could get into a state where reverse connections would not be accepted (Service in Use), even though the port would appear to be idle. Typically, this would occur only on ACCESS DYNAMIC ports with MODEM (SIGNAL) CONTROL enabled, and involved the use of both host initiated connects (print queues, SET HOST/DTE) and local access attempts within a very short time of each other. o Remote connections to a port with modem control enabled had to wait 2 seconds after the connection was established before sending data or the data would be lost. o There was a problem with CTS output flow control. After a port was logged out, either by modem signals or someone explicitly typing logout, the exact state of output flow control wasn't reset. This could result in a hung port. o Under certain circumstances, sessions that become queued to remote services could become hung. This was a fairly rare condition which would only occur if there already existed a reverse circuit FROM the node that the session is queued to. In other words, if a circuit existed FROM node A to node B, and a user on node B got queued to a service on node A, the session could become hung upon being removed from the queue. This condition has been fixed. 12 o Servers would crash with a 290 (Parity Error) crash code upon reception of ICMP redirect messages. The problem has been corrected. o Use of the port characteristic "DEFAULT PROTOCOL ANY" did not work when trying to connect to a Telnet host from a TD/SMP terminal. If the CONNECT command was issued without the TELNET protocol specifier the TD /SMP session would be terminated during the transition from LAT to TELNET. The failure symptom was the TELNET "Trying..." message followed by the TD/SMP message "Session n terminated normally". This version of software fixes the problem o This version of software fixes a problem chracterized by LAT Reverse/HIC connect requests being rejected with "Service In Use" status even though the port was in the idle state. o The server would periodically get into a state where it would not process forward LAT connect requests but would not print any informational messages or return to the local prompt. Connections established prior to entering this state would remain "Connected" but would not accept input from the user or display host data. The user could return to the local prompt by pressing the BREAK key. The problem was caused by the server's inability to recover from an Underflow in the NI driver. This has been fixed. o The criteria for generating LAT service announcements has been changed to reduce the number LAT multicast messages generated each time a port is logged in or out. Prior to this change, the server would transmit multiple back-to-back service announcements with identical service information. With this version of software, the server will only generate service announcements when there is a change in the local service status. o This version of DECserver software corrects a deficiency in reporting port level data overruns. Prior to this change, certain types of overruns would not be reported to the host. 13 o This version of DECserver software corrects a problem characterized by a Fatal Bugcheck due to an illegal instruction being executed. Occasionally, the server would Bugcheck when someone used the port command DISCONNECT SESSION n, then attempted to connect to a non-existant service. The Bugcheck would only occur if the port had Multisessions enabled and there was host data pending to be output to the port at the time the session was disconnected. o This version of DECserver software allows Telnet users to map the Telnet Break function to the keyboard's [BREAK] key. This expanded functionality is available only to the Telnet Client. o This version of DECserver software fixes a problem characterized by the server crashing with an error code of 0002. The crash would occur if the server attempted to establish a reverse LAT connection while servicing a queued LAT access request which specified a port but not a service. o This release contains a fix in the internet name resolution code related to learned name servers that are not reachable, based on the static internet gateway configuration of the DECserver. A code path existed which allowed the static route testing to be bypassed. The fix described is effective as long as the inability to reach learned name servers is caused by the configuration of the internet gateway table on the DECserver (i.e. based on a static routability test). If the routing restriction is elsewhere in the network (and the DECserver has a default gateway to all subnets), this fix will cease to be effective. In this scenario, the use of either STUB or SLAVE name resolution mode is preferable. 14 2 Full SNMP Support 2 Full SNMP Support 2 Full SNMP Support SNMP (Simple Network Management Protocol) agent software allows the DECserver to be managed by an SNMP network management system. Using the GET, GET-NEXT, SET, and TRAP functions, retrieving and setting information from selected fields in the server and event trapping is possible. This release fully supports the following SNMP specifica- tions and Management Information Bases (MIBs): RFC1155 - Structure for Management Information for TCP/IP-based Internets. RFC1157 - A Simple Network Management Protocol (SNMP). RFC1213 - Management Information Base, MIB II. (obsoletes RFC1158) RFC1316 - Definitions of Managed Objects for Character Stream Devices, The Character MIB. Also supported for backwards compatibility is the obsoleted draft version dated March 19, 1991. RFC1317 - Definitions of Managed Objects for RS232-Like Hardware Devices, The RS232-Like MIB. Also supported for backwards compatibility is the obsoleted draft version dated March 19, 1991. This release supports all SNMP operations: GET, GETNEXT, SET, and TRAP. The SET operation is fully supported providing the ability to modify DECserver parameters as well as create and delete applicable table entries. All supported MIBs will be provided as part of the release kit. Network managers can enroll these MIBs in the appropriate network management station. (snmp_survival.txt) provides ___ ____ ________ _____ The SNMP Survival Guide the system manager with all the necessary information to manage the DECserver with the Simple Network Management Protocol. The guide, which describes the full functional- ity of the SNMP agent, has been included in text format in the release kit. 15 3 How to Report a Problem 3 How to Report a Problem 3 How to Report a Problem If you discover a problem with the operation of the DECserver software, please submit a Software Problem Report (SPR). When completing a SPR, describe one problem at a time. This simplifies record keeping and facilitates a quick response. Keep the description simple yet accurate. Illustrate a general problem with several examples. If a FATAL BUGCHECK error occurs, submit an upline crash dump in your report. Because problems are often difficult to reproduce with different system configurations, please include as much detail as possible when reporting a problem. Define as precisely as possible the state of your system when the problem occurred and indicate the sequence of events or commands that caused the problem. Attempt to reproduce the situation, if it can be reproduced, using the minimum number of steps. If one of your user programs causes a problem in the server and you are unable to send the program to Digital, try to reproduce the problem with a standard utility. If this is not possible, try to describe the program's operation before and after the suspected failure. When a SPR contains concise information about a problem, that problem is more likely to be reproduced and corrected. Please ensure that any questions are direct and simply stated so they can be answered clearly and directly. 3.1 Documentation Problems 3.1 Documentation Problems 3.1 Documentation Problems When describing a problem found in a manual, specify the full title of the manual and identify the appropriate section, table, or page number. Describe what the manual says and also describe the suggested correction. You can use the Reader's Comments Card in the back of the manual. If you are reporting an error with on-line HELP, please identify the full command and screen, and specify TUTORIAL or REFERENCE HELP. 16 3.2 Severe Errors 3.2 Severe Errors 3.2 Severe Errors Severe errors may cause your DECserver terminal server to hang or bugcheck. Terminal server hangs which are not recovered from after 20 seconds, require that the terminal server be powered off and on to restore operation. If this should occur, please describe the operating conditions on the terminal server at the time of the hang. If a FATAL BUGCHECK occurs, a bugcheck message is printed out on the console terminal. The message shows the vital registers at the time of the bugcheck. Normally, an upline crash dump is automatically created when a fatal bugcheck occurs. For other types of problems, a crash dump is also an extremely valuable tool. For example, if you experience a problem that is not easily reproducible, a crash dump will normally allow Digital to fix the problem even though it cannot be reproduced. You can force a CRASH by typing CRASH at the local mode prompt in privileged local mode. A code 300 fatal bugcheck immediately occurs. The location of the crash dump file is determined as follows: o After the terminal server reinitializes, enter privileged local mode and issue a SHOW SERVER STATUS command. Information in this display will indicate the Ethernet address of the dump host. You can identify the dump host from this address. o The crash dump is located in the SYS$COMMON:[DECSERVER] directory on the dump host, and the file name is DS .DMP, where is 3 for DECserver 300, 7 for _______ _ nxxxxxx n DECserver 700, and 9 for DECserver 90TL and is ______ xxxxxx the DECnet node name assigned to the terminal server as defined using the DSVCONFIG configuration procedure. For example, if a DECserver 300 terminal server with node name LAT041 bugchecks, the crash dump will be found on the dump host in SYS$COMMON:[DECSERVER]DS3LAT041.DMP. 17 o Copy the crash dump file to TK50 (preferred), magnetic tape, or another media if these are not available and indicate on a label the format of the copy (COPY, BACKUP, FLX, and so forth). All media sent to Digital will be returned to the sender. 4 Known Problems 4 Known Problems 4 Known Problems The following list includes some of the known problems with this release of the DECserver software. Workarounds are described where applicable. 4.1 VMS INSTALLATION GUIDE 4.1 VMS INSTALLATION GUIDE 4.1 VMS INSTALLATION GUIDE In the section called 'Preparing to Install the Software' the load host available disk space after installation is incorrectly specified as 1300 Kb. It should be 2100 Kb. 4.2 SNMP 4.2 SNMP 4.2 SNMP Please refer to (snmp_survival.txt) ___ ____ ________ _____ The SNMP Survival Guide included in the release kit for a full description of potential problems. 4.3 SLIP 4.3 SLIP 4.3 SLIP o If a port has a configured SLIP Host Address, proper network operation requires that any host attached to that port have that SLIP Host address. In order to avoid configuration errors, we recommend configuring the SLIP ports so that they learn the address of the attached host when that host starts transmitting. o On ports performing address learning, the SLIP host cannot receive IP traffic until the SLIP host has sent an IP packet and the terminal server has successfully learned the Host's address. o If SIGNAL CONTROL is disabled on a dedicated port, the first packet on the port is used by the terminal server to establish the SLIP connection and the packet may be lost during session startup processing. o Each port can have only one Internet address at a time. Multi-homed SLIP hosts are not supported on SLIP lines. 18 4.4 TELNET REMOTE CONSOLE 4.4 TELNET REMOTE CONSOLE 4.4 TELNET REMOTE CONSOLE When memory utilization is at or near 100%, a Telnet remote console connection request to the server may be rejected. 4.5 PING 4.5 PING 4.5 PING o The output from a completed PING is displayed in local mode instead of in session mode. This happens if you start a PING, press the break key, and do not resume the PING session before the test completes. If you remain in session mode, the PING output will be displayed properly. 4.6 DNS 4.6 DNS 4.6 DNS The following are known problems with DNS: o If the DNS cache is full, certain commands invoke an automatic purging of LEARNED entries. If most or all of the entries are LOCAL (SET or DEFINEd entries), then the automatic purging of LEARNED host information will not free much space in memory. One effect of not freeing memory is that the name resolution phase of connecting to an internet host (you see the "Resolving name..." on the screen), when the RESOLUTION MODE is REMOTE or ORDERED, can take a long time. The lack of DNS cache memory causes the code to be extremely time inefficient. Ensure that the cache does not become full of LOCAL entries unless the name resolution mode is LOCAL. o When multiple DNS entries exist for an internet host name (a multi-homed host), the telnet code will only use the first one returned by DNS. There is no load- sharing or failover. Use caution to determine which internet address was at the top of the list. o The DNS host limit (SET INT NAME RES HOST LIMIT) has no effect. The number of hosts that can be held in the DNS cache is determined only by the DNS cache memory size limit, which is 15KB. This memory limit cannot be set or shown. 19 4.7 TELNET 4.7 TELNET 4.7 TELNET o A Telnet Server session to a physical port made through the Telnet Listener responds with WILL-ECHO to a DO-ECHO request from a Telnet Client. However, the terminal server will not actually perform echoing. Echoing of incoming network data is the responsibility of the device attached to the physical port. o When a Telnet Server session to a physical port is being established through a Telnet Listener, the DECserver does not initially announce its intention of performing echoing by sending a WILL-ECHO. Some Telnet Client implementations expect that the Telnet Server will do this so do not explicitly request the partner to enable echoing. The result is that some Telnet Client implementations connecting to a DECserver port end up in Local Echo, and depending on the implementation, may end up in a form of Line buffer mode. If a Line buffer mode results, double echoing of lines can result. To rectify these conditions, use the Telnet Client's interface to change to the desired Telnet mode once the connection is established. 4.8 Other Known Problems 4.8 Other Known Problems 4.8 Other Known Problems o The INITIALIZE command does not properly measure the amount of delay time until the command is invoked. Add one minute to the time you specify to make sure an adequate delay takes place before the server is initialized. o When setting up internet gateways the following considerations must be kept in mind: o The subnet mask must be at least as long as the network class portion. The network class portion will be one, two, or three bytes based on the IP address. o Network 17.1.1.1 mask 255.0.0.0 is illegal since the network portion has extra bits not included in the subnet mask. o All subnet masks must have contiguous ones, starting from the left. 20 o Network xxxx mask 255.255.255.255 is illegal. Use HOST xxxx instead. o Limitations apply to the GET CHARACTERISTIC command procedure which cause it to truncate a port username if the username has embedded spaces. When using TSM$DS3_ V21_GET_CHAR.COM the following guidelines apply: - The port username can be an ASCII character string up to 16 characters, optionally containing up to 4 embedded spaces. A port username containing 4 embedded spaces would therefore contain 5 ASCII substrings which collectively form the port username. For example: define port [n] username "Port 1 A B C" - A port username whose substring components are separated by multiple spaces will be compressed, thus reducing multiple spaces to single spaces between the ASCII substrings. For example: A port username defined with: define port [n] username "A B C D" will result in the command: "define port [n] username "A B C D" being generated and placed in the [server]_SETUP.COM file. - A port username consisting of more than 5 ASCII substrings will be truncated thus leaving the first 5 ASCII substrings to form the port username. Single characters or substrings beyond the 5th substring in the username will be discarded. o This version of software requires more DECserver memory than previous versions due to the additional SNMP support provided. To avoid encountering the following error message: Local -719- Insufficient resources to complete operation the local LAT services database should be limited to 200 nodes. The following priveleged command is used to to set the LAT node limit to 200. 21 Local> SET SERVER NODE LIMIT 200 5 Potentially Confusing Behavior 5 Potentially Confusing Behavior 5 Potentially Confusing Behavior o Flow Control - Enabling XON/XOFF flow control will cause the server to strip flow control characters from the data stream. To prevent the loss of graphics data it may be neccessary to either use an alternate from of flow control or if possible to disable flow control at the server and enable it at the host. - On remote/dynamic access ports Autobaud must be disabled for the session data transpariency mode to be set correctly. This affects both LAT remote/HIC connections and Telnet Listener connections. o Remote Console - When using MOP or Telnet while connected to a Remote Console, you must enter your password within two minutes or the console connection will disconnect. - When using MOP or Telnet while connected to a Remote Console, typing a LOGOUT command at the Local> prompt will cause a disconnect of the console connection. For MOP there may be a small delay before the disconnect is complete. o Telnet Remote Console When a server connected to the Remote Console is booted, and one or more Telnet Listeners are enabled in Permanent database and No Internet address is defined, the console port may receive the message "Local - Telnet Listener Failed to Bind Socket." o A connection to a Remote or Dynamic access DECserver port with output may not completely logout. ______ xoff'd The session remains in "disconnecting" state. The port delays complete logout until the port condition ____ xoff is cleared, presumably by the attached device. This is expected behavior so the DECserver can preserve pending output data. This condition can occur when the user disconnects the session when the port is . ______ xoff'd 22 If the condition on the remote port is not ____ xoff expected to be cleared by the attached device, then the following methods will log out the port: - Manually logout the port from a privileged port on the remote port DECserver. Two logouts may be required. - If the remote port and attached device use DTR/DSR signals and with DSRlogout enabled, the port will be logged out if DSR is toggled by the device. - Port Inactivity Logout timer expires on the remote port. o In order for command line recall to work, the port must be defined as ANSI. The default port type characteristic is now ANSI but it was SOFT in previous revisions. NVRAM parameters are preserved across software updates unless a factory init was done. Therefore, if the server was running an earlier revision, and no factory init was done, the ports will need to be changed to ANSI to enable command line recall and edit. o In the SET PORT or SET SERVER command, you may specify multiple characteristics on one command line. This feature does not apply to any of the new commands (for example, SET INTERNET, SET PORT TELNET). On the new commands, only one characteristic is accepted per command line. o If the DNS cache (what you see when you SHOW INTERNET HOST) is full, certain operations automatically cause the LEARNED information in the cache to be deleted: (a) a CONNECT, OPEN, or TELNET command that needs to resolve a DNS name (i.e. a connect to an internet host by name rather than by address), (b) a SET INTERNET HOST command. o The CLEAR INTERNET HOST {ALL|LEARNED} command has two side effects that other forms of the CLEAR INT HOST command don't have. First, all memory allocated for the learned cache entries is freed. Other versions of the command free only part of the total memory allocated for each such entry. Second, the cache is "primed" from 23 the "hint" database. This priming operation will make learned name server entries reappear in the otherwise emptied cache. o When you issue the SET INT NAMESERVER command, the name server will be queried when the name being resolved "matches" the default domain. If the name server is not authoritative for the default domain, it may delegate to another name server, or it may fail to provide an answer. If it fails, the name resolver in the DECserver will attempt to find another name server (i.e. go "up the chain of command"). Results may be unexpected. Keep this in mind when SET/DEF'ing name servers. The best thing is that the current value of the DECserver's default domain is the same as the domain for which the name server you are adding is authoritative. o In large networks, the data link layer (DLL) counter for User Buffer Unavailable (SHOW COUNTERS) will be expected to show much larger counts than in earlier DECserver versions. Normally this would indicate a performance bottleneck in the receiving node (in this case the DECserver), but this may not be the case. This counter includes LAT Multicast Service Announcements that are thrown away by the DLL-to-LAT interface. There is a specific "throttle" on this interface to limit the Multicast packets in favor of "real" LAT traffic (i.e. user data). These packets were not counted at all in the previous version of DECserver code. o The autoprompt port characteristic behaves differently for LAT and Telnet. In the case of LAT: With Autoprompt enabled and connected to a host, when the connection occurs, the prompt appears. _________ Username: With Autoprompt disabled and connected to a host, when the connection occurs, you must press RETURN to cause the prompt to appear. _________ Username: In the case of Telnet, when the connection occurs, the prompt appears regardless of the state of _________ Username: Autoprompt. o The CPU utilization indication in the Show Server Status screen will reach 100% long before the server has reached its actual load limit. 24 o The CPU memory usage will be higher on an idle box than it was in the previous version due to the reservation of some guaranteed pool space. o If autobaud is enabled in the permanent character- istics, the SHOW PORT CHARACTERISTICS display for a logged off port will show the input speed as 4800, but the output speed will be that specified in the permanent characteristics. 4800 is the autobaud speed and it is only used for receive. The transmit speed takes the value defined in the permanent characteristics. o When connecting to a host using Telnet Remote Console or when PING is used to a remote host, the message "Duplicate IP address received from ARP" may appear at the console port after reboot. This may also be the result of the terminal server ARPing for its own internet address and hearing a response from another host. The implication is that another host is using the same internet address as that of the terminal server. Host internet addresses must be unique. 6 Known Problems With Other Telnet Implementations 6 Known Problems With Other Telnet Implementations 6 Known Problems With Other Telnet Implementations Aborting Output - Forever! After invoking the Abort Output (AO) function, _________ Symptoms: the session appears to be hung - output is never resumed. The Abort Output function could have been invoked by: o entering the AO character (default: ^O) in session mode. o entering another special character which has an automatic AO (default: ^Y) in session mode. o entering "SEND TELNET AO" in local mode. Some foreign vendor Telnet Server implementations ________ Problem: do not reliably respond to the DO Timing Mark request. This request is used to abort output effectively on a Telnet session. 25 __________ Solutions: 1. You can recover by entering local mode and typing "SEND TELNET RESUME OUTPUT". 2. You can avoid the hang for functions which have automatic AO (e.g., IP) by disabling the autoflush feature with respect to that function. For example, SET PORT/SESSION TELNET AUTOFLUSH IP DISABLE disables it for the IP function. Subsequent invocations of the IP function will not include an AO, therefore will not experience the hang. AYT Requires an Extra Character After invoking the Are You There (AYT) function, _________ Symptoms: one character (any character) must be entered before the AYT response can be seen. The AYT function could have been invoked by: o entering the AYT character (default: ^T) in session mode. o entering "SEND TELNET AYT" in local mode. Some foreign vendor Telnet Server implementations ________ Problem: do not respond to the AYT request until a subsequent data character is entered. Enter any character. _________ Solution: Double Login Prompt from ULTRIX When telnetting to an ULTRIX V4.0 (Rev. 179) _________ Symptoms: system, the login: prompt is issued twice. It doesn't appear to matter what you enter in response to the first login: prompt, you will always get a second prompt. A bug in ULTRIX V4.0 (Rev. 179). ________ Problem: Answer the first login prompt (type anything). _________ Solution: Then answer the second with a valid login ID. Then you will be prompted for your password. Proceed normally. Going from Binary to Character Profile 26 A Telnet Client session to a VMS/UCX 5.3 host _________ Symptoms: may not always successfully negotiate a transistion from Telnet Profile Binary to Telnet Profile Character. Although Telnet Port Session Status for Will-Binary and Do-Binary indicates "Disabled," the VMS terminal is left with the PASSALL characteristic, causing unexpected response to certain input characters. This situation can occur when the initial connection establishment to VMS with Telnet Profile Binary is interrupted by doing a [BREAK] to Local during the VMS login, specifically while the account login is performing a SET TERMINAL/INQUIRE. If the Telnet session is changed to Telnet Profile Character and then resumed, Telnet negotiations to disable Binary will complete but the VMS terminal characteristic PASSALL will remain. To rectify this condition, change the VMS _________ Solution: terminal to Iteractive by performing a SET TERMINAL /INTERACTIVE to the VMS prompt once the login is complete. Newline Problem A Telnet connection from the terminal server to _________ Symptoms: an ULTRIX-32 V3.0 (Rev 64) host or V4.1 (Rev 50) host with LOCAL ECHO enabled may not interpret newline correctly. This is because ULTRIX modifies the host stty ________ Problem: newline characteristic from '-nl' to 'nl' when the Telnet Echo option is negotiated between server and ULTRIX. This results in the recognition of only LF to end lines, rather than CRLF. Workaround after a Telnet Ultrix connection _________ Solution: is established: go to server Local mode and change the Telnet session's newline-to-host and newline-from-host characteristic to : SET SESSION TELNET NEWLINE TO HOST SET SESSION TELNET NEWLINE FROM HOST and then resume the session. Double Echo 27 A Telnet session connection from the server to _________ Symptoms: an ULTRIX-32 V4.1 (Rev 50) host with LOCAL ECHO enabled results in both the server and ULTRIX echoing input characters. The server negotiates with ULTRIX to disable echo ________ Problem: and ULTRIX complies. This can be verified by performing a SHOW PORT SESSION STATUS and noting that Do-Echo status transitions from Enabled to Disabled. The server correctly starts to locally echo input characters, however ULTRIX incorrectly continues to echo producing double echoes. If this condition exists, go to server Local _________ Solution: mode and set the Telnet Session to ECHO REMOTE by performing a SET SESSION TELNET ECHO REMOTE. Extra Carriage Return At Login When connecting from the terminal server using _________ Symptoms: telnet to a VMS system (running UCX TELNET Server), you may need to enter a carriage return in order to get the login prompt. This will be corrected in a future release of _________ Solution: UCX. 7 Modems 7 Modems 7 Modems Although the DECserver 300 and DECserver 90TL do not support full modem control, certain Digital Scholar modems have been known to work under certain configurations. Generally, not all features and modes of the Scholar work. Features like Multi-speed protocol and Fallback are not supported. For further information on modem control, refer to the Software Product Description. The following Digital Scholar models are known to have operated with the DECserver in dial-in or dial-out configurations: DECmodem V32 DF242 DF224 DF212 28 7.1 Recommended Configuration Characteristics 7.1 Recommended Configuration Characteristics 7.1 Recommended Configuration Characteristics Use a connection scheme where modem DSR, DTR will be tied directly to the DECserver DSR, DTR respectively: Cable- Digital BC16E 6 conductor cable with MMP connector on each end. Adaptor- Digital H8571-D MMJ to 25-pin D-connector, male. Connect one end of cable to Adaptor. Connect 25-pin adaptor to modem and other end of cable to DECserver port. DECserver PORT SETTINGS ----------------------- Port Characteristic DIAL-OUT DIAL-IN ------------------- -------- ------- ACCESS Remote Local AUTOBAUD Disabled(1) Enabled AUTOCONNECT Disabled Enabled AUTOPROMPT Disabled Enabled BREAK Disabled Disabled(2) DEDICATED None None DSRLOGOUT Disabled Disabled DTRWAIT Enabled Disabled FLOW CONTROL XON XON INACTIVITY LOGOUT Disabled Enabled INTERRUPTS Disabled Disabled SIGNAL CHECK Disabled Disabled SIGNAL CONTROL Enabled Enabled PASSWORD Disabled Enabled (1) Match port speed with modem speed. (2) Define a port LOCAL SWITCH character. MODEM SETTINGS -------------- Scholar modems have been known to work with the following configured characteristics: DECmodem V32, DF242 (Scholar Plus), DF212 : - Reset to Factory Settings ==> DEF P/ALL - Adjust Line Speed ==> SET P1/OPE DF224: - Reset to Factory Settings 29 - Adjust Line Speed Use MODE BELL212=0 or V22bis=2 - Modem Response Use MODEM RESPONSE ABBREVIATED=0 (recommended on dial-in lines) 30