DECserver Network Access Software Version 2.0 Release DECserver Network Access Software Version 2.0 Release DECserver Network Access Software Version 2.0 Release Notes Notes Notes June, 1996 The DECserver Network Access Software Version 2.0 Release Notes contain information about enhancements, known problems, and workarounds. The Release Notes should be distributed to the network access server manager(s), load host system manager(s), and any other individuals responsible for network access server maintenance. ________ ________ _________ _______ ______ ________ _______ SOFTWARE VERSION: DECserver Network Access Software Version ___ 2.0 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. No responsibility is assumed for the use or reliability of software or equipment that is not supplied by Digital Equipment Corporation or its affiliated companies. Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the grant- ing of licenses to make, use, or sell equipment or software in accordance with the description. __________ Copyright ©1996 Digital Equipment Corporation. All rights re- served. The following copyright applies to the CMU BOOTP implementa- tion. __________ Copyright ©1988 Carnegie Mellon Permission to use, copy, modify, and distribute this program for any purpose and without fee is hereby granted, provided that this copyright and permission notice appear on all copies and supporting documentation, the name of Carnegie Mellon not be used in advertising or publicity pertaining to distribution of the program without specific prior permission, and notice be given in supporting documentation that copying and distribution is by permission of Carnegie Mellon and Stanford University. Carnegie Mellon makes no representations about the suitabil- ity of this software for any purpose. It is provided "as in" without express or implied warranty. __________ Copyright ©1986, 1987 Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of California at Berkeley. The name of the University many not be used to endorse or promote products derived from this software without specific prior written per- mission. This software is provided "as is" without express or implied warranty. (#)Version.c.4.8 (Berkeley) 4/7/88 The following are trademarks of Digital Equipment Corporation: DEC, DEChub, DEChub ONE, DECnet, DECserver, DELNI, Digital, LAT, MicroVAX, MultiSwitch, OpenVMS, Q-bus, ThinWire, ULTRIX, UNIBUS, VAX, VAXcluster, VAXstation, VT220, and the Digital logo. AppleTalk is a registered trademark of Apple Computer, Inc. HP is a registered trademark of Hewlett-Packard Company. IBM is a registered trademark of International Business Machines, Corporation. MS-DOS is a registered trademark of Microsoft Corporation. OSF/1 is a registered trademark of Open Software Foundation, Inc. SCO is a trademark of Santa Cruz Operations, Inc. Sun is a registered trademark of Sun Microsystems, Inc. UNIX is a registered trademark of UNIX System Laboratories, Inc. Vitalink is a registered trademark of Vitalink Communications Corporation. Novell and NetWare are registered trademarks of Novell, Inc. Contents Contents Contents 1 INTRODUCTION 1 1 INTRODUCTION 1 1 INTRODUCTION 1 2 DECSERVER MEMORY REQUIREMENTS 1 2 DECSERVER MEMORY REQUIREMENTS 1 2 DECSERVER MEMORY REQUIREMENTS 1 3 DISK SPACE REQUIREMENTS 1 3 DISK SPACE REQUIREMENTS 1 3 DISK SPACE REQUIREMENTS 1 4 VERSION 2.0 NEW FEATURES 2 4 VERSION 2.0 NEW FEATURES 2 4 VERSION 2.0 NEW FEATURES 2 4.1 RADIUS Client 2 4.1 RADIUS Client 2 4.1 RADIUS Client 2 4.2 SecurID Client 2 4.2 SecurID Client 2 4.2 SecurID Client 2 4.3 Local User Accounts 2 4.3 Local User Accounts 2 4.3 Local User Accounts 2 4.4 Callback, Dialing and Modem Scripting 4.4 Callback, Dialing and Modem Scripting 4.4 Callback, Dialing and Modem Scripting Support 3 Support 3 Support 3 4.5 IP Gateway Failover 3 4.5 IP Gateway Failover 3 4.5 IP Gateway Failover 3 4.6 Telnet Terminal Type Option 3 4.6 Telnet Terminal Type Option 3 4.6 Telnet Terminal Type Option 3 4.7 IPX MIB and IPXCP MIB 4 4.7 IPX MIB and IPXCP MIB 4 4.7 IPX MIB and IPXCP MIB 4 4.8 PPP Performance Improvement 4 4.8 PPP Performance Improvement 4 4.8 PPP Performance Improvement 4 4.9 DEChub 900 Support 4 4.9 DEChub 900 Support 4 4.9 DEChub 900 Support 4 4.10 DECserver Accounting and 'harvestd' UNIX 4.10 DECserver Accounting and 'harvestd' UNIX 4.10 DECserver Accounting and 'harvestd' UNIX Daemon Enhancements 5 Daemon Enhancements 5 Daemon Enhancements 5 5 DOCUMENTATION ERRORS 5 5 DOCUMENTATION ERRORS 5 5 DOCUMENTATION ERRORS 5 5.1 Viewing Online Documentation 5 5.1 Viewing Online Documentation 5 5.1 Viewing Online Documentation 5 5.2 DECserver Network Access Software 5.2 DECserver Network Access Software 5.2 DECserver Network Access Software Installation (OpenVMS) 5 Installation (OpenVMS) 5 Installation (OpenVMS) 5 5.3 DECserver Network Access Software 5.3 DECserver Network Access Software 5.3 DECserver Network Access Software Installation (Digital UNIX) 6 Installation (Digital UNIX) 6 Installation (Digital UNIX) 6 5.4 Incorrect Default Authorizations 7 5.4 Incorrect Default Authorizations 7 5.4 Incorrect Default Authorizations 7 5.5 New Error Codes 7 5.5 New Error Codes 7 5.5 New Error Codes 7 5.6 DECserver Accounting Enhancements 8 5.6 DECserver Accounting Enhancements 8 5.6 DECserver Accounting Enhancements 8 5.6.1 Summary of New Events 8 5.6.2 Examples and Descriptions of New Events 8 5.6.2.1 Dial Completion and Failure 8 5.6.2.2 Dial Request Failure 9 5.6.2.3 Authentication Failure 11 5.6.2.4 Remote PPP Client Address 11 5.6.2.5 Local User Account Inactivation 12 6 KNOWN PROBLEMS AND LIMITATIONS 12 6 KNOWN PROBLEMS AND LIMITATIONS 12 6 KNOWN PROBLEMS AND LIMITATIONS 12 6.1 DialBack Permission Needed for Callback to 6.1 DialBack Permission Needed for Callback to 6.1 DialBack Permission Needed for Callback to Occur 12 Occur 12 Occur 12 6.2 PPP Callback 13 6.2 PPP Callback 13 6.2 PPP Callback 13 6.3 Callback Numbers 13 6.3 Callback Numbers 13 6.3 Callback Numbers 13 6.4 RADIUS Reply-Messages Not Sent to PPP 6.4 RADIUS Reply-Messages Not Sent to PPP 6.4 RADIUS Reply-Messages Not Sent to PPP Clients 13 Clients 13 Clients 13 6.5 Inactivity Logout 14 6.5 Inactivity Logout 14 6.5 Inactivity Logout 14 6.6 RADIUS Accounting 14 6.6 RADIUS Accounting 14 6.6 RADIUS Accounting 14 6.7 Minor Memory Leaks 14 6.7 Minor Memory Leaks 14 6.7 Minor Memory Leaks 14 iii iii iii Contents Contents Contents 6.8 Authentication Methods Compatible with 6.8 Authentication Methods Compatible with 6.8 Authentication Methods Compatible with CHAP 14 CHAP 14 CHAP 14 6.9 Known problems in the DEChub 900 15 6.9 Known problems in the DEChub 900 15 6.9 Known problems in the DEChub 900 15 6.10 DECserver Accounting 16 6.10 DECserver Accounting 16 6.10 DECserver Accounting 16 6.11 AppleTalk 16 6.11 AppleTalk 16 6.11 AppleTalk 16 6.12 TN3270 Enhancement 17 6.12 TN3270 Enhancement 17 6.12 TN3270 Enhancement 17 6.13 Telnet Remote Console 17 6.13 Telnet Remote Console 17 6.13 Telnet Remote Console 17 6.14 PING 17 6.14 PING 17 6.14 PING 17 6.15 Telnet Server Session Echo 17 6.15 Telnet Server Session Echo 17 6.15 Telnet Server Session Echo 17 6.16 User Authentication 17 6.16 User Authentication 17 6.16 User Authentication 17 6.17 Other 18 6.17 Other 18 6.17 Other 18 7 POTENTIALLY CONFUSING BEHAVIOR 19 7 POTENTIALLY CONFUSING BEHAVIOR 19 7 POTENTIALLY CONFUSING BEHAVIOR 19 7.1 Backwards Compatibility of the 'harvestd' 7.1 Backwards Compatibility of the 'harvestd' 7.1 Backwards Compatibility of the 'harvestd' Utility 19 Utility 19 Utility 19 7.2 Development Notes for 'harvestd' Utility 20 7.2 Development Notes for 'harvestd' Utility 20 7.2 Development Notes for 'harvestd' Utility 20 7.3 Show Port Authorization 20 7.3 Show Port Authorization 20 7.3 Show Port Authorization 20 7.4 Vendor-Specific RADIUS attributes 20 7.4 Vendor-Specific RADIUS attributes 20 7.4 Vendor-Specific RADIUS attributes 20 7.5 Using Multiple RADIUS Hosts 21 7.5 Using Multiple RADIUS Hosts 21 7.5 Using Multiple RADIUS Hosts 21 7.6 Redundant Accounting Log Entries 21 7.6 Redundant Accounting Log Entries 21 7.6 Redundant Accounting Log Entries 21 7.7 Unexpected Authentication Failures with PPP 7.7 Unexpected Authentication Failures with PPP 7.7 Unexpected Authentication Failures with PPP Callback 21 Callback 21 Callback 21 7.8 Troubleshooting PPP Connections 22 7.8 Troubleshooting PPP Connections 22 7.8 Troubleshooting PPP Connections 22 8 SOFTWARE PROBLEMS CORRECTED BY THIS RELEASE 22 8 SOFTWARE PROBLEMS CORRECTED BY THIS RELEASE 22 8 SOFTWARE PROBLEMS CORRECTED BY THIS RELEASE 22 8.1 Server Bugchecks 22 8.1 Server Bugchecks 22 8.1 Server Bugchecks 22 8.1.1 Code 0002 22 8.1.2 Code 0003 23 8.1.3 Bugcheck Code 004 23 8.1.4 Bugcheck Code 000B 23 8.1.5 Bugcheck Code 299 23 8.1.6 Bugcheck Code 500 24 8.1.7 Bugcheck Code 540 24 8.1.8 Bugcheck Code 0542 24 8.1.9 Bugcheck Code 0543 24 8.1.10 Bugcheck Code 896 24 8.1.11 Bugcheck Code 0956 25 8.1.12 Bugcheck Code 0977 25 8.1.13 Telnet Problems 25 8.1.14 Superfluous Telnet Option Negotiation Messages 25 8.1.15 Telnet Listener Port List Problem 26 8.2 PPP/SLIP Problems 26 8.2 PPP/SLIP Problems 26 8.2 PPP/SLIP Problems 26 8.2.1 Autolink Sometimes XOFF'd Input 26 8.2.2 SLIP/PPP Network Connectivity 27 8.2.3 Local Errors 504 and 503 27 iv iv iv Contents Contents Contents 8.3 Port Problems 27 8.3 Port Problems 27 8.3 Port Problems 27 8.3.1 Local Login Text Out of Sequence 27 8.3.2 Port Hangs in Signal Wait or Session Mode 27 8.3.3 Problem with DTRwait 28 8.3.4 Problem With DSRS and Ring Signals 28 8.3.5 Problems With Multisessions Terminals 28 8.3.5.1 All Ports Hang 28 8.3.5.2 Single Port Hangs 28 8.3.5.3 Single Session Hangs 29 8.3.5.4 Combining Menus, Password, and DSRlogout Caused Login Problems 29 8.3.6 DSR Status Incorrect 29 8.3.7 DS90M Hangs in Session_Mode 29 8.3.8 Lost XOFF Characters 30 8.4 DNS Problems 30 8.4 DNS Problems 30 8.4 DNS Problems 30 8.4.1 Stub and Slave Name Resolution Modes Might Fail 30 8.5 Authentication Problems 30 8.5 Authentication Problems 30 8.5 Authentication Problems 30 8.5.1 Authentication Timeout 30 8.5.2 Authentication Error 3008 31 8.5.3 KPASSWD Operation Was Unreliable 31 8.6 LAT Problems 31 8.6 LAT Problems 31 8.6 LAT Problems 31 8.6.1 16 Character Port Names 31 8.6.2 Immediate Access Rejected Code 32 8.6.3 DATA_B Slots Needed to be a Minimum Size 32 8.6.4 Characters Transposed after a BREAK 32 8.6.5 LAT Local Service Port List Problem 32 8.6.6 LAT queuing Problem 33 8.6.7 LAT Circuit Failure 33 8.7 Problems with Flash RAM 33 8.7 Problems with Flash RAM 33 8.7 Problems with Flash RAM 33 8.7.1 Problem with Flash Update 33 8.7.2 Incorrect Version Information 33 8.8 Memory Leaks 34 8.8 Memory Leaks 34 8.8 Memory Leaks 34 8.9 DS900TM/DS900GM Specific Problems 35 8.9 DS900TM/DS900GM Specific Problems 35 8.9 DS900TM/DS900GM Specific Problems 35 8.9.1 Server Won't LAN hop 35 9 HOW TO REPORT A PROBLEM 35 9 HOW TO REPORT A PROBLEM 35 9 HOW TO REPORT A PROBLEM 35 9.1 Documentation Problems 36 9.1 Documentation Problems 36 9.1 Documentation Problems 36 9.2 Severe Errors 36 9.2 Severe Errors 36 9.2 Severe Errors 36 APPENDIX A RADIUS ATTRIBUTES SUPPORTED IN THIS RELEASE A-1 APPENDIX A RADIUS ATTRIBUTES SUPPORTED IN THIS RELEASE A-1 APPENDIX A RADIUS ATTRIBUTES SUPPORTED IN THIS RELEASE A-1 v v v 1 Introduction 1 Introduction 1 Introduction These Release Notes apply to DECserver Network Access Software Version 2.0, for any of the supported load host platforms, and for any of the supported DECserver platforms. Some of the information in this document was not available at the time the Product Documentation was finalized. In addition, there are sections on new features, known problems, poten- tially confusing behavior, and bug fixes applied since the last release. In Field Test, this release was labeled Version 1.6. Any refer- ences to DNAS V1.6 should be assumed to apply to DNAS V2.0. If this kit is being installed on a third-party UNIX host (i.e. not Ditial UNIX), ensure that you read the README file provided with the installation kit, if any. It includes examples and hints relevant to the installation procedure, specifically, the making of CMU BOOTP sources on different UNIX systems and platforms. Note that the CMU BOOTP sources are provided only as a convenience to those users that do not have BOOTP in their systems. Digital Equipment Corporation does not offer any sup- port of the BOOTP sources nor does it provide any warranties on their operation. 2 DECserver Memory Requirements 2 DECserver Memory Requirements 2 DECserver Memory Requirements Version 2.0 of DECserver Network Access Software requires at any any any least 4 MB of Dynamic RAM on of the supported DECserver platforms. The previous version (V1.5) required at least 2 MB on the DECserver 700, and at least 4 MB on all other supported DECserver platforms. V2.0 will not run in 2 MB. 3 Disk Space Requirements 3 Disk Space Requirements 3 Disk Space Requirements The following information refers to the disk space required on the load host's system disk. The disk space size is approxi- mate. (Actual sizes may vary depending on the user's system environment, configuration, and software options.) For OpenVMS (VAX and Alpha) systems: For OpenVMS (VAX and Alpha) systems: For OpenVMS (VAX and Alpha) systems: DECserver 90TL/90M: 8,500 blocks DECserver 700/900TM/900GM: 10,000 blocks 1 1 1 For ULTRIX systems: For ULTRIX systems: For ULTRIX systems: DECserver 90TL/90M: 3,500 K bytes DECserver 700/900TM/900GM: 3,500 K bytes For MS-Windows systems: For MS-Windows systems: For MS-Windows systems: DECserver 90TL/90M: 3,000 K bytes DECserver 700/900TM/900GM: 3,000 K bytes For Third-Party UNIX systems: For Third-Party UNIX systems: For Third-Party UNIX systems: DECserver 90TL/90M: 3,500 K bytes DECserver 700/900TM/900GM: 3,500 K bytes For Digital UNIX (Alpha) systems: For Digital UNIX (Alpha) systems: For Digital UNIX (Alpha) systems: DECserver 90TL/90M: 3,500 K bytes DECserver 700/900TM/900GM: 3,500 K bytes 4 Version 2.0 New Features 4 Version 2.0 New Features 4 Version 2.0 New Features The DECserver Network Access Software Version 2.0 release provides several new features along with various feature en- hancements and bugfixes. This section describes new features available with this software release. 4.1 RADIUS Client 4.1 RADIUS Client 4.1 RADIUS Client The DECserver now includes a Remote Authentication Dial In User Serivce (RADIUS) client. RADIUS is an emerging Internet Standard for Network Access Server (NAS) authentication, autho- rization and accounting. 4.2 SecurID Client 4.2 SecurID Client 4.2 SecurID Client The DECserver now includes a SecurID client. SecurID is a market-leading hardware token based authentication system. The SecurID client works in conjunction with ACE Servers from Security Dynamics. 4.3 Local User Accounts 4.3 Local User Accounts 4.3 Local User Accounts The DECserver now includes a local authentication and autho- rization facility based on user accounts defined and stored on the DECserver. The functionality of the local user accounts is a subset of the RADIUS authentication and authorization functionality. 2 2 2 4.4 Callback, Dialing and Modem Scripting Support 4.4 Callback, Dialing and Modem Scripting Support 4.4 Callback, Dialing and Modem Scripting Support The DECserver now includes facilities for automated dialing of modems to support call back to the user or dial out to a remote site. PPP (Point to Point Protocol) LCP (Link Control Protocol) call back option negotation is now supported. Call back may be directed by the user from the DECserver's command line prompt (voluntary call back), via authorization informa- tion for the user's account (mandatory call back), or via PPP callback negotiation. Dial services describe a port or set of ports available for dialing, as well as optional features re- lated to dialing. Modems scripts describe the modem commands and responses necessary to accomplish dialing. 4.5 IP Gateway Failover 4.5 IP Gateway Failover 4.5 IP Gateway Failover The DECserver now includes a facility to detect non-responding gateways and switch IP connections over to a secondary gateway. A gateway becomes suspect when access is actively being made via the gateway, and the application or transport layer reports poor service. When a gateway is suspect, it is cleared from the access server's ARP cache. If the gateway is truly down or unreachable, the resulting ARP request times out. This timeout After After After takes three minutes. the timeout, the bad default gateway will be replaced by another default gateway from the routing table. The user can see when the gateways have been shuffled by the order in which they appear in the SHOW INTERNET GATEWAY display. 4.6 Telnet Terminal Type Option 4.6 Telnet Terminal Type Option 4.6 Telnet Terminal Type Option RFC 1091 specifies a mechanism by which a Telnet client may negotiate a terminal type with a Telnet server. This version of software expands the list of terminal types available to the DNAS Telnet client to include ANSI and VTXXX where VTXXX is any VT type terminal from VT10 through VT999. It also provides a new parameter to the {SET | CHANGE | DEFINE} PORT TELNET CLIENT command to allow the user to specify the desired terminal type. The specified terminal type is used as a starting point in the negotiation. If the Telnet server rejects it the Telnet client will respond with an alternate type. The order of negotiation is: VTXXX, followed by ANSI, followed by UNKNOWN. The factory default is UNKNOWN. 3 3 3 4.7 IPX MIB and IPXCP MIB 4.7 IPX MIB and IPXCP MIB 4.7 IPX MIB and IPXCP MIB The DECserver now supports two additional SNMP MIBs, one for IPX and one for IPXCP. Refer to the SNMP Survival Guide file provided in the installation kit for additional details on DECserver support for these and other MIBs. 4.8 PPP Performance Improvement 4.8 PPP Performance Improvement 4.8 PPP Performance Improvement The aggregate performance for PPP packet forwarding has been improved by about 40 percent over the previous software ver- sion. 4.9 DEChub 900 Support 4.9 DEChub 900 Support 4.9 DEChub 900 Support This version adds management support for DECserver 900s oper- ating in a DEChub 900. The functionality of DECserver 90s has not changed. Specifically, IP Services and Console Redirect features have been added. If a problem is encountered with hub management functional- ity it would be helpful in quickly diagnosing problems if the following information could be provided along with the normal server platform type and DNAS version level. o The revision level of the Hub's (MAM) code. o Which mangement tool (usually Hubwatch), its revision level and what platform its running on. o Whatever network topology (interviening bridges, gateways etc.) that can be provided. Previous DNAS hub functionality should remain unchanged. The server will still show two connections (operational chan- nel when software is running and a maintenance channel for dump/load firmware firmware functions) in the hubwatch LAN interconnect screen. DNAS software does now support the MAM's 'Redirect Mode' from the DEChub Installation menu. It is important to note that setting any parameters from this menu are to the server's per- manent database (equivalent to a DEFINE command on a server). In order for these parameters to take effect the server must be re-intialized either via a server INITIALIZE command or by choosing option 2 (Restart with Current Settings) at the DECserver 900 Installation menu. 4 4 4 Two items to keep in mind when at the DECserver 900 Installation menu. First, in option 3 (Show Current Settings) the reset count is currently not supported. It will always appear as a zero. Second invoking option 1 (Restart with Factory Defaults) is equivalent to holding down the reset-to-factory switch (RFS) on the DECserver 900's front panel. All settings (port, server, service, etc.) will be returned to factory defaults. Any set- tings made via the Installation menu will be lost. It is strongly recommended to NOT use the Decserver as the IP service provider for the MAM. Currently communication speed between the DECserver and MAM is limited to one quarter or less than that of the repeaters, bridges and most other hub modules. If selected for IP services the DECserver will check its current and peak memory and processor utilization. If any of these values exceed a non-settable utilization limit the IP services will be rejected by the DECserver. 4.10 DECserver Accounting and 'harvestd' UNIX Daemon Enhancements 4.10 DECserver Accounting and 'harvestd' UNIX Daemon Enhancements 4.10 DECserver Accounting and 'harvestd' UNIX Daemon Enhancements The DECserver Accounting log contains additional types of event records in Version 2.0, that correspond to additional variables in the DECserver Accounting MIB. Version 1.3 of the unsupported UNIX utility 'harvestd' is back- ward compatible with previous versions of DECserver software. This new release supports 26 DECserver Accounting MIB variables while the earlier release supported 11 such variables. 5 Documentation Errors 5 Documentation Errors 5 Documentation Errors 5.1 Viewing Online Documentation 5.1 Viewing Online Documentation 5.1 Viewing Online Documentation When viewing the books online, be sure to expand the display window to properly display code examples and tables. 5.2 DECserver Network Access Software Installation (OpenVMS) 5.2 DECserver Network Access Software Installation (OpenVMS) 5.2 DECserver Network Access Software Installation (OpenVMS) o In the Online Services section in the Preface, the title BBB should appear as BBS. o If viewing the book online, the code example in Step 7 in Procedure section of the Downloading the Software topic does not display correctly. It should appear as follows: 5 5 5 Dynamic RAM: 4 M bytes Non-Volatile RAM: 32 K bytes Flash RAM: Installed: Yes Total size: 1 M bytes Boot block: Valid Load Image: Name: MNENG2 Size: nnnnnn bytes Version: Vn.n for DS90M BLnn-xx 5.3 DECserver Network Access Software Installation (Digital UNIX) 5.3 DECserver Network Access Software Installation (Digital UNIX) 5.3 DECserver Network Access Software Installation (Digital UNIX) o In the Online Services section in the Preface, the title BBB should appear as BBS. o In Appendix A, Software Distribution Files, the descrip- tion for WWENG2 incorrectly refers to Version 1.3 of the software. The description should read as follows: DECserver Network Access Software Version 2.0 for DECserver 700s or DECserver 900TMs with at least 4 MB o In Appendix A, Software Distribution Files, the descrip- tion for MNENG2 incorrectly refers to Version 1.3 of the software. The description should read as follows: DECserver Network Access Software Version 2.0 for DECserver 90Ms or DECserver 90 TLs with at least 4 MB o If viewing the book online, the code example in Step 1 of the Configuring the BOOTP Server topic does not display correctly. It should appear as follows: tftp dgram udp wait root /usr/sbin/tftpd tftpd -r /tftpboot bootps dgram udp wait root /usr/sbin/bootpd bootpd o IF viewing the book online, the second line of the code example in Step 5 of the Configuring the Load Host topic does not display correctly. It should appear as follows: myds: tc=DS.default ha=08002BFC0176 ip=192.12.79.6: bf=MNENG1 6 6 6 5.4 Incorrect Default Authorizations 5.4 Incorrect Default Authorizations 5.4 Incorrect Default Authorizations The default authorizations for both Security Realms and for Local User Accounts have changed since the documentation was finalized. Sepecifically, the PERMISSIONS defaults now include NODIALBACK and NODIALOUT, instead of DIALBACK and DIALOUT. This change was made to make it even more unlikely that users will inadvertenlty get Dial permission, possibly resulting in unauthorized phone toll charges. While the factory default settings for the access server do not permit any outgoing phone calls, once a Dialer Service is defined on the access server, it would have been possible for unauthorized users to make outgoing phone calls, based on the default authorizations. It is now necessary for Local User Accounts and Realm Defaults to have the Dial permissions explicitly enabled by the system administrator. 5.5 New Error Codes 5.5 New Error Codes 5.5 New Error Codes The following access server error codes were added after the documentation (Problem Solving Guide) was finalized. Local -1108- Authorization failure - specified phone number disallowed Explanation: The phone number for a dialback session is not allowed due to the server setup. For example, a Local User Account specifies one phone number while the Dialer Service specifies another. Action: Decide which phone number SHOULD be dialed and make sure that is the only number used in your setup. Local -1109- Authorization failure - phone number not specified Explanation: A dialback session has been specified, but no phone number is available to place the phone call. Action: Ensure that (a) the user's authorization data (e.g. RADIUS, Local User Account) contains a phone number, or (b) the Security Realm Defaults contains a phone number (a non-typical case), or (c) the Dialer Service contains a phone number or (d) the PPP client has requested a phone number. Local -1110- Authorization failure - dialback disallowed Explanation: A dialback session has been requested, but is not authorized for the user. 7 7 7 Action: Dialback (or callback) must be authorized by the (a) user's RADIUS Account, or (b) the Security Realm Defaults, or (c) the Local User Account. 5.6 DECserver Accounting Enhancements 5.6 DECserver Accounting Enhancements 5.6 DECserver Accounting Enhancements For this release, the DECserver Accounting Log facility and its related DECserver Accounting MIB have been enhanced with new accounting events. Documentation of these enhancements was inadvertently omitted from the , ______ ______ __________ _____ Access Server Management Guide Chapter 22, Accounting. 5.6.1 Summary of New Events 5.6.1 Summary of New Events 5.6.1 Summary of New Events In Version 2.0 of DECserver Network Access Software, the fol- lowing accounting events have been added: o Remote Client IP address o Remote Client AppleTalk address o Remote Client IPX address o Dialer Script results o Dialer Service failures o Password failures o User Account inactivation o User Privilege level modification 5.6.2 Examples and Descriptions of New Events 5.6.2 Examples and Descriptions of New Events 5.6.2 Examples and Descriptions of New Events These new events are summarized in the following sections (re- lates to Example 22-5). 5.6.2.1 Dial Completion and Failure 5.6.2.1 Dial Completion and Failure 5.6.2.1 Dial Completion and Failure Event: Dial Completion Time: 0 09:01:49 Port: 7 Service: RESV_DSERVICE Username: bob_jones Expected: CONNECT Commands: AT...OK..ATDT555-7578 Response: ...CONNECT 57600.. 8 8 8 Event: Dial Failure Time: 0 09:01:49 Port: 7 Service: RESV_DSERVICE Username: bob_jones Expected: CONNECT Commands: AT...OK..ATDT555-7578 Response: ...BUSY.. Dial Completion and Dial Failure events indicate the success- ful or unsuccessful completion of a modem dialing attempt. Characters passed to and received back from the modem are recorded within the events. These events, particularly the Dial Failure events, can be used to diagnose problems in completing dialback requests. Because these events may contain sensitive information includ- ing unlisted phone numbers, credit card numbers, etc., these accounting events, like all sensitive information, should be protected against unathorized browsing. Only privileged ac- cess server users may display the accounting log. If accounting events are harvested by an SNMP management station, the infor- mation should be suitably protected on that system as well. 5.6.2.2 Dial Request Failure 5.6.2.2 Dial Request Failure 5.6.2.2 Dial Request Failure Event: Dial Request Failure Time: 0 09:04:20 Port: 7 Mode: Unknown Service: 555-7578 Username: bob_jones Reason: Authorization failure (dialback) The Dial Request Failure event usually indicates a callback request could not be accepted for queuing. However, in one par- ticular case (shown below), the request was accepted and queued but dialing could not be started after the dialer service delay had expired. Most configuration problems are detected at the time the callback is requested, and could result in one of the following reasons: o No port associated with dialer service o No dialer script associated with dialer port o Mode not authorized on dialer port o Dialer service does not exist o Dialer service is currently disabled o Illegal mode for callback 9 9 9 o Insufficient server resources The access server checks the authorization permissions of a user who requests a callback. The request can be made using either a framed client, the command line interface, realm defaults, or the account information associated with the username specified by the user as he or she logs in. If the callback requested by the user does not pass authorization checks, the specific reason for the refusal to accept the callback request is included in the Dial Request Failure event. These reasons include the following: o Authorization failure (dialback) User has no permission to request a callback o Authorization failure (dialout) User has no permission to make an outgoing call o Authorization failure (session mode) User has no permission to request a callback o Authorization failure (phone number) User has no permission to call the specified phone number o Authorization failure (user permissions) User has no permis- sion to create a SLIP or PPP connection o Authorization failure (dialback mode) User didn't request a callback, but forced callback is enabled The dial request could possibly be accepted and queued but the dial session could not later be created to actually dial the mo- dem. The most common reason for this is that none the ports listed in the dial service are available: they're already in use, limited to local (not remote) access, etc. If this is the case, the Dial Request Failure event includes "Port: 0" since no port could be selected for the remote dial session. If the access server is unable to create a remote session, it will automatically retry the dial session creation 60 seconds later. If this one retry also fails, the queued dial request is canceled. The failure to create a dial session is indicated by one of these reasons: o Session creation failure (retry attempted in 60 seconds) o Session creation failure (no more retries allowed) 10 10 10 5.6.2.3 Authentication Failure 5.6.2.3 Authentication Failure 5.6.2.3 Authentication Failure Event: User Authentication Failure Time: 0 09:54:19 Port: 7 Username: bob_jones@realm This event indicates a user could not be authenticated using a specific username-password pair supplied by the user and passed to an authentication server: Kerberos, RADIUS, SecurID, the local user accounts database, etc. Event: PAP Authentication Failure Time: 0 09:54:47 Interface: async7 Event: CHAP Authentication Failure Time: 0 09:55:50 Interface: async7 These two events indicate a user could not be authenticated by the access server using generic authentication checking and the server-wide login password. A username is neither supplied nor used in the authentication process. NOTE NOTE NOTE In these accounting events, "async7" corresponds to port 7 ("async" is the interface name for the port). 5.6.2.4 Remote PPP Client Address 5.6.2.4 Remote PPP Client Address 5.6.2.4 Remote PPP Client Address Event: IP Address Set Time: 0 10:18:17 Port: 4 Address: 16.20.48.99 Event: AppleTalk Address Set Time: 0 10:18:17 Port: 4 Address = 404.234 Event: IPX Address Set Time: 0 10:21:34 Port: 7 Network Address: 2B2C1E73 Node Address: 026F6F863789 These events are logged to the accounting file when a new pro- tocol session is created. The events indicate the address(es) assigned to the client. If more than one protocol is run- ning over the same connection (i.e., IP and IPX or IP and AppleTalk), two events will be logged when the connection is made, one for each of the two protocols. 11 11 11 5.6.2.5 Local User Account Inactivation 5.6.2.5 Local User Account Inactivation 5.6.2.5 Local User Account Inactivation Event: User Account Purged Time: 0 10:24:49 Account of: bob_jones Closed by: Svr_Mgr53 Event: User Account Deactivated Time: 0 10:25:26 Account of: bob_jones Closed by: Svr_Mgr53 These User Account inactiviation events indicate an account in the local user accounts database has been removed by a priv- ilged user. The first event is logged if a user account is purged from the permanent copy of the accounts database in NVRAM. The second event is logged if a user account is merely cleared from the volatile user accounts database in RAM. In addition to the new accounting events listed above, several existing events have been renamed slightly. These are: Old event name New event name ------------------------ -------------------------- Kerberos Password Fail User Authentication Failure Privileged Password Fail Privileged Password Failure Maintenance Password Fail Maintenance Password Failure Login Password Fail Login Password Failure Remote Password Fail Remote Password Failure SNMP Community Fail SNMP Community Failure 6 Known Problems and Limitations 6 Known Problems and Limitations 6 Known Problems and Limitations The following list includes some of the known problems with this release of the DECserver Network Access Software. Workarounds are described where applicable. 6.1 DialBack Permission Needed for Callback to Occur 6.1 DialBack Permission Needed for Callback to Occur 6.1 DialBack Permission Needed for Callback to Occur It is currently necessary to set the DIALBACK default permis- sion in any RADIUS or SERVER security realms in order to acco- modate callback connections. Normally, the DIALBACK permission would apply to interactive sessions, i.e. user-invoked call- back. It presently applies to authorization-directed callback as well. This will be fixed in a later release. Local> CHANGE RADIUS REALM realm-name PERMISSION (DIALBACK) 12 12 12 6.2 PPP Callback 6.2 PPP Callback 6.2 PPP Callback Certain callback requests will appear to be accepted but will not result in a return phone call. If the user is trying to use PPP to establish a PPP callback session, and the port be- ing used has LCP passive open disabled (meaning the server immediately transmits characters in an attempt to start up the session), the dial request is likely to be lost. To avoid this problem, enter the following command for every port which could possibly use PPP to negotiate a PPP callback session: Local> DEFINE PORT [n] LCP PASSIVE ENABLE This specifies that when a port logs in, the server is to pas- sively wait for the client to begin PPP session negotiation. 6.3 Callback Numbers 6.3 Callback Numbers 6.3 Callback Numbers It is recommended that the callback number for a given ses- exactly exactly exactly sion come from one source, and that all other possible sources of callback numbers have the value representing 'don't care', i.e. '(Any)', '(None)' or '*'. If different numbers are specified in multiple sources, the callback will likely fail because of phone number authorization failure. That is to say, the precedence relations of multiple phone numbers is problematic in this release. The possible sources of callback number are: o RADIUS Callback-Number Attribute o PPP Client (via LCP Callback Option negotiation) o Security Realm default authorization value for DialBack Number o Dialer Service value for DialBack Number 6.4 RADIUS Reply-Messages Not Sent to PPP Clients 6.4 RADIUS Reply-Messages Not Sent to PPP Clients 6.4 RADIUS Reply-Messages Not Sent to PPP Clients The current software version does not attempt to send a Reply- Message from a RADIUS Access-Accept or Access-Reject packet to a PPP dial-in client. It is recommended that Reply-Messages not be used for PPP users' accounts. 13 13 13 6.5 Inactivity Logout 6.5 Inactivity Logout 6.5 Inactivity Logout If Inactivity [Logout] was enabled on a port, previous versions of this software would not consider that port for inactivity logout if a framed (SLIP or PPP) session existed on that port. In this latest release, a change was implemented which monitors ports with framed as well as interactive sessions to determine if a port is inactive and therefore a candidate for inactivity logout. If a framed session does exist on a port, only actual data- carrying packets are considered "activity". PING and other "keepalive" data exchanges do not reset the inactivity counter. The server-wide inactivity timer value determines how long a port is allowed to be inactive before it is automatically logged off, thereby disconnecting any inactive sessions con- nected to that port. Inactivity monitor is enabled on a port- by-port basis using the SET|DEFINE|CHANGE PORT INACTIVITY [LOGOUT] ENABLED command. 6.6 RADIUS Accounting 6.6 RADIUS Accounting 6.6 RADIUS Accounting If your access server is not set up properly to do DNS host name resolution, RADIUS accounting does not work correctly in certain conditions. For example, if you have received a RADIUS authorization with Service-Type (i.e. ACCESS) LOGIN, Login-Protocol TELNET, with a Login-IP-Host specified, you will get a RADIUS accounting STOP message without a matching START. 6.7 Minor Memory Leaks 6.7 Minor Memory Leaks 6.7 Minor Memory Leaks There are some minor memory leaks associated with the DIALER and USERACCOUNT NVRAM functions (PURGE, DEFINE and LIST). The leaks are on the order of 40 bytes and affect HIGH POOL (heap) only. 6.8 Authentication Methods Compatible with CHAP 6.8 Authentication Methods Compatible with CHAP 6.8 Authentication Methods Compatible with CHAP may may may The following authentication methods be used in conjunc- tion with a PPP Client using the CHAP protocol, via PPP LCP authentication: o RADIUS 14 14 14 o DECserver Login Password must must must The following authentication methods use the PAP protocol, when authenticting via the PPP LCP authentication protocol from a PPP Client: o Kerberos o SecurID o Local User Accounts 6.9 Known problems in the DEChub 900 6.9 Known problems in the DEChub 900 6.9 Known problems in the DEChub 900 o When displaying current settings via a MAM console redirect, the field "resets" will always have a value of zero. o When displaying current settings via a MAM console redirect, the LAT version is split between two lines. o When setting or displaying SNMP community strings via a MAM console redirect, only the first read-only and read-write string will be displayed. o When modifying values via a MAM console redirect, most times these are permanent characteristics. In order to take effect you must re-initialize the server. This can be done via option 2 of the redirect menu "Reset with current settings" or via the server's UI based "Initialize" command. o Selecting option 1 "Reset with Factory Defaults" will cause the server to reset all saved NVram characteristics to fac- tory default values. o When using versions of Hubwatch earlier than the current re- lease of v4.1 (specifically 3.1) it is possible for Hubwatch to freeze. This can currently only be cured by exiting Hubwatch. o When issuing a "CONNECT TELNET inet-addr PORT tcp-port" command, the value for tcp-port is limited to the maximum telnet listener value for the DECserver. This restriction will be removed in final release. NOTE NOTE NOTE When filing a problem report against hub based function- ality it is requested you include the MAM version level. 15 15 15 If applicable the management tool version level, typ- ically Hubwatch, and the platform running the tool are also requested. 6.10 DECserver Accounting 6.10 DECserver Accounting 6.10 DECserver Accounting A session disconnect event in the DECserver accounting log in- cludes fields for the number of bytes transmitted and received during the life of the associated session. For TD/SMP sessions, these counters are invalid (they are correct for sessions other than TD/SMP sessions). When accessing the accounting log via the User Interface, these counters follow the "TX:" and "RX:" fields in a Session Disconnect event. When accessing the ac- counting log via SNMP, these counters are available via the objects acctEntrySentBytes and acctEntryReceivedBytes. This anomaly is also visible for active TD/SMP sessions via the SNMP CHARACTER-MIB in the objects charSessInCharacters and charSessOutCharacters. 6.11 AppleTalk 6.11 AppleTalk 6.11 AppleTalk There are certain situations that may cause an attached AppleTalk host to have a "stale" AppleTalk address (an ad- dress not contained in the current network range). This will occur if the the network range changes during the lifetime of an ATCP connection, such that the connection's address is not within the new range. Examples of this might be if the routers on a network were reconfigured with a new network range or if no routers were active and then one or more routers began functioning. The user will not be notified of the new network configuration and will continue to operate with this "stale" address. This situation may not disrupt current network service connections but may inhibit future service connections. Unfortunately, it may be difficult for the user to distin- guish this problem from other unrelated network problems (e.g. routers going down). In general, if the user sees reduced ser- vice access, they should try disconnecting the ATCP connection (making sure the port gets logged out, e.g. due to modem con- trol) and then reconnecting. At this time the connection will be given a valid address within the current network range. 16 16 16 6.12 TN3270 Enhancement 6.12 TN3270 Enhancement 6.12 TN3270 Enhancement Abbreviating keymap and/or terminal names is no longer accept- able. This was allowed in older versions, when the terminal and keymap names were known and abbreviations could be assumed to be unambiguous. Now, however, since the system manager can create new terminal and keymap names, abbreviations might be ambiguous. 6.13 Telnet Remote Console 6.13 Telnet Remote Console 6.13 Telnet Remote Console When memory utilization is at or near 100%, a Telnet remote console connection request to the access server may be re- jected. It is possible, in some circumstances, for the Telnet connec- tion to the Remote Console to be broken, without disconnect- ing the Remote Console session itself. In this situation, the Remote Console will be continually "in use", and unavailable until the access server is rebooted. 6.14 PING 6.14 PING 6.14 PING There is a bug in the software which causes the output from a completed PING to be displayed in local mode instead of in ses- sion mode. This will happen if the user starts a PING session, hits the break key, and does not resume the PING session before the test completes. If the user remains in session mode, the PING output will be displayed properly. 6.15 Telnet Server Session Echo 6.15 Telnet Server Session Echo 6.15 Telnet Server Session Echo A Telnet server session to a network access server physical port made through the Telnet listener will respond with WILL- ECHO to a DO-ECHO request from a Telnet client; however, the access server will not actually perform echoing. Echoing of incoming network data is the responsibility of the device at- tached to the physical port. 6.16 User Authentication 6.16 User Authentication 6.16 User Authentication The documentation indicates that User Authentication requests may be aborted by the user, once all information has been en- tered and the actual request has been sent onto the network, by typing a Break or local-switch character on the terminal. This feature is not implemented in the current release. Once the request is sent to the Kerberos KDC, the user must wait for a response from the KDC or a timeout to occur before additional 17 17 17 local mode commands may be entered. The timeout is controlled by the SET|DEFINE|CHANGE KERBEROS TIMEOUT command. This limita- tion applies to both user login authentication and the KPASSWD command. 6.17 Other 6.17 Other 6.17 Other Other known problems with this software release are listed below. o The INITIALIZE command does not properly measure the amount of delay time until the command is invoked. Add 1 minute to the time you specify to make sure an adequate delay takes place before the access server is initialized. o When setting up internet gateways, the following considera- tions must be kept in mind: - 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. - Network 17.1.1.1 mask 255.0.0.0 is illegal, since its network portion has extra bits not included in the subnet mask. - All subnet masks must have contiguous ones, starting from the left. - Network xxxx mask 255.255.255.255 is illegal. Use HOST xxxx instead. o On OpenVMS systems, limitations apply to the TSM GET CHARACTERISTIC command procedure which causes it to trun- cate a port Username if the Username has embedded spaces. When using TSM$NA_V14_GET_CHAR.COM, the following guidelines apply: - The port Username can be an ASCII character string of up to 16 characters, optionally containing up to 4 embed- ded spaces. A port Username containing 4 embedded spaces would therefore contain 5 ASCII substrings which collec- tively form the port Username. For example: define port [n] username "Port 1 A B C" 18 18 18 - A port Username, whose substring components are separated by multiple spaces, will be compressed thus reducing mul- tiple spaces to single space 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 _SETUP.COM file. ______ server - A port Username consisting of more than 5 ASCII substrings will be truncated thus leaving the first 5 ASCII sub- strings to form the port Username. Single characters or substrings beyond the 5th substring in the Username will be discarded. 7 Potentially Confusing Behavior 7 Potentially Confusing Behavior 7 Potentially Confusing Behavior This section describes behavior that may be confusing. 7.1 Backwards Compatibility of the 'harvestd' Utility 7.1 Backwards Compatibility of the 'harvestd' Utility 7.1 Backwards Compatibility of the 'harvestd' Utility Version 1.3 of the unsupported UNIX utility 'harvestd' is back- ward compatible with previous versions of DECserver software. This new release supports 26 DECserver Accounting MIB variables while the earlier release supported 11 such variables. The DECserver Accounting log contains additional types of event records, that correspond to the additional variables in the DECserver Accounting MIB. The Version 1.3 harvestd utility will automatically sense whether the DECserver software it is monitoring has the 11 variable version of the DECserver Accounting MIB or the 26 variable version. It assumes that DECserver has the latest softwarem with the 26 variable MIB version. If harvestd fails to receive a valid response from DECserver as to the added variables, during the auto-sense phase, it backs off to a pre- vious version. The harvestd utility currently allows 10 retries with a limited exponential back off algorithm. The auto-sense process takes about 2 minutes. Once trained to work with an earlier version, harvestd does not adjust to later versions. During the course of execution, under rare situations, harvestd will adapt to an earliest version. To bring it back to a newer version, one will need to kill and restart harvestd. 19 19 19 7.2 Development Notes for 'harvestd' Utility 7.2 Development Notes for 'harvestd' Utility 7.2 Development Notes for 'harvestd' Utility This section is for customers that desire to modify the har- vestd source code. The software was developed under the CWEB environment. That means modifying .w files, using ctangle to generate .c and .h files. To generate documentation, one need to run cweave to create .tex file, tex to generate .dvi file, and dvips to generate .ps file. All this software is available from a GNU ftp site. To develop software independent of documentation, one can start with .c and .h files. Such files generated by ctangle are not human readable. One can use: pp.sh ctangled_file > readable_file to generate a prettier and readable file. This file has no comments, because ctangle extracted all such comments. 7.3 Show Port Authorization 7.3 Show Port Authorization 7.3 Show Port Authorization If a user has changed the state of the port's privilege sta- tus, or has enabled SLIP or PPP on the port, the permissions attributes {PRIV, PPP, or SLIP} displayed by the command SHOW PORT AUTHORIZATION do not change. The SET PRIVILEGE command (which requires a password) creates a privileged status on the port, without disturbing the user's authorization record, which may or may not provide for the privileged status on the port (without a password). Similarly, the port PPP and SLIP enabled or disabled status are must must must separate from the user's SLIP or PPP permissions. The port be enabled for PPP or SLIP in order for the user's PPP or SLIP particular particular particular permission to be valid on that port. 7.4 Vendor-Specific RADIUS attributes 7.4 Vendor-Specific RADIUS attributes 7.4 Vendor-Specific RADIUS attributes Each Security Realm has a default set of Permissions which are applied only when the Service-Type is NAS-Prompt. In this case, the Permissions identified in the Realm limit the commands that the user may enter. For example, if the Permission says NOTELNET, then the user may not issue a Telnet request at the Local Prompt. With RADIUS Servers, it may be necessary to use the Vendor-Specific attribute to supply a mask that covers all of the permissions. The Realm default permissions also include a DialOut Service, which is necessary to complete callbacks. A Vendor-Specific attribute for DialOut Service also exists. With RADIUS Servers, it may be necessary to use the Vendor-Specific attribute to 20 20 20 supply the DialOut Service. Alternativley, the DialOut Service may be defined as the DEDICATED or PREFERED SERVICE on the port. Provisions are also made to define a DialOut Service in the Local User Accounts. 7.5 Using Multiple RADIUS Hosts 7.5 Using Multiple RADIUS Hosts 7.5 Using Multiple RADIUS Hosts When you name multiple hosts for a specific RADIUS realm, the DECserver will potentially try to contact each of the hosts, should any not respond. The number of retries utilized and total time spent waiting for user authentication, are con- figurable parameters. Hosts are contacted in a round-robin fashion. 7.6 Redundant Accounting Log Entries 7.6 Redundant Accounting Log Entries 7.6 Redundant Accounting Log Entries For authenticated users, connecting via PPP, there will be what may appear to be redundant login entries in the DECserver ac- counting log. This is artifact of the implementation details for PPP in DNAS. PPP runs as a session in the DECserver, much as a Telnet connection to a host is a session. PPP also con- tains within it authentication. The first accounting login event is for the port, to allow the PPP session to run. This login is unauthenticated. The second accounting login event is for the PPP authentication. 7.7 Unexpected Authentication Failures with PPP Callback 7.7 Unexpected Authentication Failures with PPP Callback 7.7 Unexpected Authentication Failures with PPP Callback This version of DNAS implement a policy of rejecting PPP au- thentication, to the PPP dial-in client, in cases where the user authentication itself is just fine, but the requested callback cannot be made. This is typically a problem with the callback authorization information supplied by the user's ac- count, or by other authorization defaults on the access server. A problem exists since many PPP client implementations will immediately disconnect the phone, after negotiating callback and receiving an authentication acknowledgement. If the call- back is denied as a result of authentication, the access server will 'pretend' that the authentication itself failed. This will cause the PPP dial-in client to give a failure message to the user immediately, albeit a potentially confusing one. Otherwise the PPP client will sit there waiting indefinitely for a callback that is not going to occur. 21 21 21 7.8 Troubleshooting PPP Connections 7.8 Troubleshooting PPP Connections 7.8 Troubleshooting PPP Connections Since PPP ports do not have the benefit of interactive er- ror messages, problems with PPP connections, or callback PPP connections are best diagnosed by looking at the DECserver Accounting Log. This must be performed by a priviliged user, such as the system administrator. 8 Software Problems Corrected by This Release 8 Software Problems Corrected by This Release 8 Software Problems Corrected by This Release The Access Server load images supplied in this kit contain all the available corrections for software problems found in DNAS versions 1.0, 1.1, 1.3, 1.4, and 1.5. 8.1 Server Bugchecks 8.1 Server Bugchecks 8.1 Server Bugchecks A bugcheck is a fatal error which causes the server to abruptly cease operation and attempt to dump the contents of its mem- ory to a dump host. Prior to dumping it's memory the server displays a Local -913- Fatal Bugcheck message on the console to describe the cause of the failure. The message includes PC, SP, SR, M, and C fields but typically the only meaning- ful fields are the PC, and C fields. The PC field points to the section of code where the error was detected. The C field contains a bugcheck code which describes the type of error that occurred. Some codes are generic and do not identify a specific feature as being at fault. Other codes describe spe- cific types of failures in individual components. For example, a code of 0002 indicates that a failure occurred while try- ing to read information from memory. It's generated by the hardware and is not indicative of a failure within a specific feature or function. A code of 0956 on the other hand is spe- cific to the Authentication feature and is not likely to occur if Authentication is not being used. However, in neither case does the bugcheck code describe the full set of conditions which lead to the failure. This version contains corrections for the known causes of each of the Bugchecks listed. It is not guaranteed to correct all possible causes of each bugcheck. 8.1.1 Code 0002 8.1.1 Code 0002 8.1.1 Code 0002 This bugcheck code is generated by the server's microprocessor when it is not able to access memory. It's indicative of a type of software error and does not identify a specific area of code as being faulty. This version of software corrects a 0002 bugcheck caused by a problem with Authentication. 22 22 22 8.1.2 Code 0003 8.1.2 Code 0003 8.1.2 Code 0003 This bugcheck code is generated by the server's microprocessor when it detects a memory addressing error. It's indicative of a type of software error and does not identify a specific area of code as being faulty. This version of software corrects a 0003 bugcheck caused by a problem with the way the server processed MOP messages. 8.1.3 Bugcheck Code 004 8.1.3 Bugcheck Code 004 8.1.3 Bugcheck Code 004 This version of software corrects a problem which caused the server to Bugcheck with a code of 004. The problem would oc- cur if a multisessions port received an illegal multisession command that exceeded 132 characters in length. Since even the longest multisession command should not exceed 132 char- acters the problem would most likely happen only in situations where the port is receiving spurious data due to faulty wiring between the terminal and the server. 8.1.4 Bugcheck Code 000B 8.1.4 Bugcheck Code 000B 8.1.4 Bugcheck Code 000B This bugcheck code is generated by the hardware when it tries to execute an unsupported instruction. This version corrects a problem which would occasionally result in this type of failure if a user authentication request timed out. It would only occur if one or more ports had Authentication enabled, and the Access Server was attempting to authenticate a user, and the Kerberos server did not respond to the request, and the subsequent retry failed. 8.1.5 Bugcheck Code 299 8.1.5 Bugcheck Code 299 8.1.5 Bugcheck Code 299 This bugcheck code indicates that the software was stuck in an endless loop. This version of software corrects 2 causes for this type of error. The first was specific to the DS700 and DS900 platforms. It would occasionally occur if a port was plugged into a modem while the software was running. This version of software also corrects a problem where the server would bugcheck with a 299 code if it received a duplicate LAT Queued Access Request for a request that was already queued to a different port or service. 23 23 23 8.1.6 Bugcheck Code 500 8.1.6 Bugcheck Code 500 8.1.6 Bugcheck Code 500 This is a generic bugcheck code used by several DNAS compo- nents. This image corrects a problem in the PPP and SLIP fea- tures which would cause this type of failure. The failure would occur if a PPP or SLIP port was logged out while it was being used as a route between another port on the server and a Telnet host on another subnet. 8.1.7 Bugcheck Code 540 8.1.7 Bugcheck Code 540 8.1.7 Bugcheck Code 540 This bugcheck code indicates that the software has detected a fatal problem in managing the memory buffers it uses to support internet connections. This version of software corrects a prob- lem where receiving a bad message on a PPP port using protocol field compression would result in this type of failure. 8.1.8 Bugcheck Code 0542 8.1.8 Bugcheck Code 0542 8.1.8 Bugcheck Code 0542 This error code occurs when the server needs to associate an operation with a port and can't do so. For example if it needs to display a message but can't determine which port it should use for output. This version corrects a problem with PPP and SLIP which would result in this type of failure. The failure would only occur if a user established a PPP or SLIP connection then returned to the Local> and executed a specific set of commands. 8.1.9 Bugcheck Code 0543 8.1.9 Bugcheck Code 0543 8.1.9 Bugcheck Code 0543 This error code occurs when the server encounters a problem reading NVRAM. This version of software corrects a situation where executing a small set of LIST commands from the remote console would result in this type of failure. 8.1.10 Bugcheck Code 896 8.1.10 Bugcheck Code 896 8.1.10 Bugcheck Code 896 Bugcheck code 896 indicates that the server detected a fatal error while trying to process an SNMP get request for port level session information. This version corrects a problem with multisessions which would result in this type of crash if the port targeted by the SNMP get request had more than 2 active sessions. 24 24 24 8.1.11 Bugcheck Code 0956 8.1.11 Bugcheck Code 0956 8.1.11 Bugcheck Code 0956 This bugcheck code indicates that a port tried to restart the authentication process while it was still active from a previ- ous login attempt. This image corrects several problems which would cause this to happen. o Hard and Soft copy ports would overrun an internal buffer and crash with this code if the they received a string of 131 characters followed by a ^R or ^U while prompting for an username or password. o Occasionally, if a port logged out just prior to issuing the Authentication "Username>" prompt the next person to log in would cause the port to make a second authentication request before the previous one had been terminated. 8.1.12 Bugcheck Code 0977 8.1.12 Bugcheck Code 0977 8.1.12 Bugcheck Code 0977 This code is generated when the software detects a problem with managing it's pool of free memory. It does not point to a specific feature as being at fault and it can be caused by problems in any of the components which make up the DNAS soft- ware. This version of software corrects several causes of this type of failure. o The first correction is for a problem encountered when one or more ports had Multisessions and Autoconnect enabled. The failure would occur while the port was attempting to reconnect a user following a LAT circuit timeout. o The second change corrects a problem with the way the server processed it's internal timers. The occurrence of the crash was unpredictable and very infrequent. o This version of software also corrects a problem which would result in this type of crash if the SHOW NODE SUMMARY or SHOW SERVICE SUMMARY commands were executed and one or more of the LAT service descriptors contained illegal characters. 8.1.13 Telnet Problems 8.1.13 Telnet Problems 8.1.13 Telnet Problems 8.1.14 Superfluous Telnet Option Negotiation Messages 8.1.14 Superfluous Telnet Option Negotiation Messages 8.1.14 Superfluous Telnet Option Negotiation Messages This version of software corrects a problem which caused the server to display an un-documented error message while negoti- ating Telnet options. The following message would be displayed if the host specified an option value not supported by the access server. 25 25 25 *** Bad Command From Peer *** The software's behavior has been corrected such that it will now ignore negotiation messages for unsupported option values. 8.1.15 Telnet Listener Port List Problem 8.1.15 Telnet Listener Port List Problem 8.1.15 Telnet Listener Port List Problem The following problem description applies only to DS900TM and DS900GM servers. The port list for a Telnet Listener can be viewed using the SHOW/LIST TELNET LISTENER ALL command. The "Ports:" field of the resulting display show's which ports are assigned to each listener. This version of software corrects a problem where updating a server from DNAS version 1.3 or earlier to DNAS V1.4 or later would cause the Telnet Listener port lists to be lost. The correction is only effective when going from version 1.3, or earlier, to this version. If the server is updated from V1.3 or earlier to V1.4 (any baselevel) or V1.5 (BL95-33, BL95B- 34, and FT95B.01 through FT95B.24) the port lists will be lost and must be restored manually. Loading V1.5 BL95D-34 will not restore them. However, port lists which have been defined in V1.4 or later are preserved when updating to this version. Going from this version of software back to V1.3 or earlier will cause the port list to become corrupted and will require that they be corrected manually. 8.2 PPP/SLIP Problems 8.2 PPP/SLIP Problems 8.2 PPP/SLIP Problems 8.2.1 Autolink Sometimes XOFF'd Input 8.2.1 Autolink Sometimes XOFF'd Input 8.2.1 Autolink Sometimes XOFF'd Input Specifying a DEFAULT PROTOCOL type of AUTOLINK enables a port, which has been configured for PPP and SLIP, to automatically start either a PPP or SLIP session based on the asynchronous data it receives. This version of software corrects a problem which would sometimes cause the port to XOFF input prior to determining the correct protocol type. Since input was disabled the port couldn't determine which protocol to start and since it couldn't start either protocol it wouldn't allow further input. 26 26 26 8.2.2 SLIP/PPP Network Connectivity 8.2.2 SLIP/PPP Network Connectivity 8.2.2 SLIP/PPP Network Connectivity This release corrects a problem which would have been encoun- tered when a PC or other SLIP/PPP device was moved from one access server to another. Prior to this change if a SLIP/PPP host had established a network connection to node A via server B and was then moved to server C it would not be able to es- tablish a network connection to node A until node A's ARP cache entry for server B had expired. With this version of software server C will now send an ARP request to cause other internet hosts to update their ARP cache. 8.2.3 Local Errors 504 and 503 8.2.3 Local Errors 504 and 503 8.2.3 Local Errors 504 and 503 This version of software corrects a problem where CONNECT PPP and CONNECT SLIP commands would be rejected with Local -504- and Local -503- messages. Because the problem was the result of a memory leak it would not occur until after the server had been operational for several days. Once it started to occur however it could only be cleared by re-booting the server. Because it was in a special area of memory and not one of the free memory pools it could not be identified as a memory leak using the SHOW SERVER STATUS or SHOW MEMORY STATUS commands. 8.3 Port Problems 8.3 Port Problems 8.3 Port Problems 8.3.1 Local Login Text Out of Sequence 8.3.1 Local Login Text Out of Sequence 8.3.1 Local Login Text Out of Sequence This version corrects a problem where session data such as the host's welcome banner would sometimes be printed ahead of the local connection established message. For example: Local> C TEST Unauthorized access is prohibited. Local -011- Session 1 to TEST on NODE TEST established. Username: 8.3.2 Port Hangs in Signal Wait or Session Mode 8.3.2 Port Hangs in Signal Wait or Session Mode 8.3.2 Port Hangs in Signal Wait or Session Mode This version of software corrects a problem where ports would hang in either the Signal Wait or Session Mode state. The prob- lem would only occur if the port had Modem or Signal Control and XON flow control enabled. The exact circumstances leading to the hang were unpredictable. 27 27 27 8.3.3 Problem with DTRwait 8.3.3 Problem with DTRwait 8.3.3 Problem with DTRwait This version of software corrects a problem where remote or dynamic access ports would not allow remote connections if DTRwait, Signal Check, and Modem or Signal Control were enabled at the same time, even if DSR was being asserted by the DCE. 8.3.4 Problem With DSRS and Ring Signals 8.3.4 Problem With DSRS and Ring Signals 8.3.4 Problem With DSRS and Ring Signals The asynchronous ports of the DS900TM, DS900GM and DS700 sup- port DSRS. When Ring is enabled on the port, along with either Modem or Signal control, the DSRS signal will toggle in re- sponse to a reverse connection being established. When used with the proper cables, for example a BC22R on a full modem control port, this feature allows the server to toggle the Ring signal at the modem. This version of software corrects a prob- lem introduced with DNAS V1.5 which prevented this from working on the DS700-8. The MONITOR PORT STATUS display would show DSRS switching on and off but the signal would not toggle at the connector. 8.3.5 Problems With Multisessions Terminals 8.3.5 Problems With Multisessions Terminals 8.3.5 Problems With Multisessions Terminals This following problems were specific to multisession (TDSMP) users. 8.3.5.1 All Ports Hang 8.3.5.1 All Ports Hang 8.3.5.1 All Ports Hang This version of software corrects a problem which occurs when multisessions (TDSMP) and menus are both enabled on a port. The problem was originally reported by a customer who had setup a menu containing several command groups. Each command group would terminate the current network session and attempt to establish a new connection to a different node. If the connect attempt was terminated abnormally, by a ^Z for example, before the username had been entered all ports on the server would hang until the server was re-booted. 8.3.5.2 Single Port Hangs 8.3.5.2 Single Port Hangs 8.3.5.2 Single Port Hangs The data flow between the server and a TDSMP terminal is con- trolled by the the use of transmit credits. The server tracks the number of credits it has extended to the terminal and re- plenishes the supply when it determines the terminal has used most of them up. This version of software corrects a problem caused by the fact that some third party terminals can't accept more than 128 credits. In some situations the server would ex- tend up to 192 credits but the terminal would only use 128 of 28 28 28 them. Since the terminal stoped sending data after the 128th character and the server would not replensish the credits until it received the 160th character the port would hang. 8.3.5.3 Single Session Hangs 8.3.5.3 Single Session Hangs 8.3.5.3 Single Session Hangs This version of software corrects a problem where Multisession users would loose one of their sessions if they powered down the terminal without completely logging out the port. The port would not perform a warm restart when the terminal was powered back on and as a result one of sessions would hang. The only way to recover the port was to completely log it out using the LOGOUT PORT command. 8.3.5.4 Combining Menus, Password, and DSRlogout Caused Login 8.3.5.4 Combining Menus, Password, and DSRlogout Caused Login 8.3.5.4 Combining Menus, Password, and DSRlogout Caused Login Problems Problems Problems This version of software corrects a problem which would cause ports to reject user input if Menus, Password, and DSRlogout were all enabled. The problem would occur if the device at- tached to the port dropped DSR while the user was being prompted for a menu selection. The port would appear to lo- gout properly but subsequent login attempts would fail. The '#' character would be displayed to prompt the user for a password but the server would respond to user input by sounding the BELL and re-issuing the '#' prompt. 8.3.6 DSR Status Incorrect 8.3.6 DSR Status Incorrect 8.3.6 DSR Status Incorrect Prior to this version the state of DSR was not tested dur- ing the server's initialization cycle. As a result a SHOW PORT STATUS command issued immediately after re-booting the server would indicate that DSR was asserted even if the at- tached device was powered down. The display could be corrected by logging out the port. 8.3.7 DS90M Hangs in Session_Mode 8.3.7 DS90M Hangs in Session_Mode 8.3.7 DS90M Hangs in Session_Mode If a reverse connection is terminated with output data pend- ing at the port due to an XOFF condition the port enters the Session_Mode state. The port should remain in this state until one of the following occurs. o The XOFF condition is cleared allowing the pending output data to be transmitted. o The pending output data is flushed. 29 29 29 One way to flush the output data is to log the port out twice from another port. For example, if port 3 is in Session_Mode because DSR is de-asserted and there's data waiting to be sent out the port, a privileged user on port 4 could issue the LOGOUT PORT 3 command twice to flush the data and return the port to the idle state. Prior to this version of software how- ever a DS90M port in Session_Mode would not flush the pending data in response to a LOGOUT PORT command if DSR flow control was being used and DSR was de-asserted. 8.3.8 Lost XOFF Characters 8.3.8 Lost XOFF Characters 8.3.8 Lost XOFF Characters This version corrects a problem with loosing XOFF characters if a device such as a printer sends the server an XOFF at the very end of a print job. 8.4 DNS Problems 8.4 DNS Problems 8.4 DNS Problems 8.4.1 Stub and Slave Name Resolution Modes Might Fail 8.4.1 Stub and Slave Name Resolution Modes Might Fail 8.4.1 Stub and Slave Name Resolution Modes Might Fail Setting the server's Name Resolution to STUB or SLAVE mode dis- ables the server's caching of learned nameservers. Instead, the server depends on the locally defined nameservers to recur- sively search for the name. This version of software corrects a problem which would cause this to fail if the first nameserver queried was unavailable and none of the other nameservers were able to supply an authoritative response. The correction en- sures that the Recursion Desired bit is set not only in the original query but also in retries. 8.5 Authentication Problems 8.5 Authentication Problems 8.5 Authentication Problems 8.5.1 Authentication Timeout 8.5.1 Authentication Timeout 8.5.1 Authentication Timeout This version of software corrects a problem which resulted in persistent authentication timeouts after several weeks of operation. Login attempts would be rejected with the following messages: Local -450- Attempting to authenticate user: local -454- Authentication failed timed out 30 30 30 8.5.2 Authentication Error 3008 8.5.2 Authentication Error 3008 8.5.2 Authentication Error 3008 This version of software corrects a problem which resulted in authentication requests failing with an error code of 3008. This error code indicates that the access server is experienc- ing an internal error which prevents it from communicating with the Kerberos server. The failure responsible for the authentication 3008 problem would have affected other internet protocols because it created a memory leak in an area of memory reserved for IP message handling. Once this memory was used up any operation requiring IP would have failed and continued to fail until the server was re-booted. 8.5.3 KPASSWD Operation Was Unreliable 8.5.3 KPASSWD Operation Was Unreliable 8.5.3 KPASSWD Operation Was Unreliable The access server allows users to change their Kerberos pass- word via the KPASSWD command. This version of software corrects a problem which caused the command to fail intermittently. At times the command would appear to be successful but would be delayed in updating the Kerberos server. At other times the command would be rejected with the following local message. Local -467- Authentication failed, protocol error: 7013 The problem has been corrected and the KPASSWD command will update the Kerberos server. However, there's a known problem with Digital Authentication Server V1.0 that causes the access server to display the following message despite the successful completion of the command. Local -467- Authentication failed, protocol error: 7014 If you experience this problem contact your local DEC Field Service representative or DEC CSC for the latest DAS updates. 8.6 LAT Problems 8.6 LAT Problems 8.6 LAT Problems 8.6.1 16 Character Port Names 8.6.1 16 Character Port Names 8.6.1 16 Character Port Names This version of software corrects a problem encountered on host initiated connect requests. Prior to this change the access server would not supply a source port name in the start slot if the port name was equal to 16 characters. 31 31 31 8.6.2 Immediate Access Rejected Code 8.6.2 Immediate Access Rejected Code 8.6.2 Immediate Access Rejected Code When a port logs out it goes into a modem signaling wait state during which time it de-asserts it's modem signals. If modem control is enabled this period will last 5 seconds. If modem control is disabled it will last approximately 10 milliseconds. Prior to this version of software if a connect request was received for the port during this modem cycle time the server would return a Service In Use reject code. Now the server will return an Immediate Access Rejected code to indicate that the port will be available momentarily. If the port is part of a port list for a requested service the IAR will only be returned if all other ports are unavailable. This change only affects connect requests. If the server receives a start slot on a reverse circuit it will still return a Service In Use reject code during the modem cycle time. 8.6.3 DATA_B Slots Needed to be a Minimum Size 8.6.3 DATA_B Slots Needed to be a Minimum Size 8.6.3 DATA_B Slots Needed to be a Minimum Size The LAT protocol uses DATA_B slots to pass configuration, er- ror, and BREAK signaling information between the server and the host. Prior to this version of DNAS DATA_B slots less than 5 bytes long were discarded. This caused problems in situations where a host wanted to signal a BREAK to the server but didn't want to incur the overhead of unused bytes. Since the BREAK can be sent with a single byte the host would send the server a DATA_B slot with a length of 1. The server considered this to be a bad slot and discarded it. 8.6.4 Characters Transposed after a BREAK 8.6.4 Characters Transposed after a BREAK 8.6.4 Characters Transposed after a BREAK This version of software corrects a problem where the first two characters received by the asynchornous port following a BREAK signal would be transposed. For example, if a user pressed the terminal's BREAK key then entered the text "abc". The string "bac" would be sent to the remote host. The problem only oc- cured when the server was acting as a slave (host) device on a reverse connection. 8.6.5 LAT Local Service Port List Problem 8.6.5 LAT Local Service Port List Problem 8.6.5 LAT Local Service Port List Problem The following problem description applies only to the DS900TM and DS900GM servers. This version of software corrects a problem where updating a server from DNAS version 1.3 or earlier to DNAS V1.4 or later would cause the local LAT services port lists to be lost. This would result in local services being denied or directed to the wrong port. The correction is only effective when going from version 1.3, or earlier, to this version. If the server is 32 32 32 updated from V1.3 or earlier to V1.4 (any baselevel) or V1.5 (BL95-33, BL95B-34, and FT95B.01 through FT95B.24) the port lists will be lost and must be restored manually. Loading V1.5 BL95C-34 will not restore them. However, port lists which have been defined in V1.4 or later are preserved when updating to this version. Going from this version of software back to V1.3 or earlier will cause the port list to become corrupted and will require that they be corrected manually. 8.6.6 LAT queuing Problem 8.6.6 LAT queuing Problem 8.6.6 LAT queuing Problem This version of software corrects a problem where LAT Queued Access Requests were queued by the server instead of being rejected if the port was set to an access type of LOCAL or NONE. 8.6.7 LAT Circuit Failure 8.6.7 LAT Circuit Failure 8.6.7 LAT Circuit Failure This version of software corrects a problem where all the users of a LAT circuit would be disconnected from the host if any port received a BREAK signal while attempting to establish a connection. 8.7 Problems with Flash RAM 8.7 Problems with Flash RAM 8.7 Problems with Flash RAM 8.7.1 Problem with Flash Update 8.7.1 Problem with Flash Update 8.7.1 Problem with Flash Update This version of software corrects a problem where a Flash card programmed on a DS700-16 or a DS900 (TM or GM) would cause the hardware description contained in some displays to be in- correct. The problem would occur if the card were programmed on a DS700-16 or DS900 then used to boot a DS700-8. For exam- ple, programming the Flash on a DS900TM then using it to boot a DS700-8 would cause the SHOW SERVER command to display the server type as DS900TM. The problem was limited to displays, the MOP ID, and sysid messages. 8.7.2 Incorrect Version Information 8.7.2 Incorrect Version Information 8.7.2 Incorrect Version Information The DS90M contains internal Flash RAM which can be programmed with a compressed version of DNAS software. The programming process updates the Flash boot block with information describ- ing the Flash contents including the name and revision level of the software. Executing a SHOW MEMORY command reads and dis- plays the contents of the boot block. This version of software corrects a problem which resulted in misleading information being displayed. Prior to this release the software version information supplied by the command erroneously indicated a revision level of V1.4 BL95-32 instead of V1.5 BL95-32. When 33 33 33 programmed with this image the Flash RAM will now display the correct base level number. 8.8 Memory Leaks 8.8 Memory Leaks 8.8 Memory Leaks The term 'memory leak' is used to describe a condition where the amount of free memory available to the software decreases over time. In such situations the server operates properly after initialization but eventually starts to reject user com- mands. In most cases the command is rejected with the message: Local -719- insufficient resources to complete operation If the server is failing and a memory leak is suspected the SHOW SERVER STATUS command can be used to display the per- centage of memory currently in use. A value of 80% or more might indicate a memory leak. Please refer to the DNAS _______ Problem section 2.1.4 for more information on verifying _______ _____ Solving Guide memory usage. This version of software corrects memory leaks caused by the following commands. o HELP o SHOW PORT STATUS o SHOW PORT SUMMARY o SHOW PORT SESSION CHARACTERISTICS o SHOW PORT SESSION STATUS o SHOW PORT TELNET CLIENT o SHOW PORT TELNET SERVER o SHOW PORT TN3270 KEYMAP o SHOW PORT TN3270 CHARACTERISTICS o ZERO PORT PPP o ZERO PORT SLIP o ZERO COUNTERS ALL 34 34 34 The memory leak caused by the HELP command could be observed by using the SHOW MEMORY STATUS command to monitor High Pool memory. The amount of High Pool in use would increase each time the command was executed. The memory leak caused by the SHOW PORT commands would also cause the amount of High Pool in use to increase but only after the command had been repeated hundreds of times. 8.9 DS900TM/DS900GM Specific Problems 8.9 DS900TM/DS900GM Specific Problems 8.9 DS900TM/DS900GM Specific Problems 8.9.1 Server Won't LAN hop 8.9.1 Server Won't LAN hop 8.9.1 Server Won't LAN hop The term "LAN hop" refers to the server's ability to be re- configured onto different LANs when it's installed in a DEChub 900. Currently, when the term LAN hopping is used in this doc- ument it applies only to the DS900GM (DSRVY) and the DS900TM (DSRVZ) This version of software corrects a problem where HUBwatch could not re-configure the server to connect to a different LAN immediately following a power-up. The problem would occur if the following steps were performed. o Install the server into a DEChub 900. o Disconnect both channels then reconnect them to the desired Ethernet LAN. At this point the HUBwatch LAN view display would indicate that the operation was successful. However attempts to connect into or out of the server would fail. o Disconnect both channels then re-connect them to the desired LAN. This second attempt would be successful and the server would connect to the LAN. 9 How to Report a Problem 9 How to Report a Problem 9 How to Report a Problem If you discover a problem with the operation of the DECserver Network Access Software, please submit a Software Problem Report (SPR). When completing an 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 a crash dump. Because problems are often difficult to reproduce with dif- ferent 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 35 35 35 and indicate the sequence of events or commands that caused the problem. Attempt to reproduce the situation, if possible, using the minimum number of steps. If one of your user programs causes a problem in the DECserver and you are unable to send the program to Digital, try to re- produce 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 problem information, 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. 9.1 Documentation Problems 9.1 Documentation Problems 9.1 Documentation Problems When describing a problem found in a manual, specify the full title of the manual and identify the appropriate section, ta- ble, or page number. Describe what the manual says and also describe the suggested correction. If you are reporting an error with online help, please identify the full command and screen, and specify TUTORIAL or REFERENCE help. To send comments on this product, documentation, or online help electronically, send mail through the Internet to: doc- quality@lkg.mts.dec.com 9.2 Severe Errors 9.2 Severe Errors 9.2 Severe Errors Severe errors may cause your DECserver to hang or bugcheck. If your DECserver hangs for more than 90 seconds, you will have to power down and up to restore normal operation. If this should occur, please describe the operating conditions on the DECserver at the time of the hang. If a FATAL BUGCHECK occurs, a bugcheck message is printed 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 repro- duced. You can force a CRASH by typing CRASH at the local mode prompt in privileged local mode. A code 300 fatal bugcheck will immediately occur. 36 36 36 The location of the crash dump file may be determined as fol- lows: o After the DECserver reinitializes, enter local mode and enter 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. OpenVMS systems: OpenVMS systems: OpenVMS systems: o The crash dump will be located in the SYS$COMMON:[DECSERVER] directory on the dump host, and the filename will be NA9xxxxxx.DMP, or NA7xxxxxx.DMP where xxxxxx is the DECnet node name assigned to the network ac- cess server as defined using the DSV$CONFIGURE configuration procedure. For example, if the DECserver 90TL with node name LAT041 bugchecks, the crash dump will be found in SYS$COMMON:[DECSERVER]DS9LAT041.DMP on the dump host. ULTRIX systems: ULTRIX systems: ULTRIX systems: o The crash dump will be located in /usr/lib/dnet on the dump host and the filename will be DS9xxxxxx.DMP or DS7xxxxxx.DMP where xxxxxx is the DECnet node name assigned to the network access server as defined using the DSVCONFIG configuration procedure. For example, if the DECserver 90TL with node name LAT041 bugchecks, the crash dump will be found in /usr/lib/dnet/ds9lat041.dmp on the dump host. Digital UNIX and other UNIX systems: Digital UNIX and other UNIX systems: Digital UNIX and other UNIX systems: o The crash dump will be located in the /tftpboot directory. The file name will be one of the following: o WW_xxxxxx.DUMP o WWxxxxxx o MN_xxxxxx.DUMP o MNxxxxxx o Copy the crash dump file to TK50 (preferred), magnetic tape, or another media. If these media types are not available, indicate the format of the copy (COPY, BACKUP, FLX, etc.) on a label. All media sent to Digital will be returned to the sender. 37 37 37 Appendix A Appendix A Appendix A RADIUS Attributes Supported in this Release RADIUS Attributes Supported in this Release RADIUS Attributes Supported in this Release Please refer to the document RADIUS_SURVIVAL.TXT (or very simi- lar file name) on your kit distribution media for a description of the supported RADIUS Attributes for this release. RADIUS Attributes Supported in this Release A-1 RADIUS Attributes Supported in this Release A-1 RADIUS Attributes Supported in this Release A-1