Release Notes 93000221G for PORTSERVER II Operating System 40001260G Version 3.0.4 Product Manual P/N 90030500B Command Reference Guide 92000246A Oct 31,1997 Introduction These release notes provide information on PortServer II OS version 3.0.4. The include information on the following: - Incompatibility between older versions of the PortServer II OS and this one, which can affect your configuration. - ROM limitations for those with Pre-Rev K Model PortServer IIs. - Limitations for systems with fewer than 2 Mb of memory. - Manual errata. - Upgrading flash ROM. - Changes to the OS since it went through beta testing. - Bug fixes in this release. These include both bugs reported in Problem Report Numbers as well as some that were not reported. Pre-3.0 Incompatibility Notice This version (3.0) of the PortServer II OS is incompatible with versions older than 3.0. Certain parts of the non-volatile storage formats used to store configuration information have been changed. Consequently, if you want to use this version of the OS and preserve your current configuration, you must use the cpconf command to save your configuration to a host and then restore it once the new version of the PortServer II OS has been installed. Pre-Rev K Model ROM Limitations The addition of Frame Relay to 3.0 and later versions of the OS causes the size of the boot image to exceed the space available in the PortServer II flash ROM for units built prior to the Rev K models. Consequently, you want to use a 3.0 or later OS with these older units, you must do one of the following: - Boot PortServer II via TFTP over the ethernet port. - Acquire a smaller version of the OS, which does not have Frame Relay, this is available fro the Digi ftp site. Limitations for Systems with 2 Mb of Memory Testing has determined that the PortServer II's standard 2 Mb of installed memory is inadequate in the following instances and is likely to require an expansion to at least 4 Mb. - Full 64 port configurations in which more than 50 asynchronous and/or TCP users are simultaneously using PortServer II. This include users accessing PortServer II via the ethernet connection or any type of connection using the serial ports. Note: Exceeding this number of users is unlikely in RealPort environments because each RealPort connection is seen as a single user. This means that while that user may control more than one port, if there is only one host connected to the PortServer II using RealPort, it will use only a little more memory than someone making a telnet connection. If more than one host is using PortServer II as a RealPort server, each host will have it's own TCP connection, and therefor each is considered a user. It is unlikely that a site will have enough RealPort connections to cause problems. - Sites with heavy traffic on serial ports. Here the problem is simply throughput. Degradation of performance may indicate that additional memory is called for. Manual Errata Page 47 of the PortServer II User's Guide (90030500) incorrectly states that a V.24 cable is supplied with the PortS- erver II. This cable is not included. Sync parameters are automatically set when FrameRelay. To ensure proper operation of the Synchronous Port the port must be set to "dev=term" OR "dev=prn". It is further recommended that all setting contained in "set flow" be set to "off". Upgrading Flash ROM Should it be necessary to update the PortServer II OS contained in Flash ROM on your PortServer II, the recommended procedure is: 1. Obtain the new version of the software from Digi and place it on your TFTP server. 2. Save your current configuration using cpconf. This should not be necessary, but it is advisable to maintain a backup of your current configuration when re-writing a sizable portion of flash. 3. Boot your portserver with the new operating system via TFTP, by using set config boothost=hostip bootfile=filename tftpboot=yes, and then rebooting your PortServer. See page 45 of the User's Guide and Reference Manual for more details. This step ensures that you have a good copy of the new version of the software, and also that you can still boot your PortServer II in the unlikely event that your flash image gets corrupted in the process of writing it. 4. After booting your PortServer via TFTP, load the new version of the software into the flash ROM by using the command boot load=host:filename. If all goes well, the PortServer will reply "The image now in flash memory appears valid." 5. Now you can return your PortServer II to booting from its flash ROM image by entering the command set config tftpboot=no. Change from Beta - Miscellaneous routing fixes have been made. - The TFTP timeout algorithm was improved. - The RealPort daemon will survive ICMP messages in a more reliable manner. - In the cases where PPP is started before the identity of the remote is known, the async map starts out a 0x00000000, not 0xFFFFFFFF. The result is we don't have to go through LCP negotiations twice if the user's desired async map is 0x00000000 (most often the case). Also, the software flow control flags on the port are checked, and if set, the flow control characters are used to determine the async map. - PPP changes, mostly to work through problems connecting with Microsoft Windows NT. Bug Fixes The bug fixes addressed by this release include, but are by no means limited to: 1. PR# 5118, 5258 - Reboot problems, primarily induced under load. 2. PR # 5261 - The RealPort server in the PortServer did not receive the notification from TCP that a connection had been dropped. Therefor the server never released the ports and subsequent attempts to establish realport connections to ports were rejected. 3. Changing flow control from both RTS/CTS flow and XON/XOFF flow to just one type flow control while the port was in a flow control state sometimes would result in a condition where flow control would not release properly. This affected only the base ports, not ports on the EM modules. 4. Fixed a DMA addressing problem which affected the PortServer's base ports. This occasionally resulted in dropped data. 5. Apparent memory leaks which manifested themselves when a network interfaces, whether on ethernet or on the serial ports, would go down for long periods of time were the result of data being added to the bottom-most queues without checking the high water levels. Checks are now in place to ensure this does not occur. 6. The timeout for re-request of a TFTP packet has been increased to allow more time on "noisy" networks. Important Note: Testing has determined that the PortServer's standard 2 Mb of installed memory is inadequate for full 64 port configurations. Each of the users requires a certain amount of contiguous memory when attempting to access a port on the PortServer, whether that port be a serial port or a TCP port. As the size of the code has increased, the amount of free memory available to user tasks has decreased, this in conjunction with the pre- allocated buffers for each port has resulted in an effective limit of approximately 50 users. This limit can be removed with the replacement of the 2Mb SIMM with one of at least 4Mb. There are also other situations where the 2Mb SIMM may not be the optimal size. If the PortServer is used at a site where there is normally high traffic on the serial ports, more memory may allow higher throughput, as there will be more buffers available to STREAMS. If there are 1 or 2 expansion modules, there is enough memory to allow the use of each port, with enough memory available to effectively send and receive data. In spite of that, as data rates rise, this site may benefit by adding more memory. This situation is unlikely to be a RealPort issue, as each RealPort connection is seen as one "user". This means that while that "user" may control more than one port, if there is only one host connected to the PortServer using RealPort, it will use only a little more memory than someone making a telnet connection to the PortServer. If more than one host is using that PortServer as a RealPort server, each host will have it's own TCP connection, and therefor is considered to be a "user". It is unlikely that a site would have enough RealPort connections to a PortServer to cause the problems described above. If a site is doing something like this, increasing memory may be of benefit.