Copyright (c) 1991 - 2005 Digi International. All Rights Reserved. EtherLite(R) 160 US Patent No. 6,047,319 RealPort Firmware Release Notes 2/22/2005 v1.6 Release Notes: p/n 93000403_E Firmware Image: p/n 80007013_E Table of Contents ----------------- Product Specific Notes Firmware Update Instructions for Windows NT/2000/XP Firmware Update Instructions for UNIX What is the RealPort Firmware? Virtual Ports Optimization for Throughput or Latency Revision History Product Specific Notes ---------------------- None. Firmware Update Instructions for Windows NT/2000/XP --------------------------------------------------- To update EtherLite firmware from a Windows NT/2000/XP host, download the utility package DgIpServ.zip from our web or FTP site, and refer to the included instructions. Firmware Update Instructions for UNIX ------------------------------------- Check your device driver release notes and user documentation for any additional update instructions specific to the operating system you are using. Some driver packages offer alternate methods for updating the EtherLite firmware. The EtherLite Units use TFTP in conjunction with BOOTP to update their firmware. In order to update your units, enable the TFTP Server on the same host that provides BOOTP service. Disable this service as soon as you are done updating the firmware, as TFTP does no user authentication and allows file transfers. As a result, it can be a security risk. The BOOTP service is typically launched at boot time by the system, and is configured according to an entry in /etc/inetd.conf, even though current versions of bootp server software no longer uses inetd. The bootp server line in that file may look like this: bootps dgram udp wait root /etc/bootpd bootpd TFTP service is typically enabled by "inetd". An entry in the "/etc/inetd.conf" file specifies how to start the service. Most systems will already have an entry for TFTP, but it will be commented out, which disables it for security reasons mentioned above. It may look similar or identical to this: tftp dgram udp wait root /usr/etc/in.tftpd in.tftpd -s /tftpboot There should also be entries in your "/etc/services" file, specifying BOOTP server service on UDP port 67 and the TFTP service on UDP port 69. The entries in your /etc/services file should appear as shown below. If your system differs from the example given below, refer to the man pages on your system for "tftpd" and "inetd" for details on how to enable TFTP service. bootps 67/udp # bootp server bootpc 68/udp # bootp client tftp 69/udp # tftp server To get the EtherLite Unit to download the new firmware, you need to specify the bootfile option in the BOOTP entry for the unit. To do so, edit the "/etc/bootptab" file. Add the field ":bf=filename" to the entry for the EtherLite Unit, where "filename" is the full path to the new firmware. Note: Most TFTP implementations perform a "chroot" (change root directory) when started. If your TFTP server does this, place the firmware image in its directory tree and specify the path relative to TFTP's root directory. For example, most TFTP servers have a "root" directory of /tftpboot on the host, which means that a file whose path to TFTP is /files/bootfile, is actually /tftpboot/files/bootfile to the UNIX system. Your bootptab entry may look like: el16_0:\ sm=255.255.255.0:\ gw=192.9.200.1:\ ht=ethernet:\ ha=00A0E7000004:\ ip=192.9.200.2:\ bf=/bootp/sts/el16.prm: In this case, the full path to the file on the UNIX side would be: /tftpboot/bootp/sts/el16.prm To actually update the EtherLite Unit, power cycle it. Each time it boots, it downloads the bootfile specified by BOOTP. If the bootfile differs from the firmware it is currently running, it will update its Flash EPROM with the new firmware. Once you have updated your EtherLite Unit, it is not necessary to leave the TFTP server enabled. As mentioned earlier it can be a security risk. Unless you are sure that your configuration is secure, disable TFTP service by commenting out its entry in "/etc/inetd.conf". It is ok to leave in the bootfile entry in the "/etc/bootptab". What is the RealPort Firmware? ------------------------------ The EtherLite product line originally used Digi's STS driver (or ELS driver) to communicate with a host system. However, Digi also offers a driver package called RealPorts, which offers similar functionality to the STS driver but has a broader range of operating system support and improved characteristics over wide-area networks. The RealPort firmware allows you to use the EtherLite hardware with a RealPort driver. If you load this firmware into your EtherLite; you will need to use a RealPort driver. It is not possible to use the STS driver with the RealPort Firmware. You can, however, convert an EtherLite back to non-RealPort by loading the appropriate firmware. Virtual Ports ------------- The version 1.4 firmware adds virtual ports to most EtherLite models. With virtual ports it is possible to have more RealPorts than there are physical ports on the EtherLite. Each physical port can have up to two RealPorts. When there are two RealPorts for one physical port, any data sent to the physical port can be read from both RealPorts. Any data written to the two RealPorts is merged and sent out the common physical port. The two associated RealPorts can be open on different hosts; this allows two separate hosts to monitor the same physical port. By default virtual ports are not enabled. Virtual ports can be enabled through the boot console or through the bootp or dhcp protocols. The number of virtual ports enabled can be from 0 to the number of physical ports on the EtherLite. The virtual ports are added sequentially from physical port 0 on up. For example, on an EL-160 with 5 virtual ports enabled, RealPorts /dev/ttyaa00 through /dev/ttyaa15 refer to the 16 physical ports, and virtual RealPorts /dev/ttyaa16 through /dev/ttyaa20 also refer to the first 5 physical ports. Any data written to physical port 3 can be read from /dev/ttyaa03 and /dev/ttyaa19; and any data written to /dev/ttyaa03 and /dev/ttyaa19 is merged and sent out physical port 3. Physical ports 5 and above have only one RealPort, no virtual ports. There are no guarantees about the atomicity of writes; that is, if each of the two RealPorts does a single write at about the same time, the data from those two writes might be intermixed. Generally, however, data from small separate writes will remain separate. There is no difference between the original RealPort and the corresponding virtual RealPort. If one of the two associated RealPorts is not open, the other behaves as a normal single port. Only when both associated RealPorts are open do the virtual port features become active. The two associated RealPorts must stay roughly in sync as they read data. If one of the two stops reading data, the other can only read one buffer full of data further before being flow controlled. In cases where you do not want one port to be able to flow control the other, a virtual port timeout can be set. When set, one port can only flow control the other for this timeout period, then the other can continue reading data. Once the happens the first port, the one not reading data, will lose data. When it begins reading again, it will start from the position of the other port in the data stream. Once both ports are reading, the timeout is reset for the next time one port falls behind the other. By default there is no virtual port timeout set. The two RealPorts that share the same physical port share the same set of low level stty parameters. A change on one RealPort will affect both ports. For example, setting baud rate or flow control or modem signals on one RealPort affects the other. These parameters are associated with the common physical port. Higher level stty parameters that are handled by the RealPort driver can be set independently for each RealPort. There are two new bootp/dhcp vendor specific options for virtual ports: VS_VP_NUM_PORTS = 6 VS_VP_TIMEOUT = 7 Each of these options takes a two byte value, in network byte order, specifying the number of virtual ports and the timeout in deciseconds. The timeout can be from 0 (no timeout) to 600 deciseconds. For example, in hexadecimal, the vendor options 06 02 00 05 07 02 01 F4 set 5 virtual ports and a virtual port timeout of 500 deciseconds. These values can also be set at the boot console with the "vpports" and "vptimeout" commands. The values of these values are displayed by the boot console "show" command and by the rlogin "ver" command. Optimizing for Throughput or Latency ------------------------------------ The version 1.4 firmware adds the ability to optimize the EtherLite for throughput or low latency. By default the EtherLite is optimized for throughput. The optimization setting can be made in the boot console or through a bootp/dhcp vendor specific option. When optimized for throughput the EtherLite polls 50 times per second to send packets of data to the RealPort host. When optimized for low latency, it polls 500 times per second. Optimizing for throughput forces the EtherLite to send fewer but larger packets of data--this is more efficient, but it adds latency. Optimizing for latency forces the EtherLite to send more frequent but smaller packets of data--this reduces latency, but it adds to the network load. It is not recommended that you run EtherLites optimized for low latency over slow WAN links, unless the data rate is very low. To further reduce latency, set the Windows RealPort driver to "Complete writes immediately". There is one new bootp/dhcp vendor specific option for optimization: VS_OPTIMIZE = 8 This option takes a two byte value, in network byte order, 0 to optimize for throughput and 1 to optimize for latency. For example, in hexadecimal, the vendor option 08 02 00 01 optimizes for low latency. Optimization also be set at the boot console with the "optimize" command. The current optimization setting is displayed by the boot console "show" command and by the rlogin "ver" command. Revision History ---------------- 02/22/2005 - v1.6 - Release for the EtherLite RealPort firmware, EL-2, EL-8, EL-16, EL-32, EL-80, EL-160, and EL-162. - Modified the RealPort TCP connection to disconnect after aproximately 2 minutes of failed communication. Previously it took a failed connection to disconnect around 12 minutes with latency turned on and 2 hours with throughput turned on. 04/28/2004 - v1.5 - Release for the EtherLite RealPort firmware, EL-2, EL-8, EL-16, EL-32, EL-80, EL-160, and EL-162. - Redesigned TOUT reporting in the Net/CX protocol so TOUT reports are only sent when something changes, rather than continuously when data is waiting to go out. This reduces unnecessary network traffic. Vantive 13114. - Fixed the EL-32 firmware so that it flushes ports on close and does not miscompute window values. This bug was introduced with virtual ports in the 1.4 release; it only affected the EL-32. Vantive 11298. - RTS toggle was added. Vantive 9534. - Delay before sending out a DHCP/BOOTP request after reboot was increased from 1/4 second to 4 seconds. This fixed DHCP/BOOTP over a crossover cable and over some slow hubs. Vantive 7826. - The EtherLite now gives preference to DgIpServ over other DHCP servers for the first 4 seconds after it sends out a DHCP request. Vantive 7826. - A request to erase an already erased configuration is now ignored. Vantive 7826. - The TCP FIN handling has been improved to prevent a network flood that occurred under certain circumstances. - A waiting open response on a port number > 16 no longer results in protocol corruption on the EL-32. 05/15/2003 - v1.4 - Release for the EtherLite RealPort firmware, EL-2, EL-8, EL-16, EL-32, EL-80, EL-160, and EL-162. - Virtual port support was added to all models except the EL-32. Virtual ports are disabled by default, but can be enabled through the boot console or bootp. - The optimize option was added to all models. Optimize can be set to latency or throughput. When set to latency, the polling frequency is increased from 50 times per second to 500 times per second. Throughput is the default. The optimize option can be set through the boot console or bootp. Vantive 9496. - EL-16 and other models based on the CD1400 UART now clear software flow control when the port is closed and reopened. Vantive 9797. - EL-32 no longer sends a continual stream of module select packets. 08/14/2002 - v1.3 - Release for the EtherLite RealPort firmware, EL-2, EL-2 EIA485, EL-8, EL-16, EL-16h, EL-32, EL-80, EL-160, and EL-162. - Resolved hardware signal response, which affected products: EL-2, EL-2 EIA485, EL-80, EL-160, and EL-162 - Vantive 7995. - This production release captures changes released in the v1.3beta release. 07/9/2002 - v1.3beta - Release for EL-160 and EL-16 beta testing. Also, beta release for the legacy Central Data EL-16h firmware. - Added enhancement to allow 16 concurrent host connections for OEM firmware. - Resolved issue of HUPCL not working under RealPort. HUPCL as supported by the Net C/X specification has been implemented to work as defined - Drop DTR/RTS on close when enabled else maintain current state on port close. - Resolved Net C/X window sequence packet state of the transmit buffer - Vantive 8483. 10/31/2001 - v1.2 - A feature was added to permit the unit to be remotely reset using the elsreset and dgipserv utility programs. - EL-160, EL-162, EL-2 products - Modem signal changes were being reported too slowly. Worst case latency was 320ms + driver poll time. It is now 20ms + driver poll time. 10/19/2001 - v1.1 - Support was added for the EL-8, EL-16, and EL-32 products. 08/15/2001 - v1.0 - Corrected a bug where PARMRK was not being handled when the UART fifo was in a full condition. - The RealPort keep-alive timer needed to be reset when a connection is established with the host. - EL-160 only, some test code had been left in which caused the UART buffers to be larger than necessary. - The RealPort patent number was added to the rlogin display. 07/11/2001 - v0.8 - Release for beta testing. - Changed the default TFTP file to a name unique to the RealPort firmware. For instance, the EL-2 will use the default name of elr2.prm instead of el2.prm. - Modified DHCP requests to include a vendor specific option that contains the product ID. - Modified RealPorts to return a unique hardware and product IDs. - Improved handling of RealPort protocol errors. - Improved handling of Ethernet and TCP/IP errors. 06/18/2001 - v0.6 - Initial release for alpha testing