--------------------------- LANtronix --------------------------- ETS/EPS --------------------------- Terminal and Printer Server --------------------------- Software Release Notes --------------------------- Version V3.5/5 May 27, 1998 Copyright 1998, Lantronix Release notes are also available 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 Terminal/Printer Server software release. Release Summary =============== V3.5/5 ------ V3.5/5 provides traditional terminal and print server functionality, including the TCP/IP, Novell, Appletalk, Lan Manager and LAT protocols on the ETS4P4, ETS8/16 and ETS8P/16P platforms. Appletalk, Lan Manager and Novell support is limited to print serving. V3.5/5 provides print server functionality, including the TCP/IP, Novell, Appletalk, Lan Manager and LAT protocols on the EPS2P2, EPS4P1, EPS1/2, LPS and MPS platforms. Note that these units are print servers. They will not allow outgoing connections to hosts. V3.5/5 provides terminal server functionality, including TCP/IP, Novell and LAT protocols on the MSS1, MSS1-T2 and the MSS485 platforms. Note: V3.5/5 software is not supported on the EPS4/12. V3.5/3 is the last software release for these units. Note: V3.5/5 software will only download on LPS1 units with a Boot ROM revision of V2.4 or greater. (The ECO revision must be "CA3" or greater.) New Features ============ The following is a list of new features in V3.5/5. DHCP Support ------------ DHCP support has been added to both boot and run-time code. To enable DHCP support in the run-time code, use the command "DEFINE SERVER DHCP ENABLED." (on the MSS1 and MSS485, use the command "CHANGE DHCP ENABLED") Note that run-time code can use DHCP to acquire an IP address even if the boot roms do not support DHCP. The following rules will be used: Boot Code DHCP Support No Boot Code DHCP Support --------------------------------------------------------------------- | DHCP enabled by default in new | DHCP disabled by default when | | runtime and operational code. | upgrading existing units. | | | | | Both boot and operational code | Boot code will attempt to get | | will attempt to get an IP | an IP address using BOOTP and | | address via DHCP. If boot code | RARP and if successful will | | succeeds, the address returned | save the address in NVR. | | will be saved in NVR and the | | | runtime DHCP code will attempt | In the runtime code, if the | | to acquire the same IP address. | DHCP request succeeds, the | | | address returned by the DHCP | Runtime | In the runtime code, if DHCP is | server will be used, but will | DHCP | enabled and there is no DHCP | not be saved to NVR. | Support | response after 15 seconds, the | | | IP address saved in NVR will be | If the DHCP request fails, the | | used. (saved IP address is due | IP address saved in NVR will | | to BOOTP or RARP response) | be used. | | | | | Flash can be reloaded using the | Flash can be reloaded using | | IP address acquired by DHCP, | the address acquired by BOOTP, | | BOOTP, RARP or IP address | RARP or IP address entered by | | entered by hand at the boot | hand at the boot prompt. | | prompt. | | --------------------------------------------------------------------| | Not a typical case, but boot | Existing units. | No | will be able to acquire an IP | | Runtime | address via DHCP, BOOTP, RARP | | DHCP | or IP address entered by hand at | | Support | the boot prompt. | | -------------------------------------------------------------------- If the "define server ipaddress xxx.xxx.xxx.xxx" command is used to save a specific IP address in NVR, a warning message will be issued and DHCP will be disabled. Enabling DHCP will remove the IP address saved in NVR. To acquire an IP address in boot mode using DHCP, the following ROM revisions are required: EPS1 ----- V2.3 EPS2 ----- V2.3 EPS2P2 --- V1.3 EPS4P1 --- V1.3 ETS4P4 --- V1.3 ETS8P ---- V1.3 ETS16P --- V1.3 LPS1 ----- V2.5 MPS1 ----- V2.5 MSS1 ----- V2.0 MSS485 --- V2.0 The boot code uses the same set of rules to find an IP address as the run-time code. (If IP address found using DHCP, use it, otherwise use BOOTP, RARP or address saved in NVR.) Once an IP address has been found, normal boot code functionality appplies. Boot Gateway Support -------------------- The ability to TFTP boot through a gateway has been added. Note that this functionality requires new boot code according to the following table: EPS1 ----- V2.3 EPS2 ----- V2.3 EPS2P2 --- V1.3 EPS4P1 --- V1.3 ETS4P4 --- V1.3 ETS8P ---- V1.3 ETS16P --- V1.3 LPS1 ----- V2.5 MPS1 ----- V2.5 MSS1 ----- V2.0 MSS485 --- V2.0 To define the boot gateway, use the command "DEFINE SERVER BOOTGATEWAY x.y.z.t" where x.y.z.t is the IP address of the gateway on the local segment. (Use "CHANGE BOOTGATEWAY x.y.z.t" for the MSS1 and MSS485.) This local gateway is the IP address that the server will send TFTP packets to when downloading. Note that this is NOT the loadhost - the packets will be addressed to the loadhost, but will be physically sent to the gateway host. This lets units boot without enabling proxy arp on the router. Test Port DTR ------------- The "TEST PORT n DTR [DELAY delaytime]" command has been added. Executing this commmand will drop the DTR signal on the specified port for for "delay" milliseconds. The delay value can range from 50 to 3000 milliseconds, defaults to 1 second and is accurate to within about 15 milliseconds. On the MSS1 and MSS485, use the command "TEST DTR [DELAY delaytime] Dedicated Local Connections --------------------------- The "DEFINE PORT n DEDICATED LOCAL portname" has been added. This command allows a dedicated connection to another port on the same terminal server. Use the command "DEFINE PORT n DEDICATED NONE" to clear the dedicated session. (Note that this command does not apply to print servers or MSS serial servers.) Multihost Connections --------------------- The ability to have "multihost" connections has been added to the MSS1 and the MSS485. The following commands have been added: CHANGE DEDICATED HOSTLIST will put the serial port into the mode where it will pay attention to the hostlist instead of any other dedicated setting. Use CHANGE DEDICATED NONE to return it to normal. HOSTLIST {ADD | DELETE} option is used to manipulate the hostlist. HOSTLIST DELETE {ALL | number} is used to remove one or all of the hosts in the SH HOSTLIST listing. HOSTLIST ADD {UDP | LAT | SPX | TCP | RLOGIN} hostname is used to add a host to the list. Note that the TCP keyword actually causes a Telnet connection; if you want raw TCP, attach a :T to the end of the hostname, like in the usual Dedicated syntax. (Unfortunate, but unavoidable.) Note that for UDP, you don't need to attach the :U to the end - using the UDP keyword will take care of that. For TCP/UDP, the hostname can be a text name (if a nameserver is defined) or a numeric IP address. SHOW HOSTLIST will show the list of remote hosts. If one or more of the sessions are UDP, and the remote host sends back an ICMP Unavailable message, it will cause a 10-second backoff on that session. Other sessions will keep working, but that UDP connection won't be retried for 10 seconds. The time wait for Telnet and Rlogin is 120 seconds; for LAT it is 30 seconds. The timeouts were chosen based on how painful a failed connect attempt is, performance-wise. A TCP connect that has to timeout takes ~30 seconds, which isn't good. LAT and UDP succeed or fail much quicker. All TCP and UDP connects will be prefaced with a Ping packet, as a quick way to see if the host is even alive. If the ping succeeds, the real connection will be attempted. If it fails, the real reconnect won't be tried at all. Any network session that flow controls the mss will have its data discarded so the other sessions can continue to pass data. If the serial device flow controls the MSS, the network session data will not be consumed until the serial port is cleared (or the port is logged out and everything returns to idle. The server's Serial Delay parameter is obeyed, when reading data from the serial port for sending to the network connections. The Autostart parameter is also obeyed. If Autostart has not been enabled a must be received by the serial port to get the connection(s) established. Resolved Problems ================= Miscellaneous ------------- The minimum buffer (window) size has been increased to 512 bytes. Lower values caused some hosts to not communicate correctly with the servers. Several of the startup printouts to the console port did not obey the "silent-boot" option. In the help system, pressing a carriage return to return to the previous help level could actually return back several levels. When using an ETS8P or ETS16P to do virtual protocol translation, the translation data path could duplicate data. This would cause data to be printed twice. On the ETS8/16P more user sessions than were specified by the port and server session limit parameters were allowed. If data arrived continuosly into the ETS8P and ETS16P serial ports, when the data was displayed on a network session, it could arrive in a "bursty" manner. The second parallel port on the EPS2 would truncate or corrupt print jobs if a "SHOW PORT ALL COUNTERS" command was entered. On the MSS1, if an "INITIALIZE DELAY n" command was issued and then the server was modified using a "CHANGE" command before the reboot occured, the initialize time delay would be saved into the server NVR information. On the MSS1, support NONE as well as ALL for the "CHANGE LAT GROUP" command. Lan Manager/DLC --------------- Lan Manager printing using NetBios was not working correctly. Printing large documents using DLC could result in data corruption. LAT --- When making a LAT connection and specifying a destination node, the node specification was ignored. Netware ------- Logging into a Novell NDS tree failed when the file server and print server negotiated a packet size of 1024 or fewer bytes. If a primary file server redirected the print server to a secondary file server, generate an error message if the second file server is not reachable. If a Novell file server requested zero copies of a print job, print exactly one copy of the job rather than lots of copies. TCP/IP ------ Under certain "buffer full" conditions, telnet IAC processing that would result in an expanded data stream (i.e. to processing) would not correctly transmit the additional character. If forming a Telnet connection to a device resulted in an IAC war, stop IAC negotiation after six exchanges of IAC pairs. When generating the banner page for LPD print jobs, the time field could be incorrectly formatted without an actual time value. When forming a TCP/IP connection using a MSS1 or MSS485, the ARP cache entry is verified if there are no current connections to the requested host. This will allow "failover" to backup hosts if a primary host goes down but it's ARP entry is still cached. When printing using LPD, data loss could occur if characters were returned by the printer when the print server was output flow controlled. (when the printer has told us to stop transmitting data) This condition can also occur if the printer is really slow in accepting data. Connection environment strings (i.e. :3001T) were not being parsed correctly which could result in failed DNS lookups. Known Problems ============== The following problems are known in V3.5/5. Printing directly from a Windows for Workgroups machine is not supported because of a problem in WFW. If the print server is flow controlled by the printer and in turn flow controls the WFW host machine, the WFW host will abort the print job. This means that if the print job is larger than the print server's internal buffer (maximum 4Kbytes) the print job will fail. The only workaround for this problem is to spool the jobs from the WFW machine to a Windows NT machine and print to the print server from there. LPD printing from Solaris machines is problematic due to the way Sun has implemented the Solaris spooling system. This problem has been reported to Sun. Their suggested workaround is "Do not print using LPD from Solaris machines to network based print servers. Instead use the vendor supplied printer interface programs." For Lantronix print servers this is the RTEL software. Please see the RTEL man pages for more information about configuration and use.