--------------------------- LANtronix --------------------------- Universal Device Server --------------------------- Software Revision Notes --------------------------- Version V3.6/8 August 07, 2001 Copyright 2001, Lantronix Release notes are also available via the Lantronix web site (www.lantronix.com) and via anonymous FTP from ftp.lantronix.com. Contact Lantronix or your reseller for more information. This document describes the Lantronix Universal Device Server V3.6/8 software release. Release Summary =============== These release notes will document new features added and problems corrected since the V3.6/4 software release. Supported Platforms ------------------- V3.6/8 provides terminal server functionality, including TCP/IP, Novell and LAT protocols on the MSS100 platform. V3.6/8 provides terminal server functionality, including the TCP/IP protocol on the MSSLiteX, MSS-VIA and MSS4 platforms. New Features ============ The following is a list of new features in V3.6/8. MSS-VIA Second Serial Port Enabled ----------------------------------- The console serial port on the MSS-VIA has been enabled as configurable functional serial port. The only caveat is that current hardware ECO levels do not support DSR/DTR signaling on this port. In order to allow this change, the command syntax for the MSS-VIA has changed slightly. All port commands now require the port number to be specified. For example the new syntax for changing the port access to remote is: CHANGE PORT ACCESS REMOTE where port_num is either 1 or 2. In addition, the following commands now require the "SERVER" keyword: CHANGE SERVER BOOTGATEWAY CHANGE SERVER BOOTP CHANGE SERVER BUFFERING CHANGE SERVER DHCP CHANGE SERVER DOMAIN CHANGE SERVER GATEWAY CHANGE SERVER INACTIVE TIMER CHANGE SERVER INCOMING CHANGE SERVER IPADDRESS CHANGE SERVER LOADHOST CHANGE SERVER LOGINPASS CHANGE SERVER NAME CHANGE SERVER NAMESERVER CHANGE SERVER PASSWORD LIMIT CHANGE SERVER PRIVPASS CHANGE SERVER RARP CHANGE SERVER RETRANSMIT LIMIT CHANGE SERVER RLOGIN CHANGE SERVER SECONDARY GATEWAY CHANGE SERVER SECONDARY LOADHOST CHANGE SERVER SECONDARY NAMESERVER CHANGE SERVER SESSION LIMIT CHANGE SERVER SILENTBOOT CHANGE SERVER SNMPSETCOMM CHANGE SERVER SOFTWARE CHANGE SERVER STARTUP RETRY CHANGE SERVER STARTUP FILE CHANGE SERVER SUBNET MASK CHANGE SERVER TCPKEEPALIVE CHANGE SERVER TELNETDEST CHANGE SERVER TIMESERVER CHANGE SERVER WINS When upgrading from previous versions of firmware to V3.6/8, all NVR settings will be retained. Downgrading from V3.6/8 to a previous firmware version will force the unit settings back to factory default. Enhanced Serial Support ----------------------- Enhanced serial handling support has been added to the MSS product line. These new features allow much more control of how a server will bundle received serial chararacters into network packets. Several new commands have been added to configure this functionality. Note that for all these commands the the syntax "CHANGE" is used for the MSS1, MSS485, MSSLite and MSS100 and "CHANGE PORT " is used for the MSS-VIA and the MSS4. To start a connection, the autostart functionality has been enhanced to allow sessions to be initiated by a sequence of 1 or 2 characters. Either of the characters can be a wildcard, signified by the ANY keyword. (mss100) CHANGE AUTOSTART CHAR ["x" | ANY | NONE] ["x" | ANY] (mss4) CHANGE PORT AUTOSTART CHAR ["x" | ANY | NONE] ["x" | ANY] In addition, the characters that start the connection can either be passed to the host as the first bytes of data or can be discarded. (mss100) CHANGE AUTOSTART SAVE [1 | 2 | NONE] (mss4) CHANGE PORT AUTOSTART SAVE [1 | 2 | NONE] where "x" is any valid character. Non-printable characters can be specified as "\xx" where xx is the hex value of the character wanted. Note that data can only be saved if the port is set to dedicated mode. In all other modes autostart chars are discarded. Once the connection has been started, several different triggers can be used to force the server to transmit all accumulated serial data to the host. These triggers are individually described below. The first trigger will allow serial data to be accumulated until a "timeout" condition has been detected. This timeout may be either a period of time since the last character was received or the time since the current "character burst" was started. The command syntax is: (mss100) CHANGE DATASEND TIMEOUT [IDLE | FRAME] [n | NONE] (mss4) CHANGE PORT DATASEND TIMEOUT [IDLE | FRAME] [n | NONE] Several simple examples should help illustrate how this trigger works. For example the command "CHANGE DATASEND TIMEOUT IDLE 50" would look like: xx x (data) x xx x x xxx xx xx |----------------------| 50 milliseconds transmit packet Using the command like "CHANGE PORT 2 DATASEND TIMEOUT FRAME 150" would result in the following behaviour. x x x xxx xx (data) x x xx xxxxxxxx xx xxxx xx xxxx |----------------------------------------------| 150 milliseconds transmit packet The second trigger can be used to specify a one or two byte character sequence that will cause the accumulated serial data to be transmitted. The command syntax is: (mss100) CHANGE DATASEND CHAR [x1 | ANY | NONE] [x2 | ANY] (mss4) CHANGE PORT DATASEND CHAR [x1 | ANY | NONE] [x2 | ANY] Again, examples may help explain how these commands work. The command "CHANGE DATASEND CHAR Z" would transmit any accumulated data as soon as the "Z" character is detected in the data stream. x x x xxx xx x (data) x x xx x x xxxxxxx x Z |----------------------------------------------| transmit packet The command "CHANGE DATASEND CHAR Z &" would send any accumulated data as soon as the characters "Z&" are detected in the data stream. x x x xxx xx x (data) x x xx x Z xxxxx x Z & |----------------------------------------------| transmit packet The DATASEND match characters can either be sent to the host as part of the data or can be discarded. Use the command: (mss100) CHANGE DATASEND SAVE [1 | 2 | NONE] (mss4) CHANGE PORT DATASEND SAVE [1 | 2 | NONE] There are several important caveats in this functionality: The timer resolution on these products is approximately 20 milliseconds. Any timeout values lower than 30 msec will be approximated as well as possible. Packets created by the serial handling rules will be queued to the ethernet driver as a single operation, but there is no guarantee that they will be received at the network host in a single network read. If the serial input buffer is filled, the accumulated data will be queued to the ethernet driver regardless of the serial handling rules. The serial input buffer size is 2048 bytes. MSS-VIA PCcard Support ---------------------- MSS-VIA support has been added for the following wireless Ethernet cards: 3Com 3CRWE737A Agere ORiNOCO Breezecom PRO.11 Cisco Aironet PC4800, 340 series and 350 series Compaq WL-110 Dell TrueMobile Intel Pro Wireless Farallon SkyLINE 11Mb PN473, SkyLINE 2Mb Linksys Instant Wireless Lucent WaveLAN/IEEE turbo SMC 2632W Symbol Spectrum 24-HR (LA4111/LA4121} When using these cards there are several configuration options that may be available on the Access point. They are listed below in order of preference: If the Access Point allows the choice between Standard RFC1042 Encapsulation and 802.1h, select Standard RFC1042 Encapsulation. If the Access Point allows a choice between Encapsulation and Translation, select Translation. If the Access Point only allows choices between 802.1h/RFC1042 or Straight Encapsulation, choose 802.1h/RFC1042. If the Access Point only allows choices between Straight Encapsulation or 802.1h, select 802.1h. Wireless Equivalent Privacy --------------------------- Support for Wireless Equivalent Privacy (WEP) has been added to the MSS-VIA. This is currently only supported on Cisco Aironet and the Lucent WaveLAN/ORiNOCO wireless ethernet cards. The following commands have been added. CHANGE 80211 WEP ENABLED Turn WEP on. The MSS will now only connect to an AP (in infrastructure mode) or communicate with other ad-hoc peers (in ad-hoc mode) that have been programmed with the same WEP key as the MSS. All wireless network traffic the MSS sends will be encrypted with its WEP key, and received wireless network traffic, if encrypted, will be decrypted with its WEP key. CHANGE 80211 WEP DISABLED Turn WEP off. The MSS will ignore its WEP key, and connect to any AP (in infrastructure mode) or communicate with any other ad-hoc peer (in ad-hoc mode) that sends and receives unencrypted traffic. All wireless network traffic the MSS sends will not be encrypted, and the MSS will only be able to receive unencrypted network traffic. CHANGE 80211 WEP RECEIVE ALL Allow reception of unencrypted traffic while WEP is enabled. The MSS will accept unencrypted wireless network frames it receives, as well as frames encrypted with its WEP key. CHANGE 80211 WEP RECEIVE ENCRYPTED Do not allow reception of unencrypted traffic while WEP is enabled. The MSS will discard and ignore unencrypted wireless network frames it receives, accepting only frames encrypted with its WEP key. Note: WEP on the Cisco Aironet card is currently supported only in "RECEIVE ALL" mode. "RECEIVE ALL" is the factory default, so as long as this setting is not changed, it will not be an issue. CHANGE 80211 WEP KEY {key data} Set the WEP key. The MSS allows both 40-bit and 128-bit keys, and will determine which key length is being set purely by the length of the key data. Key data must be formatted as "xx-xx-xx-xx-...." where x's are hexadecimal digits (0 through 9 and A through F). Each pair of hex digits defines a byte of key data, and each byte is separated from the next by a dash. For a 40-bit key, 5 bytes of key data must be given. For a 128-bit key, 13 bytes of key data must be given. CHANGE 80211 WEP INDEX {index} The 802.11 spec states that up to four WEP keys may be in use at any given time, and assigns each an index: 1, 2, 3, or 4. The index is an integral part of the key: for two keys to match, both their key data and their indexes must be identical. The MSS-VIA actually can only use one key at a time, but it can assign any of the four indexes to it. This command selects the index that should be used with the WEP key. The "SHOW 80211" command has been updated to display WEP status. The WEP field will show "Disabled", "Enabled, Receive all frames" or "Enabled, Receive only encrypted" In addition WEP Key information (length and key index) will be displayed. The key data itself will not be displayed. Example WEP setup command sequence: CHANGE 80211 WEP ENABLED CHANGE 80211 WEP KEY 26-e4-97-db-1f CHANGE 80211 WEP INDEX 1 CHANGE 80211 RESET Miscellaneous Wireless Controls ------------------------------- New functionality has been added to support RTS and Fragmentation thresholds, power levels and antenna diversity. Note that power level and antenna diversity commands are currently only available on the Cisco Aironet Wireless cards. The following commands are used to configure the new functionality. SHOW 80211 [POWER | ANTENNA] Displays the power and antenna diversity options for the 802.11 card currently installed. CHANGE 80211 RTS {number} Changes the RTS Threshold value to {number}, which must be between 0 and 3000. The default value is 3000. CHANGE 80211 FRAGMENTATION {number} Changes the fragmentation threshold to {number}, which must be between 256 and 2346. The default value is 2346. CHANGE 80211 POWER [DEFAULT | {number}] This command controls the cards transmit power settings. The card may be configured to it's default power value or a specific milliWatt power setting can be configured. Note that the numeric power setting specified must exactly match a value that the card supports. CHANGE 80211 ANTENNA [RX | TX] [DEFAULT | {list}] This command controls the antennas used. Note that different sets of antennas can be used for transmit and receive operations. Antennas are numbered consecutively starting with antenna number 1. If a card has three antennas, and they all could be used to receive, the command CHANGE 80211 ANTENNA RX 1,2,3 would enable all three of them. Note that this command will fail if {list} is empty, malformed, or calls out any antenna numbers that do not exist or cannot be used as specified. Flash and MicroDrive Support ---------------------------- ATA flash card and IBM Micro Drive support has been added to MSS-VIA. Supported flash cards include the SanDisk PCcard SDP series and the Centennial ATA Flash series. Note that like all PCcard support on the VIA, cards cannot be inserted and removed without removing power from the VIA. To use these cards, they must be formatted with the MSS-VIA filesystem using the command "DISK FORMAT /pccard1" from the VIA local prompt. Files on the drive can then be referenced with as "/pccard1//. Note that if power is removed from the unit while writing data, (i.e. the power cord is removed) data can be corrupted. 802.11 Error Codes ------------------ If a Direct-Sequence 802.11 card is being used, the "SHOW 80211" screen has a line that reads "Errors:" followed by two numbers, each eight digits long, separated by a comma. This is a 64-bit wide bitfield of error bits, each one indicating whether or not the given error has occurred at least once. The bitfield is zeroed each time the user issues either a "ZERO" command or a "CHANGE 80211 RESET" command at the Local prompt. High order (first) error bitfield 80000000 An authentication or association sequence timed out. An expected reply from the AP was not received within the required time window. 40000000 Internal error. 20000000 Internal error. 10000000 Internal error. 08000000 Fragment reassembly timed out. Failed to receive all the fragments of a fragmented 802.11 packet before the reassembly window expired. Dropped some correctly received fragments. 04000000 Received an 802.11 packet with invalid subtype code. 02000000 Received an 802.11 packet with invalid type code. 01000000 Received an 802.11 packet with invalid version code. 00800000 Dropped a correctly received 802.11 packet due to lack of a sufficiently sized buffer to hold it. May happen under heavy network load if applications are not processing network data fast enough. 00400000 Internal error. 00200000 Internal error. 00100000 Failed to transmit an 802.11 management packet. 00080000 Failed to transmit a data packet. 00040000 Internal error. 00020000 Lost contact with the AP. Unit will attempt to reestablish contact by itself. 00010000 Unit was deauthenticated or disassociated by the AP for attempting to pass data packets before being fully associated. (Indicates confusion of either the unit or the AP.) 00008000 Unit was disassociated by the AP for inactivity. 00004000 Unit was deauthenticated or disassociated by the AP because the AP is going offline or being reconfigured to serve a different network. 00002000 Unit was deauthenticated by the AP because its previous authentication is no longer valid. 00001000 Authentication or association with the AP failed, or the unit was deauthenticated or disassociated by the AP for an unknown reason. 00000800 Association with the AP failed because the unit does not support all of the data rates marked as basic in the AP. 00000400 Association with the AP failed, or the unit was disassociated by the AP because the AP is full, and cannot handle any more stations associating with it. 00000200 Authentication with the AP timed out. The AP did not receive an expected reply from the unit within the required time window. 00000100 Authentication with the AP failed because the WEP key the unit is using is not the same as the key the AP is using. 00000080 Authentication with the AP failed because either the unit or the AP sent an incorrect authentication packet. Some APs will erroneously return this error code when the problem is actually "authentication type not allowed." 00000040 Authentication with the AP failed because the AP does not allow the authentication type requested by the unit. 00000020 Authentication or association with the AP failed for administrative reasons. 00000010 Reassociation with another AP serving the same ESS as the previous one failed because the association could not be confirmed by the previous AP. 00000008 Assoication with the AP failed because the AP does not support all 802.11 options requested by the unit. 00000004 Authentication or association with the AP failed, or the unit was deauthenticated or disassociated by the AP for a reason explicitly given as "unspecified". 00000002 Could not find any beacons matching the network parameters the unit is configured with. Most likely there is no AP or ad-hoc network within range that satisfies the unit's ESSID, NETWORK-TYPE, and CHANNEL parameters. 00000001 Internal error. Low order (second) error bitfield 80000000 Unassigned. 40000000 Unassigned. 20000000 Unassigned. 10000000 Unassigned. 08000000 Unassigned. 04000000 Unassigned. 02000000 Unassigned. 01000000 Unassigned. 00800000 Unassigned. 00400000 Unassigned. 00200000 Unassigned. 00100000 Unassigned. 00080000 Internal error. 00040000 A data packet that could not be sent immediately and was queued for later transmission timed out in the retransmit queue and was dropped. 00020000 Internal error. May occur on some cards in conjunction with other described error codes. 00010000 The 802.11 card in use is not compatible with the regulatory region to which the unit has been programmed. 00008000 Internal error. 00004000 Internal error. May occur on some cards in conjunction with authentication or association failures, or other configuration mismatches. 00002000 Received an 802.11 packet that was too large to be handled. 00001000 Internal error. 00000800 Failed to queue a data packet that could not be sent immediately for later transmission. It was dropped. 00000400 Internal error. 00000200 Failed to find, sync to, and associate with an AP or ad-hoc network within a reasonable time. Most likely there is no AP or ad-hoc network within range that satisfies the unit's ESSID, NETWORK-TYPE, and CHANNEL parameters. 00000100 Received an 802.11 data packet that was not encapsulated as per RFC1042 or 802.1h. Unit will still attempt to decapsulate and interpret it. Some AP's cause this error when they send out "magic" packets containing proprietary extensions not defined in the 802.11 specification. 00000080 Received an 802.11 data packet encapsulated in a completely foreign manner or not encapsulated at all. Unit will still attempt to interpret the packet, but proper interpretation is not guaranteed. The packet may be dropped. 00000040 Received an encrypted packet that could not properly be decrypted. Packet was dropped. 00000020 Unspecified error during packet reception. At least one packet was dropped. Absence of this error bit does not imply that all packets have been received correctly. 00000010 A received packet failed CRC check and was dropped. 00000008 Internal error. May occur in conjunction with "no AP or ad-hoc network within range" errors. 00000004 Internal error. 00000002 Internal error. 00000001 Internal error. MSSlite Real-Time Clock ----------------------- Commands for setting the date and time for the real-time clock have been added for MSSLite/X models that support a RTC. Use the commands: RTC SET DATE mm/dd/yyyy RTC SET TIME hh:mm:ss to set the correct date and time and use the command "RTC SHOW" to show the current date and time. Miscellaneous ------------- The ability to disable the web server and ftp interface has been added. Use the commands: CHANGE HTTPSERVER [ENABLED|DISABLED] CHANGE FTPSERVER [ENABLED|DISABLED] The ability to configure WINS support was added to the product web pages. The ability to change 802.11 parameters was added to the MSS-VIA and MSS4 web pages. A IO_OUTAVAIL ioctl has been added to the SDK. This ioctl will return the amount of buffer space available for a write request to a network socket and will allow a SDK programmer to determine if a write would block. Use the syntax: /* find the amount of space available in the TCP output buffers */ rv = ioctl (fd, IO_OUTAVAIL, NULL); printf("space in TCP output buffers: %d\n\r", rv); Encryption support has been removed from the standard product software for all MSS products. Contact Lantronix for information on receiving software with encryption functionality. Netware and LAT protocol support has been removed from the MSS-VIA. Resolved Problems ================= These problems have been corrected since the V3.6/4 software release. Miscellaneous ------------- When streaming data into the MSS-VIA's serial port at 38.4K baud on busy networks, the network could stop responding. If a LOOP request was received in a packet with a null (all zeros) ethernet hardware address the server would respond to the null address. When resetting units back to factory defaults using the external reset button, the bootgateway was not being cleared. When using the redirector to connect to the serial port on a MSS, unnecessary Carrier Detect (CD) state transitions could be sent. If the privileged password and the login password are the same the web pages were not handling privileged logins correctly. When serving HTML files with dynamic content, attempt to force the browser to treat them as expired so they will update correctly. In modem emulation mode, allow the "+" character to start modem emulation and allow and ignore the command "ATXn". In modem emulation mode, accept ATZ0 as well as ATZ. When using SNMP to check serial port control line (DSR/DTR) status a small timing window could allow memory corruption. On MSSLite units, when receiving high speed serial data using XON/XOFF flow control, an XOFF character was not being sent early enough to prevent data overruns and incoming character loss. On the MSS-VIA only allow RS485 to be configured on the main port. EZWebCon would incorrectly identify a MSSliteX as a MSS-VIA. On the MSSLite models with a real-time clock, ensure that SDK calls to get the current time are synced up with NTP/daytime and the RTC. The web page "reboot server" option would not correctly reboot the MSS-VIA. On MSSLITE or MSSLITEX units with a DCE port, drive the CD serial signal as if emulating a modem's behaviour. SDK --- When opening a TCP/IP connection with the SDK, evenly split the input and output buffers. This will allow SDK code to write a full size Ethernet packet to the TCP/IP driver on the MSS as a single atomic write. TCP/IP ------ If an oversized broadcast UDP packet was received in fragments and the fragments could not be re-assembled the server would incorrectly reply with an ICMP packet. If an incoming HTTP request to the internal web server didn't send any data the HTTP server would stop servicing all requests. The UDP session timeout has been capped at 3600 seconds. When a break condition was received on a serial port, a telnet break sequence could be generated on a TCP (raw) connection. In the serial MIB, the serial device types were being incorrectly reported as RS232 rather than RS423. If simultaneous TCP connection attempts come in for the same destination socket, a timing window could allow both attempts to be accepted and then one would be reset.. When caching WINS info on networks with a lot of WINS traffic the IP ARP table could start thrashing. When a SNMP get request for an invalid InSigTable or OutSigTable name was made, the SNMP response did not correctly report "No such name." Known Problems ============== This release has no known problems.