Installation guide

CUSTOMER RELEASE NOTES
10/17/07 P/N: 9038177-17 Subject to Change Without Notice Page: 14 of 21
F0615-O
KNOWN RESTRICTIONS AND LIMITATIONS:
Firmware Release 6.0.4.4:
Upgrading to RBT switch Version 6.0 and Certificate Issue: Customers may experience issues with Certificates
or Private keys installed on RBT switches after upgrading to newer 5.0 and 6.0 releases. Error messages
relating to this issue may include the following:
- HTTPD Aug 14 16:32:13.648823 ERROR HTTPD: SSL connection failure (bad cert?);
- Admin client 145.36.245.51 EAP Aug 14 16:32:14.110502 ERROR EAP_STORE_ERR: No EAP key pair.
Cannot do PEAP
Affected services may include SSH, Web-portal, PEAP-offload, WebView, and RASM administrative access
and/or Domain Security.
You can prevent this issue by generating new private keys and any related Certificates prior to upgrading to a
newer version of the RBT switch. Third party Certificates should be exempt from this issue provided a new
private key was explicitly generated before the CSR request generation. If you are unsure, whether a new
private key was generated before the initial CSR, the best course of action may be to request a replacement
certificate from your provider using a new private key.
Customers that encounter this issue can follow the same process to restore normal operation. Details on
generating private keys, self-signed Certificates and certificate requests can be found in the Enterasys
RoamAbout Mobility System Software Configuration Guide.
There is an open issue where clients connected to the network using an Intel 2100 wireless network card may
be disconnected from the network during large file transfers.
The 6.0.4.4 release only supports 16 ACL rules (ACEs) per ACL, total of inbound and outbound, to be mapped
to the user if the AP has Direct Path Forwarding (Local Switching) enabled. There can be more than one ACL,
with 16 ACEs, applied to multiple users on the AP. If an ACL with 17 or more rules is mapped to the user with
Local Switching enabled, the users in the network will not connect or authenticate to that wireless network.
Enterasys Networks recommends creating separate ACL profiles to be used for those users who are
authenticated into the Local Switching VLAN profile.
There is an open issue where the Access Point strips off the VLAN header from a tagged packet before the
Tunnel encapsulation from the AP to the RBT switch. This occurs with Direct Path Forwarding (Local Switching)
enabled on the Access Point.
There is an open endian issue where an ICMP ACL rule (ACE), with either the source or destination IP address
fields and masks configured, will not get applied to an authenticated user with Direct Path Forwarding (Local
Switching) enabled. The workaround is to set the rule to any IP address.
The set ap <apnum> boot-configuration switch switch-ip cannot be set at the same time as set ap <apnum>
boot-configuration switch name <switch-name> dns <ip addr>. The commands overwrite each other when
used.
The Web-portal ACL does not work on IPv6 traffic. IPv6 clients are not able to authenticate using Web Portal
unless the clients also run IPv4. This issue affects Web-Portal authentication only. The other authentication
types (802.1X, MAC, and Last Resort) can be used with IPv6 clients.
The LED radio designation for the RBT-4102-thin is not the same as the RBT-4102 in a standalone mode. In
the thin mode, the LED labeled ―1‖ should be associated with the B/G band, and LED ―2‖ is associated with the
―A‖ radio band.
In the RBT switch User Guides and Configuration manuals, the syntax for the ‗set dap boot-ip‘, ‗set dap boot-
switch‘, and ‗set dap boot-vlan‘ commands is incorrect. The actual commands in the RBT switch firmware
version 5.0 are ‗set dap boot-configuration ip‘, ‗set dap boot-configuration switch‘, and ‗set dap boot-
configuration vlan‘. In 6.0.x.x, these commands are ‗set ap boot-configuration ip‘, ‗set ap boot-configuration
switch‘, and ‗set ap boot-configuration vlan‘.
At the time of this release, there is an open LED issue with the RBT-82x0 switches, where both ports could
show an incorrect connection status after a device reboot when there is no cable attached. This does not affect
the performance for either port in any way.