MUXserver 320/380/90-Software Module Release Notes Revision/Update Information: V2.0 BL9 These Release Notes apply to the MUXserver 320/380/90 V2.0 Remote Terminal Server software which appears as Baselevel BL9 on any SHOW SERVER display. They contain update information and other miscellaneous items not included in the rest of the MUXserver 320/380/90 V2.0 documentation set. All known problems affecting MUXserver 320/380/90 operation are documented, together with information specific to the V2.0 release of the software. The Release Notes should be distributed to the server man- ager(s), load host system manager(s) and any other individuals responsible for server maintenance. Digital Equipment Corporation Maynard, Massachusetts CONTENTS 1 HOW TO REPORT A PROBLEM.............................. 1 1.1 Submitting and SPR................................ 1 1.2 Documentation Problems............................ 1 1.3 Severe Errors..................................... 2 2 SOFTWARE NOTES - SUMMARY OF CHANGES.................. 2 2.1 Documentation Errors.............................. 3 2.2 Problem Fixes..................................... 3 2.2.1 Miscellaneous Crashes.......................... 3 2.2.1.1 Entering Blanks on Command Line............. 3 2.2.1.2 Crash in Multiplexor........................ 3 2.2.1.3 TEST LINK command........................... 4 2.2.1.4 Telnet Print Job Cancellation............... 4 2.2.1.5 Link Loss While Connections Queued.......... 4 2.2.1.6 User Limit Exceeded......................... 4 2.2.2 LAT Problems................................... 4 2.2.2.1 LAT Nodes Inaccessible After Reboot......... 4 2.2.2.2 Inconsistent Reachable Nodes Count.......... 4 2.2.2.3 LAT START Slot Missing Parameter 6.......... 4 2.2.2.4 TEST SERVICE Fails.......................... 5 2.2.3 Telnet Problems................................ 5 2.2.3.1 Hanging Telnet Printer Connections.......... 5 2.2.3.2 Telnet Print Queuing........................ 5 2.2.3.3 Telnet Job Abort Using FIN.................. 5 2.2.3.4 Telnet Abort Output Signal.................. 5 2.2.3.5 Special Telnet Characters................... 5 2.2.4 Synchronous Link Problems...................... 5 2.2.4.1 Link Speed Determination.................... 6 2.2.5 TD/SMP Multisessions Problems.................. 6 2.2.5.1 Rapid Entry of Cursor Movement Commands..... 6 2.2.5.2 Hanging Multisessions Session............... 6 2.2.5.3 Unable to Resume............................ 6 2.2.5.4 Multisessions Performance................... 6 2.2.6 User Interface Problems........................ 7 2.2.6.1 Pathru/Passal Mode.......................... 7 2.2.6.2 Unable to Break from Autoconnect............ 7 2.2.6.3 Terminating Passwords with Control-Z........ 7 2.2.6.4 SHOW SESSION PORT........................... 7 2.2.7 Internet Database Command Problems............. 7 2.2.7.1 ARP Databse Memory Leakage.................. 7 2.2.7.2 CLEAR INTERNET HOST LOCAL................... 7 2.2.7.3 Crash when CLEARing NAMESERVER.............. 8 2.2.7.4 CLEAR INTERNET HOST DOMAIN.................. 8 2.2.8 Miscellansous Problems......................... 8 iii 2.2.8.1 Inconsistent Behaviour of Telnet and Ping... 8 2.2.8.2 Duplicate Station Names..................... 8 2.2.8.3 Queue Entry Count Corrupted................. 8 2.2.8.4 TSM$MS_V20_GET_CHAR.COM..................... 8 3 KNOWN PROBLEMS....................................... 9 iv 1 HOW TO REPORT A PROBLEM If you discover a problem with the operation of the MUXserver 320/380 remote terminal server software, please check to see if the problem is already known before submitting an SPR. If it is, a work-around or fix may already be available, which will minimize any disruption caused by the problem. To check this, please perform the troubleshooting procedures outlined in the MUXserver 320/380 Documentation and verify the source of the problem. Also, read Section 3 of these Release Notes, which describe known restrictions and problems with this release. If the software is still under warranty, or if you purchased Digital support services, call the telephone hotline to report your problem. They may be able to provide you with information and a work-around to solve the problem immediately. 1.1 Submitting and SPR When completing a Software Performance Report (SPR), describe one problem at a time. This simplifies record keeping and fa- cilitates a quick response. Keep the description simple yet accurate. Illustrate a general problem with several examples. If a FATAL BUGCHECK error occurs, submit a crash dump. (See Chapter 10 of the MUXserver 320/380 Network Reference Manual for more details.) 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 an 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. 1.2 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. If you are reporting an error with on-line HELP, please identify the full command and screen. 1 1.3 Severe Errors Severe errors may cause your MUXserver 320/380/90 to hang or bugcheck. Server hangs are usually recovered by an automatic server initialization, followed by a downline load. If this should occur, please describe as best you can the operating conditions on the server at the time of the hang. If a FATAL BUGCHECK occurs, a bugcheck message will be printed out on the console terminal, showing the vital registers at the time of the bugcheck. Normally, an upline crash dump will automatically be created upon a fatal bugcheck error. For other types of problems a crash dump is also an extremely valuable tool; if you experience a problem that isn't easily reproducible, a crash dump will normally allow DIGITAL to fix the problem even if not reproducible. You can force a CRASH by typing 'CRASH' to the Local> prompt in privileged local mode, or by pressing the red Dump/Reset button on the MUXserver 320/380/90. The crash dump will normally be located in the directory SYS$COMMON:[DECSERVER] on the dump host, and the file name will be MSnxxxxx.DMP, where n is 2 for a MUXserver 320, 8 for a MUXserver 380 or 9 for a MUXserver 90, and xxxxxx is the DEC- net node name assigned to the server unit, as defined using the DSV$CONFIGURE configuration procedure. For example, if the MUXserver 90 with node name LAT041 bugchecks, the crash dump will be found in SYS$COMMON:[DECSERVER]MS9LAT041.DMP on the dump host. Copy the crash dump file to Magtape or TK50 media, and indicate on a label the format of the copy (COPY, BACKUP, TAR, etc.). All media sent to Digital will be returned to the sender. 2 SOFTWARE NOTES - SUMMARY OF CHANGES This V2.0 is a major new release of the MUXserver 320/380/90 software and includes two new areas of functionality: 1. Support for the MUXserver 90 hardware, and 2. Support for management via the Simple Network Management Protocol (SNMP). Full details of these new areas of functionality are included in the completely revised Network Reference Manual. A number of other minor areas of functionality enhancement are included, such as support for OpenVMS AXP and OSF/1 load hosts. In addi- tion, all previously reported problems have been corrected. 2 2.1 Documentation Errors Two errors are present in the new (Version 2) MUXserver Network Reference Manual. 1. The sysObjectID as documented in Appendix C, Table C-1, is wrong and should be as follows: iso(1), organisation(3), dod(6), internet(1), private(4), enterprises(1), dec(36), ema(2), system(15), MUXservers(16), Mode - MUXerver90(1), MUXserver320(2), MUXserver380(3), DECmux300(4) MUXVersion(1) 2. The use of link type RS422 has been discontinued as this link type is indistinguishable from a Null-modem link. This affects the list of interface types in Section 1.2.1 and also the syntax of the SET/DEFINE/CHANGE LINK INTERFACE command on page A-74 of Appendix A. 2.2 Problem Fixes This section summarises all problem fixes that have been in- cluded in the software since V1.1 (Baselevel BL7C). A number of these fixes have been included in patch kits since then and this is noted against each problem. Problems are grouped into functional areas. 2.2.1 Miscellaneous Crashes 2.2.1.1 Entering Blanks on Command Line A crash sometimes resulted from entering one or more blanks followed by a Carriage Return at the local prompt. The crash would occurr when entering the next command, and it was neces- sary for the MUXserver to repaint the line, eg. a Control-R or Delete-Word (Control-J) was entered. 2.2.1.2 Crash in Multiplexor A crash was reported in the transmit multiplexor and was found to result from a combination of a simultaneous LOGOUT PORT ALL and some other command that communicates with the same remote DECmux, eg. TEST PORT or MONITOR LINK STATUS. The problem was most likley to occur when the frame size for the link was small, eg. a slow link. This was corrected in Baselevel BL7D. 3 2.2.1.3 TEST LINK command TEST LINK (online with no loopback) with a WIDTH greater than 200 caused a crash. This is corrected in this version, Baselevel BL9. 2.2.1.4 Telnet Print Job Cancellation A crash was possible if a Telnet print job was cancelled during execution. This is corrected in this version. 2.2.1.5 Link Loss While Connections Queued If a link went down while there were jobs in the connection queue for ports or services on a DECmux on that link, a crash would occur. This has been corrected in this version. 2.2.1.6 User Limit Exceeded A crash was reported when the User Limit (eg. 128 on a MUXserver 380) was exceeded. This was due to an error in the checking of the user limit and a subsequent table overflow. This has been corrected in this version. 2.2.2 LAT Problems 2.2.2.1 LAT Nodes Inaccessible After Reboot When a LAT node was shutdown and subsequently rebooted, the LAT services would remain unavailable. This would not normally be noticed, since the first user to attempt to reconnect to the service would cause a LAT solicitation to be done and the node would respond and the LAT database updated. If for some reason the LAT solicitation was not attempted, eg. the port's preferred protocol was Telnet, then the unavailability would not be corrected. This was corrected in Baselevel BL7D. 2.2.2.2 Inconsistent Reachable Nodes Count The count of reachable nodes shown on the SHOW SERVER STATUS display could become inconsistent in some circumstances where nodes timed out. This was corrected in Baselevel BL7D. 2.2.2.3 LAT START Slot Missing Parameter 6 Some problems were found with the MUXserver interoperating with third party LAT implementations due to the non-inclusion of Parameter Code 6 in START slots sent by the MUXserver. This parameter specifies the group codes of the destination port, so as to allow the other LAT implementation to validate them. This parameter is included by MUXserver software Baselevel BL7E and this version. 4 2.2.2.4 TEST SERVICE Fails A problem was introduced into V1.1 which prevented TEST SERVICE from working. This was corrected in Baselevel BL7D. 2.2.3 Telnet Problems 2.2.3.1 Hanging Telnet Printer Connections A problem was found whereby a host closes a Telnet connection at a time when the output to the printer was flow controlled off. The result was that the MUXserver did not complete the closure of the Telnet connection. This was corrected in Baselevel BL7E. 2.2.3.2 Telnet Print Queuing No queuing was provided for Telnet connections. To accommodate the needs of some third party printer daemons, a queing facility has been added to this version. To use Telnet queuing, it is necessary to establish the listener to be directed to a local service using SET/DEFINE/CHANGE TELNET LISTENER nnnn SERVICE xxxx and to ensure that the local service has QUEUING enabled. 2.2.3.3 Telnet Job Abort Using FIN When a Telnet connection is received for a port which is in use, the TCP connection is initially established but must then be closed. This was previously done with a FIN message followed, if necessary, by a RST message. In this version, only the RST message is sent. This solves some interoperability problems with some third party print daemons and makes the behavior consistent with the DECserver. 2.2.3.4 Telnet Abort Output Signal The Telnet Abort Output (AO) signal was being sent with each Interrupt Process (IP) signal, whereas it should only have been sent if the AO Autoflush characteristic was enabled. This is corrected in this version. 2.2.3.5 Special Telnet Characters In certain circumstances, special Telnet characters including the IAC and Newline characters would be missed and thus not interpreted correctly. This could lead to Telnet Options being missed or Newline sequences being processed incorrectly. This is corrected in this version. 2.2.4 Synchronous Link Problems 5 2.2.4.1 Link Speed Determination When operating with certain modems, it was found that the link speed was incorrectly determined by the MUXserver and conse- quently, an inappropriate frame size was set for the link. This was believed to be a result of instability in the modem clocking immediately after DSR was raised. A short 3 second delay was introduced (in Baselevel BL7E) so that the autobauding is not commenced immediately after DSR is raised. Where multiple DECmuxes are daisy chained, it was possible that if the second or third DECmux in the chain went down, that communications from the MUXserver to the nearer DECmux was hung. This was only able to be overcome by bringing the entire link down and up. This problem is corrected in this version. There was a circumstance in which a link would go down for a valid reason, eg. loss of a modem signal, but would subsequently not come up again. This is corrected in this version. 2.2.5 TD/SMP Multisessions Problems 2.2.5.1 Rapid Entry of Cursor Movement Commands Rapid entry of cursor movement commands (arrow keys) in an editor such as TPU while in Multisessions operation with a VT420 terminal could sometimes cause the port to hang. This was partially corrected in Baselevel BL7E but revealed a subsequent problem described below. 2.2.5.2 Hanging Multisessions Session If during rapid input to a Multisessions session the input was flow controlled off, ie. the Wait status appeared, and then the user switched to another session and back to the original, then the original session's flow control state was never cleared. This is corrected in this version, Baselevel BL9. 2.2.5.3 Unable to Resume After BREAKing to the local prompt from a Multisessions sessions it was sometimes impossible to resume the service session. This was corrected in Baselevel BL7E. 2.2.5.4 Multisessions Performance Performance of simultaneous output to two sessions was improved significantly in Baselevel BL7E by implementing ``trusted mode'' in the handling of credits between the MUXserver and the TD/SMP terminal. 6 2.2.6 User Interface Problems 2.2.6.1 Pathru/Passal Mode It was found that if a session was in PASSAL or PASTHRU mode and Local Mode was resumed using BREAK, that the connection remained in PASTHRU/PASSAL mode while communicating with the Local Mode interface. Thus, attempts by the terminal to use XON/XOFF flow control were being ignored and spurious Control-S and Control- Q characters would be sent to, and echoed by, the Local Mode interface. This was corrected in Baselevel BL7D. 2.2.6.2 Unable to Break from Autoconnect If a session was abnormally terminated and the port's AUTO- CONNECT characteristic was enabled, when the attempt to re- establish the connection was made, the user was unable to break back to the Local prompt. Furthermore, the Local prompt was be- ing displayed incorrectly in these circumstances. These problems were corrected in Baselevel BL7E. 2.2.6.3 Terminating Passwords with Control-Z When entering the privileged password, if it was terminated with a Control-Z, privileged mode would NOT be entered and the actual password would be echoed on the following line. This is corrected in this version. 2.2.6.4 SHOW SESSION PORT The SHOW SESSION port commands would sometimes produce erroneous results, examining the wrong ports. This has been corrected in this version. 2.2.7 Internet Database Command Problems 2.2.7.1 ARP Databse Memory Leakage It was found that dynamic memory was being consumed if an ARP message was processed for an entry which was already in the database. Over time, this could lead to a depletion of the dynamic memory pool as shown on the SHOW SERVER STATUS display. 2.2.7.2 CLEAR INTERNET HOST LOCAL A minor problem was found in the processing of the Internet Host Database such that following a CLEAR INTERNET HOST LOCAL command, new hosts could not be entered. This was corrected in Baselevel BL7D. 7 2.2.7.3 Crash when CLEARing NAMESERVER A crash was found when performing a CLEAR INTERNET NAMESERVER command. The problem only appeared if the nameserver name sup- plied was part of the domain name of the actual nameserver to be cleared, eg. CLEAR INTERNET NAMESERVER A.B.C where the actual nameserver was A.B.C.D. This was corrected in Baselevel BL7D. 2.2.7.4 CLEAR INTERNET HOST DOMAIN The CLEAR INTERNET HOST x.y.z DOMAIN command could cause a crash, depending upon the contents and structure of the Internet Host dataase. Clearing individual hosts would not cause the problem. This was corrected in Baselevel BL7E. 2.2.8 Miscellansous Problems 2.2.8.1 Inconsistent Behaviour of Telnet and Ping Ping was doing an ARP request when asked to make send messages to a host outside the current subnet in the absence of a gate- way, whereas Telnet was not doing an ARP request. Telnet and Ping were made consistent in Baselevel BL7E and now neither do an ARP request in these circumstances, and both return a ``No Router to Host'' message if no gateway is present. 2.2.8.2 Duplicate Station Names Some problems were found if two DECmuxes were found to have the same name. A check was added in Baselevel BL7E such that if two or more DECmuxes have the same name, the default station name, eg. STATION_A1, will be used instead. Also, use of an incorrect default name is disallowed, eg. trying to SET STATION NAME STATION_A1 for the DECmux on link B would be disallowed. 2.2.8.3 Queue Entry Count Corrupted One instance was reported of the Queue Entry Count as shown on the SHOW SERVER STATUS display being corrupted. In fact it was seen to go negative and to thus display as a large number. This could also lead to the corruption of the dymanic memory pool. This problem has been corrected in this version. 2.2.8.4 TSM$MS_V20_GET_CHAR.COM The previous version of this command precedure which can be used to save and restore the full MUXserver configuration, had some errors including an inability to retain the case of or embedded spaces within port names. This version corrects these errors as well as incorporating the SNMP characteristics. 8 3 KNOWN PROBLEMS None. 9