---------------------- LANtronix ---------------------- LRS ---------------------- Remote Access Servers ---------------------- Software Release Notes ---------------------- Version V1.3/4 May 29, 1998 Copyright (c) 1998, 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. This document describes the Lantronix Remote Access Server software release. Release Summary =============== V1.3/4 provides remote access functionality for the LRS1, LRS2, LRS16 and LRS32F remote access servers. This release is primarily a maintenance release, but it does introduce several new features. NOTE: Lantronix recommends using the V1.2/1 version of the 32-Bit Windows Redirector with LRS Version V1.3/4 software. Users of the 16-Bit Windows and DOS redirectors need not upgrade. See the Redirector release notes for more details. New Feature Summary =================== The following is a list of new features in V1.3/4. Authentication and Command Strings ---------------------------------- A new command has been added to provide a way for the sysadmin to configure a command string to be executed on the LRS after Authentication completes even if the user is authenticated via Kerberos, Netware, TFTP or Secureid. (Unlike commands defined in the local authentication database or sites created via Radius support, these methods don't provide any way to execute a command after authentication succeeds.) Use the command syntax: DEF AUTH USER xxx ALTCOMMAND [Enabled|Disabled] and enter the command to be executed using the syntax: DEFINE AUTH USER xxx COMMAND "lrs_command" This command does NOT apply to Radius authentication, since Radius can provide its own command line. You CANNOT have a local user in the database with both a password (for Local Authentication) and Altcommand Enabled, since they use the same location to store the password and the command string. The LRS will issue a warning message if a password field is overridden with an AltCommand, and vice versa. Time of Day Site Dialing ------------------------ Sites can now be configured to dial at a particular time of day. Use the command syntax: DEFINE SITE site_name TIME FORCEDIAL If this attribute is created for a site, the site will always attempt to create a connection at this time of day, everyday. Permanently Connected Sites --------------------------- Sites can now be configured to be permanently up. Use the command syntax: DEFINE SITE site_name PERMANENT [ENABLED|DISABLED] If enabled, the site will connect immediately after the LRS boots and will reconnect if for any reason the site goes down. Miscellaneous New Functionality ------------------------------- Finger connections from the network can no longer get the detailed process info of the "finger finger" display. Instead, the LRS will return user information, the LRS nodename and the uptime. SNMP enterprise IDs are now unique and meaningful. Since LAT is not included in the LRS code set, the "Connect" command was changed to work the same as the "Telnet" command. Syslog facilities that have numeric levels now allow the "MAX" keyword. Specifying "MAX" will force the level to its highest allowed setting. The SHOW IPX ROUTE command can now take an optional route parameter. If the parameter is specified, information for just that route will be displayed. Sitenames have been added to IP routing syslog messages. An initial "site up" syslog message that displays the site logging level was added. Resolved Problems ================= The following problems have been fixed in V1.3/4. Authentication -------------- Using the DEFINE PORT PPP CHAP REMOTE command would not disable the PPP CHAP LOCAL option. If both remote and local chap authentication is required, use the DEFINE PORT PPP CHAP BOTH command. General ------- Incorrect buffering for MONITOR LOG MEM could cause an LRS2 crash. The command line/help handler could overwrite a memory buffer if random characters were received by the serial port at high data rates. This could corrupt memory and cause a server crash. A command line parser error caused the parameter "BANDWITDH MAX xxx" to be interpreted as "MTU xxx." The PURGE PORT command was not accepting the keyword "ALL" as the list of ports to purge. SHOW PORT would occasionally report a port in "Local Mode" when it wasn't. Syslog messages sent early in the boot sequence could have been discarded by the IP log host, since the checksum was calculated incorrectly. If an outbound call attempt failed repeatedly, the LRS could have lost resources such that it couldn't make any other calls. The counters incremented for flow control events were wrong in some cases. On the LRS2, if the AUTOSTART, MODEM CONTROL and xxxDETECT characteristics were all enabled, an extra carriage return was required to login to the server. When transmitting packets on a very busy LRS16, the ethernet driver could cause prototols to hang waiting for their packets to be sent out on the net. On the LRS16, port 1 (the console port) was not useable for PPP connections. On the LRS16 and 32F, serial ports could get "stuck" and would be non- responsive until logged out. IP -- If an IP packet needed to be fragmented but the DontFragment bit was set, the LRS was not informing hosts via ICMP messages. This could cause packet loss due to incompatible MTU values. If an unsolicited DNS "Auth-Record" was recieved, the LRS could crash. Service sockets were subject to the Incoming Telnet flag, and shouldn't have been. TCP header compression had a bug in the sequence number calculation which resulted in poor performance due to excessive retransmissions. RTEL and LPR could mishandle printjobs with invalid service names. Some eight-bit control characters were not correctly passed through to the destination printer when printing via LPD. SNMP community names were not being length checked. (The LRS limits the community name length to 14 characters.) Remote Networking ----------------- If ports were logged out or a PPP connection was terminated in abnormal ways, the port could get stuck in a "dial" or "transition" state. When UDP broadcasts are sent out a remote node connection, the idle timer for that connection was being updated. This had the effect of never allowing a remote node connection to timeout. If PPP links cycled quickly, the network protocols might not be notified, l eading to inconsistent site/route tables. Multilink connections were not correctly handling NCP negotiation on all links. After starting a multilink connection, a bandwidth check was made. If no traffic had gone across the new link before the calculation happened, the LRS incorrectly calculated the bandwidth and would drop the new link. Filters were not applied to packets directed to the LRS itself. Radius ------ When using radius to specify a dailback connection, the telephone number supplied by the radius response was not being saved correctly. This would cause the dialback attempt to fail. Inconsistencies in the way CBCP and Radius handled dialback were resolved. Using Radius authentication with login dialback was not working correctly. Known Problems ============== The following problems are known in V1.3/4: Appletalk --------- Due to design decisions made by Telebit, the LRS is not able to perform AppleTalk LAN-to-LAN routing with the Telebit Netblazer. 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. The LRS2 serial hardware appears to be incompatible with the Motorola V.3400 modem. The LRS2 cannot communicate reliably with these modems at speeds above 38400 bps. 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. RADIUS ------ When using PPP and CHAP authentication in conjunction with RADIUS authentication, the LRS generates RADIUS packets with the CHAP-Challenge attribute. This is necessary due to the length of the challenge the LRS uses in CHAP authentication (64 bytes). Many older RADIUS servers do not support this attribute and are therefore incapable of authenticating users who are attempting to authenticate themselves via CHAP on the LRS. The LRS's use of the CHAP-Challenge attribute is in compliance with the IETF's RADIUS document, RFC 2058.