---------------------- LANtronix ---------------------- LRS1 / LRS2 / LRS16 ---------------------- Remote Access Servers ---------------------- Software Release Notes ---------------------- Version V1.3/1 January 14, 1997 Copyright (c) 1997, Lantronix Release notes are also available via Kermit using the Lantronix media support and download system or via anonymous FTP from ftp.lantronix.com. Contact Lantronix or your reseller for more information. Release Summary =============== V1.3/1 A new feature release. V1.2/2 A maintenance release. V1.2/1 A new feature and LRS1 support release. V1.1/1 A new feature and LRS16 support release. V1.0/3 A maintenance release. V1.0/2 A maintenance release. V1.0/1 Initial software release for the LRS2. NOTE: USR Sportster and Courier modem users MUST change their modem switches after upgrading to V1.3/1 from versions BEFORE V1.2/1. Enter `DEFINE PORT 2 MODEM TYPE n', where "n" is your USR modem type. The LRS will display the required switch settings. Set the switches, power cycle your modem, then reboot the LRS. If you would like to use a new modem template, you must re-enter the DEFINE PORT 2 MODEM TYPE n command. New Feature Summary =================== The following is a list of new features in V1.3/1. Basic details of the new features are described below. The LRS Reference Manual and EZCon have been updated and contain more information. AppleTalk Routing ----------------- The LRS is now capable of routing AppleTalk over PPP for both LAN-to-LAN and remote node applications. For remote node connections, the FCR LinkUPPP! client is recommended. An evaluation copy is available at http://www.fcr.com. NetBios Nameserver Support -------------------------- Two commands were added to allow the LRS to pass the IP addresses of up to two NetBios WINS nameservers to IP PPP clients. They are SET/DEFINE PROTOCOL IP [SECONDARY] NBNS xxx.yyy.zzz.aaa Lantronix Redirector for Windows 95 Support ------------------------------------------- The LRS can now perform out-of-band communications with the Windows 95 Redirector to better support modem pooling. Enhanced Modem Support ---------------------- The LRS now automatically parses the modem's CONNECT string in an attempt to recover the link speed. Whenever possible, LRS modem profiles now configure the modem to report this information in their connect string. If you'd like to use the latest initialization strings with your modem, you must reissue the `DEFINE PORT [N] MODEM TYPE' command. Be advised that executing this command will destroy customizations you may have made to the default initialization strings. In addition, the LRS can parse Caller ID information from modems capable of decoding Caller ID signals. Caller ID and link speed information can be viewed with the following command: SHOW PORT [N] MODEM STATUS The following commands were added to support external Caller ID monitoring as well as the LRS's Caller ID recording facilities: SET/DEFINE PORT [N] MODEM ANSWER RINGS 1/3 SET/DEFINE PORT [N] MODEM CALLERID ENABLED/DISABLED In addition to the SHOW PORT MODEM STATUS display, Caller ID information is also reported by the LRS's logging facility (Modem Logging level 2 or above) and in RADIUS authentication and accounting packets. Please see the LRS Reference Manual for details on setting up the LRS to report Caller ID information. Windows 95 Dialback Support --------------------------- The LRS now supports the initial draft of the Microsoft Callback Control Protocol (CBCP) for PPP. This enables the LRS to perform dialback with the Windows 95 PPP client. Please see the LRS Reference Manual for full details on configuring CBCP. Miscellaneous ------------- Another variation of the Test command was added, to allow users to manually dial a remote site without having to force packet traffic across. The syntax is TEST SITE sitename When the command is issued, the LRS will attempt the connection and return basic status information. If detailed status is needed, users should use the Logging feature of the LRS. Users will have to manually shut down the site connection - it will not be brought down unless the site timeout is reached with no packet traffic. Port logouts are now recorded via the LRS's system logging facilities. A command has been added to allow only one authenticated instance of a given username to be logged into the LRS at any given time: DEFINE AUTHENTICATION UNIQUE ENABLED/DISABLED Another command has been added to zero the counters associated with the LRS's ethernet port: ZERO COUNTERS ETHERNET Resolved Problems ================= The following problems have been fixed in V1.3/1: Authentication -------------- The RADIUS Framed-IP-Address attribute was not fully supported in earlier versions of the LRS. Values of 255.255.255.255 (user-selected address) and 255.255.255.254 (NAS-selected address) are now supported. General ------- On ports with CTS/RTS flow control enabled, it was previously possible for the port to become unable to transmit any further data if the CTS signal was low when the port cycled from in-use to idle. This problem has been resolved. The PURGE PORT command now clears all port fields including PPP and modem settings. Ports with their access attribute set to remote no longer spend inordinate amounts of time in "Local Mode" rejecting serial input. Instead, they now cycle back to idle in a timely fashion. System logging now correctly reports priority and facility values to Unix hosts. Port and user counts on the SHOW SERVER display are now correctly updated. IP -- Several minor problems in the IP router's handling of secondary IP interfaces have been resolved. The LRS's SNMP engine has been revamped. SNMP users should see no difference in operation other than slightly more complete MIB support. Formerly, in Telnet connections, the LRS padded all Carriage Return (CR) characters with a Null character unless the next character was a Linefeed (LF). Problems result from this strict interpretation of the Telnet specification when attempting to do ZModem file transfers over an LRS-to-Unix telnet connection. The LRS now pads all CR's with a Null regardless of the next character. When creating packet filters, you can now use HTTP as a synonym for port 80. IPX --- A problem in the IPX router which caused responses to the IPX "Get Nearest Server" request with incorrect information has been resolved. Limits have been placed on the total number of RIP and SAP entries in the IPX routing table. If IPX logging is enabled, the system logging facility will generate messages if these limits are exceeded. Remote Networking ------------------ The LRS no longer responds to the first few IP, IPX or AppleTalk packets across a PPP link with protocol reject messages. Problems with Multilink PPP in high bandwidth situations have been resolved. Problems with site idle timeouts have been corrected. The idle timeout filter now works as documented. Modems ------ A problem where the LRS would fail to drop DTR after an outgoing site shuts down has been resolved. In instances where the modem prefix (typically AT) and/or modem dial command (typically DT) where unusually long (over 10 characters total), previous versions of the LRS firmware would fail to dial. The problem has been resolved. Formerly, Telnet and EZCon users could cause a modem port to become unresponsive by logging the port out and disconnecting their Telnet or EZCon sessions within 3 seconds. This problem has been resolved. Reference Manual ---------------- A number of updates and additions have been made to the LRS Reference Manual. A copy of the latest reference manual can be found on the Lantronix web page (http://www.lantronix.com) or on the Lantronix CD version number CD_01_10. If you require a printed manual, please print the postscript file contained on the CD or contact Lantronix Customer Support. Known Problems ============== The following problems are known in V1.3/1: Bandwidth on Demand ------------------- If PPP logging is enabled, the message `Peer rejected protocol 0x0000' may be seen when bandwidth is added. This is a symptom of packet loss. The first packet transmitted by the caller is sometimes lost after bandwidth is adjusted. In general, this should have a very limited effect on performance. General ------- Due to a hardware limitation, autobaud does not function with all speeds and all parity/stop bit settings. At the higher speeds (19200- 115200), attempting to jump more than 3 speeds (i.e. from 115200 to 19200) is not supported. A setting of 8 bits, no parity works the best. Autobaud functionality should not be required for modem use on the LRS. IPX --- Use Netware VLM client 1.20 or greater to achieve the greatest performance. Earlier versions of the client do not handle low speed connections gracefully. IP -- Remote networking startup logging will report an incorrect IP address and protocol if the packet originated from the LRS. RIP packets may not always be delivered to the remote location immediately after a connect. Traffic flows normally within five to twenty seconds. If PPP logging is enabled, the message `Peer Rejected Protocol 0x800' may be seen. This message can safely be ignored. Modems ------ Currently, the LRS does not gather post-call statistics. This option will be implemented at a later date. In some cases, changes to a port's modem profile may not be downloaded to the modem. If this occurs, make a minor change to the profile and log out the port. For example: DEFINE PORT 2 SPEAKER DISABLED LOGOUT PORT 2 Modems are not reset to their Non-Volatile (NVR) setting after an outgoing LAN-to-LAN call. This should not affect operation unless a site's dial string changes a modem's setup. PPP --- The LRS cannot negotiate IPXCP according to RFC 1552 with the Cisco version 10.2. A workaround is to define the LRS's IPX network number to always be lower than the Cisco's network number. The Cisco router will accept the connection as long as it `wins' the negotiation and can choose its network number. Otherwise, the Cisco router ignores incoming traffic from the LRS. The LRS cannot negotiate IPXCP according to RFC 1552 with the Livingston Portmaster version 3.1. A workaround is to define the LRS's IPX network to be always be equal to the Livingston router's network number. Otherwise, the Livingston router ignores incoming traffic from the LRS.