This document provides installation instructions and release notes for the flash components within the Avocent ESP-2 products. Note that these download images cannot be used on standard, 10/100 or Multi-Interface-8 ESPs.

Components

• esp2miapp.img, version 3.13 (embedded application image)

• esp2miboot.img, version 0.82 (embedded bootstrap image).

Models

The following ESP models are supported:

1. ESP-2 (images: esp2miapp.img and esp2boot.img)
   • ESP-2 MI

Flash Image Preparation On Windows Systems

The following are the steps to prepare the images for installation on Windows systems:

1. Download the archive file from the web-site.
2. Unzip the archive file.
3. If you are using the Equinox TFTP service, copy the flash images (.img files) to the c:\%WINDIR%\system32\drivers directory. This is the root TFTP directory used by the Equinox TFTP service.
4. If you plan to use a TFTP service other than the Equinox provided service, then it will be necessary to manually copy the flash image files to the appropriate TFTP transfer directory.
5. Ensure that the TFTP service is properly installed and enabled.
6. After installation, the temporary directory and its contents may be removed.

Flash Image Preparation On Unix Systems

The following are the steps to prepare the images for installation on Unix systems:

1. Download the archive file from the web-site.
2. Unzip the archive file.
3. Copy the flash images (.img files) to the /etc/eqnx directory.
4. If the TFTP root directory is not “/”, copy the flash images (.img files) to TFTPROOT/etc/eqnx. Note that typically TFTPROOT = /tftpboot.
5. Ensure that the TFTP service is properly installed and enabled. Refer to “Enabling TFTPD on Unix Systems” within this document.
6. After installation, the images may be removed.

Updating ESP-2 Flash

The flash images within the ESP-2 can be updated by:

1. using EquiView Plus (windows systems only).
2. using espcfg utility (unix systems only).
3. using the embedded administration utility within the ESP-2.
4. using the embedded web browser administration utility within the ESP-2. (requires version 2.50 or later of the application image and 0.60 or later of the bootstrap image).
5. socket administration API facility.

Flash Image Update Using Device Manager (Windows 2K and above)

• Download the archive file from the web-site.
• Unzip the archive file.
• If you are using the Equinox TFTP service, copy the flash images (.img files) to the c:\%WINDIR%\system32\drivers directory. This is the root TFTP directory used by the Equinox TFTP service. Note you can use a different subdirectory if you wish. This is directory you will use in step 11 below.
• Open up Device Manager.
• Double click on the Avocent Ethernet Serial Provider.
• Click on the ESP properpty page tab. Make sure this is the correct ESP by looking at the Unit ID which is the same as the MAC Address and the IP Address.
• Click on Update Flash.
• Type in the Community Name (usually “public”) then click Next.
• In the ESP FLASH Update mode page, your will see the Version, Create Date and Create Time. You also see the Status of the Last Flash Update. The Status should be App: Last Application Flash image update successful. And Boot: Last Boot Flash image update successful.

• Click on the Manual FLASH Update.
• Click to Enable both the Bootstrap FLASH Update Parameters and the Application FLASH Update Parameters. Type in the Server IP Address, this is the address of where the image files are located. Type in the full pathname for the boot image and app image. This is the full pathname to where the images are located. Click Next.
• Here you can type in 0 for the Days Hours Minutes and Seconds or just click Next. This means the Flash updates will begin immediately.
• Now click Finish.
• After the images have been transferred you can go back to the ESP FLASH Update and you should see the App: Last Application Flash image update successful and Boot: Last Boot Flash image update successful. You should see the new Version and the Create Date and Create Time change. The Create Date and Time are the Date and Time these images where built.

Flash Image Update Using Equiview Plus (Windows systems only)

1. Install, or upgrade to EquiView Plus 5.2 or later.
2. If necessary, discover the ESP-2 unit.
3. Using EquiView Plus, click on “Module” and “Update FLASH”.
4. Select “Update Bootstrap Image”, provide the IP address of the TFTP server system and the name of the new image file. Then click Update.
5. Repeat step 4 using application image.
6. Reboot the ESP-2.

Updating Flash Images Using espcfg (Unix systems only)

1. Invoke espcfg.
2. select "Update flash".
3. select the appropriate esp.
4. select "Update flash"
5. provide the SNMP Community password (usually "public")
6. select bootstrap or application.
7. provide server IP address if necessary (note that the IP address for the current host will usually be displayed).
8. provide bootstrap/application location. refer to "Location of Flash Components on Unix Systems". As shipped, the names of the images would be:
   • /etc/eqnx/esp2app.img (application image for ESP-2)
   • /etc/eqnx/esp2boot.img (kernel and bootloader for ESP-2)
9. Reboot the ESP as directed.

Updating Flash Images Using Embedded Administration Utility

1. telnet to the IP address of the ESP-2.
2. Enter administration password (or specify one if not already configured).
3. From the Main Menu, select Server Configuration.
4. From the Server Configuration Menu, select Flash Status and Update.
5. Enter ‘y’ to update applicaton image.
6. Enter the IP address of the TFTP server system and the name of the application image file. Refer to “Location of Flash Components on Unix Systems”. Then click “Apply”.
7. Allow 30 seconds for the process to complete.
8. Repeat steps 5,6 and 7 for the bootstrap image.
9. From the Server Configuration Menu, select Reboot.

Updating Flash Images Using Embedded Web Browser Administration Utility

1. Launch a browser to the IP address of the ESP-2.
2. Enter administration password (or specify one if not already configured).
3. From the Main Menu, select the Flash option.
4. Click the Update Bootstrap button.
5. Enter the IP address of the TFTP server system and the name of the bootstrap image file. Refer to “Location of Flash Components on Unix Systems”. Then click “Apply”.
6. Allow 30 seconds for the process to complete.
7. Repeat steps 4,5 and 6 for the application image.
8. Click on the “Reboot” button.

Updating Flash Images Using Socket Administation API

Contact Avocent Technical Support for the Socket Administration API protocol document.

Enabling TFTPD on Unix Systems

For a flash update to succeed, the tftp (trivial file transfer protocol) daemon must be enabled on the server where the downloadable images are located at. This process is documented below. Note that the process varies based on operating system type:

OpenServer, UnixWare and Aix

tftpd is invoked indirectly by the internet services daemon - inetd. The configuration file for inetd must be modified to enable tftpd.

1. edit /etc/inetd.conf
2. uncomment the line for tftpd
3. locate the inetd process: ps -eaf | grep inetd
4. send signal to inetd process: kill -s SIGHUP <inetd process>

Note that the tftpd daemon can run in non-secure or secure mode. Either one may be used, but secure mode is recommended. Secure mode is specified by the “-s” option when tftpd is invoked (i.e. in the file /etc/inetd.conf). In secure mode, the default tftpd root directory is /tftpboot. If this is changed, the download images installed in the /tftpboot directory will need to be moved to the tftpd root directory.

Linux

If not already done, the tftpd package must be installed on your system. On most systems that use RPMs, this is done by the tftp-server RPM. To verify that this package is installed:

rpm -q tftp-server

If not present, then it must be installed from your distribution set.

tftpd is invoked indirectly by the internet services daemon inetd or xinetd (xinetd has replaced the older inetd in most recent distribution sets). The configuration file for inetd or xinetd must be modified to enable tftpd.

Determine if your system is using inetd or xinetd:

• if /etc/inetd.conf is present, then inetd is being used.
• if /etc/xinetd.d directory exists, then xinetd is being used.

Testing TFTPD

It is always a good idea to verify that tftpd is running correctly before doing a flash update. The verification can be done as follows:

1. tftp localhost (or name of local system)
2. get etc/eqnx/espapp.img
3. quit

If tftpd is configured correctly, this should transfer espapp.img to the local directory.

Location of Flash Components on Unix Systems

As installed, the flash components are located in /etc/eqnx and /tftpboot/etc/eqnx. How the location of the flash components are specified varies based on whether or not secure mode tftpd is used:

Secure-Mode

Files are accessed relative to the tftpd root directory (i.e. expected to be /tftpboot). Hence etc/eqnx/esp2app.img actually refers to /tftpboot/etc/eqnx/esp2app.img

The leading "/" may or may not be specified (on Linux systems with tftp-server versions 0.16 and earlier, the leading "/" must not be specified).

Non-Secure Mode

Files are accessed relative to the "/" directory. Hence, /etc/eqnx/esp2app.img actually refers to the file by that name.

Generally, the leading "/" must always be specified.

Flash Update Failures

When a flash update failure occurs, it may not always be obvious what the problem was. The following steps may be used to diagnose the failure:

In addition, check the following:

1. Verify that tftpd is configured properly.
2. Make sure the proper pathname to the image file was specified (see "Location of Flash Images on Unix Systems").
3. Check the tftp logfile if one exists. This log will indicate if a successful tftp connection was made and also if there were any abnormal operations.
4. Verify that the versions of the new images are greater than the currently installed images.
5. TFTP is an un-reliable transport mechanism using UDP. A busy network may result in lost packets which would cause the update to fail.

Changes in release 3.13 (application image)

1. Fix to dhcp client to properly timeout before sending next set of BOOTP/DHCP requests. Previously, no timeout would occur on busy networks which would result in BOOTP/DHCP requests never being sent beyond initial set.
2. Change to dhcp request timeout values to reduce the amount of time to acquire an IP address during the first 60 seconds of operation. The new "rules" regarding requests:
   • For the first 60 seconds, there is a 5 second timeout between request bundles. A request bundle contains 1 BOOTP and 3 DHCP requests (each 1 second apart).
   • After 60 seconds, the timeout increases by 7 seconds between each request bundle. A request bundle contains 1 BOOTP and 2 DHCP requests (each 1 second apart).
   • The maximum is 60 seconds between request bundles. At the maximu, a request bundle contains 1 BOOTP and 1 DHCP requests (each 1 second apart).
3. Change to permanent debug level to that it is saved across reboots. This is used to configure to application logger - which is only accessible via the serial menu administration utility.
4. Change to the TCP-based administration API so that login can be done with a zero-length password.
5. Add support for TFTP push of firmware images in order to do flash updates. The application or bootstrap image may be pushed by a TFTP client. No other TFTP pushes will be accepted while the flash update process is in operation.

Changes in release 3.12b (application image)

1. Fix to properly account for deltas. Firmware was changed to match drivers, such that delta messages do not count against the send window size.
2. Change the manufacturing process for ESP-2 models (ESP-2 MI and ESP-2 OPTO). Different image files and downloaded for the different ESP-2 models.
3. Change when setting the SNMP community name MIB variables midRCommName and midWCommName (enterprises.544.4.1.4 and enterprises.544.4.1.5). Setting either variable will also cause the other to be set.
4. Increased SNMP maximum request size. Equiview Plus sends a single request with multiple OIDs in order to "poll" the ESP. On ESP-16 MI, this request was being refused because the total request size was too large. Equiview Plus would indicate this by displaying its "No Reply" field.
5. Changed the internal loopback (used by Equiview Plus and ESP-View) so that the drain would timeout after completing / terminating the loopback. Without the timeout, the port would remain in use until ESP reset.
6. Changed the internal loopback (used by Equiview Plus and ESP-View) so that the "transmitter" paced better with the "receiver" and also so that the "transmitter" correctly honored x-offs.

Changes in release 3.11 (application image)i / 0.82 (bootstrap image)

1. Fix for problem that might cause control signal state to not be properly reported.
2. Increased number of concurrent servers from 8 to 16.
3. Added Windows SETXON and SETXOFF support.
4. Added control signal extension protocol messages.

Changes in release 3.10 (application image)

1. Added Windows SETXON and SETXOFF support.
2. Added control signal extension protocol messages.
3. Fix to restore gateway route after changing network attributes.

Changes in release 3.08 (application image) / 0.81 (bootstrap image)

1. Enhancements to ESP-View utility to add the ability to run loopback on all serial ports and also obtain the status of all ports.
2. Changed the menus for the CLI administration utility. This affects all of the port configuration and status functions. After selecting a function, the port number must be selected to perform the operation on. In addition, there is an “all ports” option to perform the operation on all serial ports.
3. Changed the menus for the web based administration utility. This affects all of the port configuration and status functions. After selecting a function, the port number must be selected to perform the operation on. In addition, there is an “all ports” option to perform the operation on all serial ports.
4. Modifications to the manufacturing setup and diagnostics procedure.
5. Various other modifications and fixes, mainly in the administration functions.

Changes in release 3.04 (application image) / 0.77 (bootstrap image)

1. Added ESP-View utility for performing datascope, loopback and status operations. This utility is invoked through the web based administration utility.
2. Added ability to configure network interface with regard to speed and duplex. Configured through administration utilities.
3. Added ability to send port break to serial port. Invoked through administration utilities.
4. Modifications to adhere to Avocent branding requirements.
5. Various other modifications and fixes, mainly in the administration functions.

Changes in release 3.03 (application image) / 0.76 (bootstrap image)

1. Added TCP-based administration functionality. This allows an application to perform system and port specific configuration operations using the standard socket client model. More information can be found in the User’s Guide. A protocol description and example source code is available upon request.
2. Fixed problem with update of embedded application and bootstrap images during manufacturing process. The flash update would fail intermittently.
3. Fixed a problem that would cause modification of connection methods using the web-based administration utility on ESP-2 OPTO units to fail.

Changes in release 3.02 (application image) / 0.75 (bootstrap image)

1. Added modem emulation serial connection method. This connection method provides a modem interface to a serial device by accepting and performing AT modem commands. By using this interface, legacy modem applications may be used to talk to ESP serial ports with minimal rewrite. For more information, refer to the User’s Guide.
2. Added configuration capability using downloadable configuration file. This capability may be used to modify any of the system or port configuration items. The configuration download operation may be done at:
   1. First boot following initialization.
   2. Console administration utility.
   3. Web-based administration utility.
   4. Using SNMP.

For more information, refer to the User’s Guide.

3. Fixed problem with 76800 baud using serial port redirection.

Changes in release 3.00 (application image) / 0.73 (bootstrap image)

1. Added support for ESP-2 OPTO and ESP-2 OPTO POE models.
2. Fix to flash update procedure to properly display errors as a result of TFTP failures.
3. Fix to EPC_RESET port redirection request. This was not properly returning an ACK.
4. Added TCP Idle Buffering capability to raw TCP server. When enabled, prior to establishing a TCP connection, the serial port will be monitored for input data. When the connection is established, the buffered data will be sent to the remote client.
5. Added TCP Monitor DCD option to raw TCP server. When enabled, the connection to the remote client will only be established if the DCD signal is asserted. An established connection will be terminated if DCD is lowered.
6. The default baud rate was changed from 9600 to 19200.

Changes in release 2.99 (application image) / 0.72 (bootstrap image)

1. Fix to telnet server so that echoing is never enabled on the local serial port. Previously, a remote telnet client could enable echo which would result in incorrect data being sent from server to client.
2. Fix to raw tcp server, raw tcp client and telnet server so that the control signals on the serial ports are reset when the connection is closed.
3. Fix to datascope utility. Datascope would sometimes not run correctly on port 2.
4. The GET_DTRRTS protocol function did not work correctly. This would generally cause the embedded tcp application process to abort.

Changes in release 2.97 (application image) / 0.72 (bootstrap image)

1. Added additional methods for accessing the serial ports remotely. In addition to the existing serial port redirection functionality, the ports may be accessed using telnet from a remote server, tcp connection initiated from a remote server, or a tcp connection initiated by the ESP-2 MI. More information can be found in the ESP-2 MI Installation Guide.
2. Minor changes to the titles for some of the pages displayed by the internal web based configuration utility.
3. The initial discovery of an ESP-2 MI would fail if the unit did not have an IP address and it is on a classless routing network (CIDR) and the last octet in the broadcast address was not 0xff.
4. The datascope feature now works with the Equiview Plus loopback utility.

Changes in release 2.50 (application image) / 0.60 (bootstrap image)

1. Added an internal web based configuration utility to the ESP-2 MI. This utility is invoked using the IP address of the ESP-2 MI (or 192.1.1.1 for un-initialized units). More information can be found in the ESP-2 MI Installation Guide.

Changes in release 2.48 (application image) / 0.58 (bootstrap image)

1. Support was added for Mark and Space parity.
2. Fixed error message displayed by Equiview Plus when invoking datascope if datascope is already running on the other port. This was caused by the internal SNMP agent setting the wrong value for the MIB variable portDscopeStatus.
3. The internal diagnostic flash test would fail if either the primary or secondary application image was bad or if either the primary or secondary kernel image was bad. The diagnostic should fail only if both the primary and secondary application or kernel images are corrupted.
4. The SNMP agent was returning the wrong value for the MIB variable portDevName if the port was opened by a Windows/NT server and the COM port number was greater than 63. Fixed so that the proper name is returned.
5. The IP address acquired during manufacturing diagnostics was being saved in configuration memory. This incorrectly resulted in a unit having a configured IP address after running manufacturing diagnostics. The IP address is no longer preserved if acquired in diagnostics mode.