---------------------- LANtronix ---------------------- LRS ---------------------- Remote Access Servers ---------------------- Software Release Notes ---------------------- Version V1.3/5 May 23, 2000 Copyright (c) 2000, 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/5 provides remote access functionality for the LRS1, LRS2, LRS16F and LRS32F remote access servers. This release is primarily a maintenance release, but it does introduce several new features. New Feature Summary =================== The following is a list of new features in V1.3/5. Authentication For Socket Connections ------------------------------------- Full authentication has been added for socket connections from a host to a port on the LRS. Enable this authentication with the command: DEFINE PORT nn PASSWORD INCOMING ENABLED When a user forms a socket connection, they will be prompted for a username and password. The data entered will then be verified according to the normal LRS authentication methods and precedence table. Network Address Translation --------------------------- Network Address Translation (NAT) functionality has been added. To setup NAT, the network administrator will have to select a private network range for the "local" devices and will have to have a single "valid non-private" IP address for the LRS. To configure NAT support: 1. Define the LRS's IP address to an address on a private subnet. (DEFINE PROTO IP IPADDR 192.168.13.1) 2. Create the site that will dial-up the ISP. Set the IP address of the site to the single non-private address for your network. (DEFINE SITE FOO IP ADDRESS 201.73.220.92) Note that this will turn that site interface into a NUMBERED interface. 3. Enable NAT on the LRS. (DEFINE IP NAT ENABLED) 4. Configure the NAT parameters if needed. (LIST IP NAT) The default parameters are good enough for most situations. 5. Configure the LRS as the gateway on the machines on the private network (e.g. 192.168.13.2, .3, etc). Where possible, set the default route/gateways for machines in the private network to the LRS's IP address. Miscellaneous New Functionality ------------------------------- Support has been added to allow a break sequence to be passed from a PC running the COM port redirector software to a serial port on the LRS. This requires COM port redirector software B1.2/401 or greater. Up to 32 services are now allowed on the LRS32F. Resolved Problems ================= The following problems have been fixed in V1.3/5. Authentication -------------- When using the "CONNECT LOCAL" command username/password authentication was not behaving correctly. When sending Radius authorization requests for outgoing socket connections, use the "OUTBOUNDUSER" Radius server type. In addition, Radius accounting was added for outgoing socket connections. General ------- When a site connection was initially brought up, a small timing window in bandwidth calculations could result in a divide by zero error and server crash. If there is no modem profile for a port, mark the port as being correctly initialized so network connections work correctly. When using the "SOURCE" command to execute a file containing LRS commands, the bang character ("!") was being treated as a comment char regardless of the position in the command line. Unfortunately, some modem initialization strings use the "!" character. Now recognize bang as the start of a comment if it is one of the first couple of characters on a command line. On the LRS16/32F, broadcast packets were not being logged correctly in the receive packet counters. IP -- The "SAVE IP" command did not save all appropriate values. (For example things like the domain name.) When processing ICMP redirection packets, a route was added for every redirected network, regardless if a route for that network was already in the routing table. Under certain conditions, if a IP network host sent the LRS a TCP RST packet while the LRS side of the connection was in a timewait state, the network connection would not be cleaned up properly. If this happened repeatedly, the LRS would run out of memory and crash. (RedHat 4.1 Linux generated this condition fairly regularly.) Remote Networking ----------------- When attempting to perform a callback operation using Microsoft CBCP increase the retry counter to be a bit more generous in how long we will wait before timing out the connection. Known Problems ============== The following problems are known in V1.3/5: 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 ------ The LRS does not gather post-call statistics. 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.