Hp Msm7xx Controllers V5.7.1.1 Release Notes

Transcript

HP MSM7xx Controllers v5.7.1.1 Release Notes HP Part Number: 5998-3704 Published: November 2012 Edition: 3 © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Acknowledgements Windows® is a U.S. registered trademark of Microsoft Corporation. Version: MSM v5.7.1.1 Description These Release Notes provide important release-related information. NOTE: In this document, except when identifying specific models, the generic term “controller” is used in place of MSM7xx Controller product names and the generic term “AP” is used in place of MSM3xx / MSM4xx AP product names. Product models This document applies to these HP products: Model Part MSM710 Access Controller J9328A MSM710 Mobility Controller J9325A MSM720 Access Controller J9693A MSM720 Premium Mobility Controller J9694A MSM720 Access Controller (TAA) J9695A MSM720 Premium Mobility Controller (TAA) J9696A MSM760 Access Controller J9421A MSM760 Premium Mobility Controller J9420A MSM765zl Premium Mobility Controller J9370A Online documentation You can download documentation from the HP Support Website at: www.hp.com/support/manuals. Search by product name or part number. Software Updates and Licensing portal The Software Updates and Licensing portal provides access to the latest software updates to customers with a support contract. An HP Passport is required to access the Software Updates and Licensing portal at www.hp.com/go/hpsoftwareupdatesupport and it is available to customers who have purchased a maintenance and support agreement. Mandatory channel change required prior to software upgrade; discontinue use of channel 132 Applies to these Americas/USA models: MSM410 (J9426A/B), MSM422 (J9358A/B), MSM430 (J9650A), MSM460 (J9590A), MSM466 (J9621A), MSM466-R (J9715A), MSM310 (J9374A/B), MSM310-R (J9380A/B), MSM320 (J9360A/B), MSM320-R (J9365A/B), MSM325 (J9369A/B), MSM335 (J9356A/B). IMPORTANT: PRIOR to upgrading to MSM software version 5.7.1.1, all applicable APs (autonomous or controlled) that are manually configured to use channel 132 must be either re-configured to use a different channel or be re-configured to use auto channel. This is required because channel 132 is no longer available for use. Description 3 NOTE: Due to a problem with AP channel use validation, a banner similar to this may appear at the top of the Home screen: AP CNxxxxxxxx, Radio 1 channel configuration has been set to autochannel because the previously configured channel Auto is not supported by this version of software. The same message is added to the system log. These messages can be safely ignored. Software configuration change may be required prior to upgrade If the MSM7xx controller is configured with the NAT feature enabled (default setting) and with the Extend VSC egress subnet to VSC ingress subnet feature enabled (disabled by default), the v5.7.1.1 software will disable the NAT feature. These two features are incompatible, and the combination although not validated prior to 5.7.1.0 is now enforced. It is recommended that you review your existing settings and disable one of these features before upgrading to V5.7.1.1. Updating software Update the controller software as described in the “Software updates” section of the MSM7xx Controllers Configuration Guide. Once the controller is updated, it automatically updates all of its controlled devices to the same software version. Downgrading software If you upgrade from version 5.7.0.x (or any other previous version) to version 5.7.1.x, and then you wish to return to the version that you had been running prior to upgrading, the configuration that you used originally with that version will still be available. If you have made configuration changes while using version 5.7.1.x, those changes will not be present when you downgrade to the previous version. If you factory reset your device after upgrading to version 5.7.1.x, your previous configurations will be lost, and when you downgrade to any previous version you will be in a factory reset state. MSM management tool now requires web browser with SSLv3 support NOTE: Starting with MSM software version 5.7.0.3, a web browser that supports SSLv3 is mandatory for running the MSM web-based management tool. SSLv3 is supported by Microsoft Internet Explorer 7 and 8 but must be enabled. Microsoft Internet Explorer 9 only uses SSLv3. Mozilla Firefox also supports SSLv3 but support may need to be enabled or you may need to update to a more recent version. GMS (Guest Management Software) MSM7xx Controllers purchased on April 15, 2010 or later, are entitled to GMS. MSM7xx Controllers with an active software support contract are also entitled to GMS. HP GMS simplifies centralized guest-account creation from any Microsoft Windows-based computer. It provides centralized, real-time management of visitor accounts and sessions with a configurable visitor session duration per account. The intuitive user interface is designed for receptionists and clerical staff with minimal training. Working with HP MSM7xx Controllers, secure login prevents unauthorized account creation, and the reporting feature records all account management activity for audits. A digital certificate secures all communications between GMS and the MSM7xx Controller. For details and download instructions, consult the Guest Management Software (GMS) v5.7.1.x Release Notes. Search for “Guest Management Software” at www.hp.com/support/manuals. NOTE: GMS 5.7.1.0 works with MSM software versions 5.7.1.0 and 5.7.1.1. See also “GMS support for teaming” (page 8). 4 Software configuration change may be required prior to upgrade RF Manager software and MSM software version compatibility RF Manager versions 5.9.x and 6.0.x work with MSM software version 5.5.x and higher. However, to use the WLAN Integration feature in RF Manager 6.0.x, the RF Manager and MSM software versions must be matched as follows: MSM7xx software version Compatible RF Manager version(s) 5.7.1.0 and 5.7.1.1 6.0.177 or above 5.7.0.2/5.7.0.3/5.7.0.4 6.0.162 or above 5.5.3.x 6.0.157 or above 5.5.1.x/5.5.2.x 6.0.154 or above 5.5.0.x 5.9.203, 6.0.147 or above Sensor devices version Sensor-only devices (MSM415) AP/Sensor combo devices (MSM320*, MSM325, MSM335) Upgraded automatically by RF Manager Upgraded automatically by MSM7xx Controller *MSM320 APs that have been upgraded to MSM325 RF sensor via HP MSM320 RF Sensor License J9384A. NOTE: If with RF Manager 6.0.x you choose to use mismatched software versions, you should first turn off the WLAN Integration in RF Manager. NOTE: Upgrading an MSM7xx Controller to v5.7.1.1 will also automatically upgrade any MSM325 and MSM335 Sensors it manages to MSM software v5.7.1.1 and sensor code v6.0.177. NOTE: The MSM415 Sensor has no MSM software dependency. It is managed and upgraded directly by RF Manager. Clear web browser cache before launching management tool In the management tool the Automated Workflow pages use updated JavaScript files. If your web browser cache contains old versions of these files you may see JavaScript errors. If this occurs, clear your web browser cache and re-launch the management tool. Configuring Teaming on the MSM720 For important information on how to configure Teaming on the MSM720, consult the Controller teaming chapter in the MSM7xx Controllers Configuration Guide. Note also that these sections in the MSM7xx Controllers Configuration Guide supersede MSM720 teaming-related information in the management tool online help. Teaming changes To simplify teaming configuration on the MSM720, a new option called Dedicate this port for teaming has been added to the Controller >> Management > Teaming page. Also, the terminology used to identify settings on this page has been changed to more clearly identify the settings and how they are used. (These terminology changes apply to all controllers that support teaming.) • The Connectivity box has been renamed to Control channel. The settings in this box define how team members will establish a control channel with each other to exchange management and control information. • The Communicate using option has been renamed to Establish control channel on. • The Team IP address setting has been renamed to Team management IP address. RF Manager software and MSM software version compatibility 5 Previous release — MSM760/MSM765 This release — MSM760/MSM765 (blue boxes indicate changed sections) Previous release — MSM720 6 Teaming changes This release — MSM720 (blue boxes indicate changed sections) About the new option: Dedicate this port for teaming When enabled, this option reserves the selected port for teaming. This means that the port cannot be assigned for any other purpose on the Controller >> Network > VLANs page. It also means that any VLAN currently assigned to the port is automatically removed. For example, if you reserve port 1 for teaming: Port 1 will be unavailable on the Network > VLANs > Add/Edit VLAN mapping page. Teaming changes 7 Also, note that the VLAN ID assigned to the team control channel (199, in the example above), is not visible on the Network > VLANs page. GMS support for teaming GMS 5.7.0 is not compatible with MSM controllers running software version 5.7.0.x. GMS 5.7.1.0 supports teaming in MSM software 5.7.1.0 and 5.7.1.1 with the following limitations: 8 • Only the team manager controller is supported. GMS interacts only with the team manager controller and not team member controllers. • Subscription plans not supported. User sessions are not synchronized across all members in a team. Therefore, subscription plans are not supported on a controller team. User accounts cannot have Validity set to Subscription Plan. Custom Validity is the only choice for Validity. • Automatic account removal only supported for Invalidity. Due to a lack of synchronization between team members and the team manager, automatic account removal due to Inactivity is not supported on a controller team. Automatic account removal due to Invalidity is supported on a controller team. • Maximum number of concurrent sessions not supported. Since this option is per controller, it is not supported in a team. This option is fixed at Unlimited for controller teams. Teaming changes Configuring the service controller in GMS (when teaming is used): • Do NOT configure a controller in GMS when the team manager controller is not available and a team member is temporarily taking its place. • GMS interacts only with the team manager controller, you cannot add a team member as the controller. • Any attempt to add a team member as a service controller in GMS will be rejected, with the following message displayed: “An error occurred while uploading the CA to the Service Controller. Please check if the Services Controller is a member of a team. If teamed, please add the Service Controller using the team IP or team manager IP.” • It is best to use the team IP address for the controller configuration. • If you specify the team manager controller IP address, GMS detects that it is the team manager controller and automatically adds the controller using the team IP address. This confirmation message is displayed: “The Service Controller you are trying to add is the team manager. GMS will add this Service Controller using the team IP address instead of the Service Controller IP address.” This is normal. • On the Service Controller tab, the Edit Service Controller button cannot be used to edit the controller information for teamed controllers (parameters such as Team IP, HTTP port number, and SOAP port number). Attempts to do this cause this message to be displayed: “Editing Service Controller details is not supported. If the details are altered, please delete and add the Service Controller using the Add device wizard.” As the message indicates, delete and then add the controller back with the wizard, specifying the changed values. • On the Service Controller tab, the two items IS_TEAMED and MANAGER_STATE should be ignored because they are not accurately updated. Adding/editing user accounts in GMS when the team manager is unavailable: • Like when teamed controllers are not used and the controller becomes unavailable, if the team manager controller becomes unavailable, users can still be added and edited in GMS but the controller (team manager) is not updated until it comes back online. • In this case when adding/editing user accounts, the following prompt is displayed: “The selected team is in standby mode. GMS will add the account once the team manager is active. Do you want to continue?” Select Yes to add/edit the account in GMS only for now, with automatic update of the team manager controller upon its availability. SOAP function limitations for teaming environment The functions discussed in this section may be of interest to developers who make use of SOAP to communicate and configure devices, especially when creating and managing user accounts on a controller. Although not available in MSM software version 5.7.0.x, the following SOAP function calls are re-enabled in MSM software version 5.7.1.0 and 5.7.1.1, some with limitations as follows: • UpdateUserAccountMaxConcurrentSession: The user account limit is per controller instead of being applied globally to the team. • UpdateUserAccountValidity: This function will return an error if subscription plans are selected to set the account validity. • ExecuteUserAccountLogout: The action of logging out a user will only take effect if the user is logged in on the team manager. • UpdateUserAccountRemovalSettings The above limitations ONLY apply to controller teams. Teaming changes 9 Although enabled in MSM software release 5.7.1.0 and 5.7.1.1, the following SOAP functions should not be used on a controller team. If you attempt to use any of these functions when teaming is enabled, an error is returned. • ExecuteBackupUserAccountsPersistentData • ExecuteUserAccountRenewPlan • AddSubscriptionPlan • DeleteSubscriptionPlan • DeleteAllSubscriptionPlans • UpdateSubscriptionPlanName • UpdateSubscriptionPlanOnlineTimeState • UpdateSubscriptionPlanValidityPeriodState • UpdateSubscriptionPlanOnlineTime • UpdateSubscriptionPlanValidityPeriodMethodState • UpdateSubscriptionPlanValidityPeriodFor • UpdateSubscriptionPlanValidityPeriodBetween • UpdateSubscriptionPlanValidityPeriodFrom • UpdateSubscriptionPlanValidityPeriodUntil • UpdateSubscriptionPlanBooleanAttribute • UpdateSubscriptionPlanIntAttribute • UpdateSubscriptionPlanBandwidthLevelAttribute Note on SOAP function UpdateUserAccountRemovalSettings The Removal due to invalidity option of this function works in a teaming environment. However, the Removal due to inactivity option should be avoided when teaming because it could cause the controllers to wrongly remove active accounts. Wireless feature changes (for 802.11n radios) NOTE: These changes only apply to APs with 802.11n-capable radios (MSM410, MSM422 (radio 1), MSM430, MSM460, MSM466, MSM466-R). Older APs (MSM3xx) are not affected. Wireless modes changed and restricted 802.11n access added With this release, MSM430 and MSM46x APs can now have their radios set to support legacy wireless modes 802.11a and 802.11b/g. This release also provides the ability for an 802.11n radio to be configured only to allow 802.11n clients to associate with it. The goal of this feature is to allow administrators to segregate 802.11n traffic to ensure that 802.11n clients do not experience performance degradation when sharing a wireless network with legacy (slower) client stations. This feature is supported on the following APs: MSM410, MSM422, MSM430, MSM460, MSM466, and MSM466-R. In order to support this functionality, the following changes have been made to the Radios configuration page: 10 • Supported wireless modes have been changed (see table on next page for details). • A new parameter, Allow 802.11n clients only, has been added under Advanced wireless settings. Wireless feature changes (for 802.11n radios) Wireless modes supported in this release Mode MSM410 MSM422 MSM430 MSM460 Radio 1 Radio 1 802.11n/a (5 GHz) X X 802.11a (5 GHz) X X 802.11n/b/g (2.4 GHz) X X 802.11b/g (2.4 GHz) X X Mode Radio 1 or 2 when in Monitor mode X X MSM466 and MSM466-R Radio 1 Radio 2 802.11n/a (5 GHz) X X 802.11a (5 GHz) X X (except Monitor) 802.11n/b/g (2.4 GHz) X (Monitor only) X 802.11b/g (2.4 GHz) Radio 2 X (except Monitor) Wireless feature changes (for 802.11n radios) 11 Wireless modes no longer supported in this release The following wireless modes are no longer supported in this release: • 802.11b • 802.11b/g • 802.11n (5 GHz) • 802.11n (2.4 GHz) • 802.11n/g When upgrading, radios that are currently configured to use these modes are automatically converted to the new modes as described in the next section. Wireless mode conversion when upgrading When upgrading to this release, existing wireless settings are converted to the new wireless settings as follows: Configuration before upgrade Configuration after upgrade Wireless mode Wireless mode Allow 802.11n clients only 802.11b 802.11b/g (2.4 GHz) (not available) 802.11b/g 802.11b/g (2.4 GHz) (not available) 802.11g 802.11b/g (2.4 GHz) (not available) 802.11a 802.11a (5 GHz) (not available) 802.11n (5 GHz) 802.11n/a (5 GHz) Enabled 802.11n/a 802.11n/a (5 GHz) Disabled 802.11n (2.4 GHz) 802.11n/b/g (2.4 GHz) Enabled 802.11n/g 802.11n/b/g (2.4 GHz) Disabled 802.11n/b/g 802.11n/b/g (2.4 GHz) Disabled Local mesh wireless modes changes Wireless mode changes also affect configuration of local mesh profiles for controlled APs when selecting Controlled APs >> Provisioning > Connectivity. AP New wireless modes Radio 1 MSM410 802.11n/a Radio 2 n/a 802.11a (5 GHz) 802.11n/b/g (2.4 GHz) 802.11b/g (2.4 GHz) MSM422 12 802.11n/a (5 GHz) 802.11a (5 GHz) 802.11a (5 GHz) 802.11b (2.4 GHz) Wireless feature changes (for 802.11n radios) MSM430, MSM460 MSM466, MSM466-R 802.11n/b/g (2.4 GHz) 802.11g (2.4 GHz) 802.11b/g (2.4 GHz) 802.11b/g (2.4 GHz) 802.11n/a (5 GHz) 802.11n/b/g (2.4 GHz) 802.11a (5 GHz) 802.11b/g (2.4 GHz) 802.11n/a (5 GHz) 802.11n/a (5 GHz) 802.11a (5 GHz) 802.11a (5 GHz) 802.11n/b/g (2.4 GHz) 802.11b/g (2.4 GHz) NOTE: • When upgrading to this release, existing wireless settings for local mesh are also converted to the new wireless settings as described in the table on the previous page. • The wireless modes available for local mesh configuration are automatically determined by the wireless operating mode that is set. • Local mesh is only supported between two APs when the radios on each AP are configured with identical wireless modes. For example, if AP 1 is set to 802.11a, then AP 2 must also be set to 802.11a and not 802.11n/a. Multicast rates for 802.11n radios In order to allow 802.11n clients to take advantage of High Throughput data rates for multicast traffic, the list of allowed multicast rates now takes into account the Allow 802.11n clients only setting of the radio. Supported multicast rates in this release are as follows: MSM410, MSM422, and MSM430 Wireless mode Allow 802.11n clients only Enabled Disabled 802.11n/a (5 GHz) 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0, and MCS 0 to MCS 15. Default: 24 Mbps 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0. Default: 24 Mbps 802.11a (5 GHz) n/a 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0 Default: 24 Mbps 802.11 n/b/g (2.4 GHz) 1.0, 2.0, 5.5, 11.0, 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0, and MCS 0 to MCS 15. Default: 11 Mbps 1.0, 2.0, 5.5, 11.0, 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0. Default: 11 Mbps 802.11 b/g (2.4 GHz) n/a 1.0, 2.0, 5.5, 11.0, 6.0, 9.0, 12.0, 8.0, 24.0, 36.0, 48.0, 54.0 Default: 11 Mbps Wireless feature changes (for 802.11n radios) 13 MSM460, MSM466, and MSM466-R Wireless mode Allow 802.11n clients only Enabled Disabled 802.11n/a (5 GHz) 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0, and MCS 0 to MCS 23. Default: 24 Mbps 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0. Default: 24 Mbps 802.11a (5 GHz) n/a 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0. Default: 24 Mbps 802.11 n/b/g (2.4 GHz) 1.0, 2.0, 5.5, 11.0, 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0, and MCS 0 to MCS 23. Default: 11 Mbps 1.0, 2.0, 5.5, 11.0, 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0, and MCS 0 to MCS 23. Default: 11 Mbps 802.11 b/g (2.4 GHz) n/a 1.0, 2.0, 5.5, 11.0, 6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0. Default: 11 Mbps Wireless support changed for Israel The 5 GHz band cannot be used outdoors in Israel. Therefore on the MSM466-R, when the country code is set to Israel: • Radio 1 will be disabled and all options will be greyed out. The setting for Operating mode will be changed to Monitor. • Radio 2 will still be configurable, but Wireless mode will only contain options for 2.4 GHz operation. NOTE: The 5 GHz band can still be used indoors in Israel, therefore operation of the MSM466 is not affected by this change. 14 Wireless feature changes (for 802.11n radios) IPSec recommendation changed In the previous release, the MSM7xx Controllers Configuration Guide provided the following recommendations in the topic Securing wireless client sessions with VPNs in the chapter Working with VPNs. To make it clearer on how to configure this type of setup, the second note above now reads as follows: Wireless clients require VPN software (L2TP, PPTP, or IPSec) that is configured to work with the VPN configuration on the controller. If the VSC is access controlled, enabling VPN-based authentication is recommended. See Configuring VPN-based authentication on a VSC in the chapter User authentication, accounts, and addressing. CLI command changes Changes have been made to the CLI to support the new wireless modes and the new Allow 802.11n clients only parameter. dot11 Syntax: dot11 The syntax of this command has not changed. However the wireless modes supported by the option are now as follows: • a: selects 802.11a in the 5 GHz frequency band. • an: selects 802.11n + 802.11a in the 5 GHz frequency band. • bg: selects 802.11b + 802.11g in the 2.4 GHz frequency band. • bgn: selects 802.11n + 802.11g + 802.11b in the 2.4 GHz frequency band. IPSec recommendation changed 15 To maintain backward compatibility with the previous version of this command, the dot11 command will automatically map old settings for the mode option to the new settings as follows: If mode is set to … It is mapped to… 802.11b 802.11bg 802.11g 802.11bg 802.11n-5GHz 802.11an 802.11n-2.4GHz 802.11bgn 802.11gn 802.11bgn The dot11 command does not allow setting the operating frequency of radio 2 to 5 GHz when the country code of an AP is set to Israel. dot11 allowedclients This new command in the Wireless Interface context allow a radio to be configured to only support 802.11n client stations. Syntax: dot11 allowedclients Where is: • n only: configures the radio to only allow 802.11n clients to associate. • all: configures the radio to allow all clients to associate. provisioning local mesh type Syntax: provisioning local mesh type The syntax of this command has not changed, however the wireless modes supported by the option are now as follows: • 802.11a • 802.11n+a • 802.11b+g • 802.11n+b+g To maintain backward compatibility with the previous version of this command, this command will automatically map old settings for the type option to the new settings as follows: If type is set to … It is mapped to… 802.11b 802.11b+g 802.11g 802.11b+g Teaming fixes The following teaming-related issues are fixed in this release: 16 • (Applies to MSM720, MSM760, MSM765zl with Teaming.) Management tool page Controller >> Management > Teaming has some formatting problems. • (Applies to MSM720, MSM760, and MSM765zl with Teaming that are upgraded to software version 5.7.0.2.) When a team of controllers is configured to use MCS rates, the team member controllers fail to synchronize with the team manager controller after the software upgrade. • (Applies to MSM720 with Teaming.) The message "Firmware unavailable" may appear for the team member controller and the team member controller fails to synchronize with the team manager controller. Teaming fixes • SOAP function ControlledNetworkGetWirelessAssociatedClientStatus is not available in a teaming environment. • If the country code is changed on a team of controllers, the team-member controllers fail to synchronize to the team manager and the following error is logged: The short Guard Interval is not allowed with the 20 MHz channel width. • Creating a mobility domain between a team of controllers (that use a VLAN for teaming communication) and another controller is not working properly if the team is set as the primary mobility controller. In this case the IP address of the slave controller is not properly set on the mobility domain. • With a controller team, there may be an excessive amount of UDP traffic (related to team management) causing slow wireless client response. • With a controller team, if the sysinfo file for the team manager controller is downloaded, the team manager controller reboots. Other fixes The following other issues are fixed in this release: • Controlled APs manually configured in previous releases with radio power levels that are out of regulatory bounds in version 5.7.1.0, will not synchronize with the controller after its upgrade to version 5.7.1.0. • If you configure DHCP relay per VSC with Forward to egress VLAN selected and had previously configured DHCP relay per VSC with valid subnet information, then network access may not work on that VSC even if you obtain an IP address, DNS, and gateway. This can also affect the operation of the HTML-based Web login interface, if you have performed this configuration. • If a controlled AP has a Country setting that is different from the group in which it is in, and channel 12 or 13 is selected, the web GUI will display 0dBm as the maximum output power. • After upgrading to v5.7.1.0, the radio power for channels 12 and 13 gets set to minimum values, and cannot be changed. • Controller responds to gratuitous ARP request for an IP address it does not own. • A VSC configured for Mobility Traffic Manager (MTM) is not allowing wireless clients to authenticate with a secondary RADIUS server when the primary RADIUS server fails. • When the primary RADIUS server is down, the controller does not send RADIUS requests to a configured secondary RADIUS server. • SOAP function GetWirelessAssociatedClientStatus() fails to retrieve results for controlled APs, reporting FAULT: SOAP-ENV:Client Internal error in the system log. • (Applies to MSM720, MSM760, MSM765zl.) When a mobility domain grows and includes many (more than 10) controllers (either teamed or standalone), Mobility Traffic Manager (MTM) clients roaming from one controller to another may randomly drop their connection or experience delays in recovering wireless service. • (Applies to MSM410.) An MSM410 cannot join an AP group configured to use the radio configured for 802.11b/g only. • (Applies to MSM765zl.) Management tool page Controller >> Tools > Status > LLDP is not displayed properly, requiring the management tool to be re-launched. • When a controller is handling live streaming traffic from many wireless users, the controller management tool may become temporarily unreachable. • (Applies to MSM710.) The controller reboots when the number of adopted access points reaches 10. Other fixes 17 18 • When a wireless client disassociate command is issued by the management tool, the CLI, or SOAP, encryption keys stored on the controller are not cleared. • When SNMPv3 is configured to use SHA/AES encryption, the device does not respond to SNMP queries. • (Applies to 802.X authentication with Active Directory.) When a wireless client roams, the controller assigns an incorrect VLAN to the client. • In some cases, a PPTP client connection fails and this error is logged: PPP Internal error (1). • When a VSC is configured to use special character "%" in the preshared key (PSK), the controller truncates the preshared key after the "%" character. • When payment services are configured and used, a duplicate payments page remains open for two hours instead of 30 seconds. • (Applies to MSM765zl.) The SNMP MIB OID "operstatus" always returns a status of "down" for interfaces ETH0 and ETH1. • (Applies when VSC DHCP pool is configured on the same subnet as one of the logical or physical interfaces.) After a controller reboot, the IP address and the default route for the Internet interface is lost. • (Applies to MSM760.) The Internet port cannot be manually set to 10 Mbps full duplex. Auto settings work as expected. • DNS cache is not working properly, causing unnecessary requests to reach the DNS server. • An AP with a VSC configured with radio mode 802.11n b/g and having 30 or more clients connected at the same time, may experience slow client association and the appearance of many tx_nobuff error messages in the system log. • (Applies to MSM710.) The controller reboots due to a memory leak caused when multiple wireless clients are performing a file transfer. A message similar to the following appears in the system log: warning kernel Softdog, warning kernel cpu: 100%, warning kernel, cause 1 • When 802.1X user statistics are being generated, unexpected messages similar to the following may appear in the system log: eapolserver: assert: ieee802dot1x_stats.c IEEE802dot1xServer_PostStats 95 • APs truncate 802.1X usernames to 96 characters. • (Applies to MSM720.) On page Network > Address Allocation, the Max Connections parameter under VPN address pool has an incorrect default value of 55. When attempting to save changes to this page, an error message will appear indicating that Max Connections must have a value in the range of 1 to 15. • The web-based management tool becomes unreachable and causes controller reboot. • Wireless clients fail to get a DHCP lease after a VLAN has been dynamically assigned. • When a wireless client connects to an Active Directory controlled VSC, it shuts down the VSC and indicates a termination of the "iprulesmgr" process. • (Applies to MSM720.) In the HP MSM MIBs, a query to sysObjectID.0 returns colubrisProducts.56 instead of the correct value colubrisMSM720. • (Applies to MSM430, MSM460, MSM466, MSM466-R.) When multiple VSCs are configured to use WPA+WPA2 and PSK, the AP restarts. • When multiple VSCs are configured to use 802.1X, the eapolserver process consumes excessive CPU resources. • (Applies to MSM760, MSM765zl.) Associating or authenticating a wireless client with a VPN-based login VSC that uses L2TP over IPSec may cause the controller to restart. Other fixes • When the NetBIOS name is left blank the controller fails to authenticate users to an external Active Directory server. • When RADIUS authentication is configured to use both: remote and local RADIUS servers, the requests going to the external RADIUS are missing the NAS-ID resulting in users not being authenticated. • When a VSC is configured for Mobility Traffic Manager (MTM) (non-access-controlled) and MAC-based authentication is set for both Local and Remote RADIUS servers, the Remote RADIUS server will never be queried even if no match if found in the local database. • In cases where there are more than one controller sharing the same egress VLAN for an Access-Controlled VSC, and the DHCP relay and Extend VSC egress subnet to VSC ingress subnet options are enabled, it is possible that the same IP address will be active on more than one controller at the same time, causing more than one controller to answer ARP requests for this IP address, leading to incorrect behavior. • (Applies to Japan (JP) versions of MSM320 with an MSM7xx Controller team.) Upon team failover to a team member, the MSM320 shows as having incompatible settings when attempting to re-synchronize with the team member. • (Applies to MSM720.) The L2TP option for VPN Based Authentication is not supported in this release. • When configuring the maximum number of clients per radio on a VSC, the maximum allowed value is 255 whereas the maximum value for the Access Point group is 999. • (Applies to MSM760, MSM765zl with teaming enabled.) When opening the AP Overview page with more than 300 APs, the management tool may stop working, requiring it to be re-launched. • (Applies to MSM310, MSM320, MSM325, MSM335, MSM422.) Sometimes an Apple Mac Book is unable to forward traffic to the external network even though the wireless signal is shown as Excellent. Furthermore, the AP wireless driver may stop working. Either restart the AP or re-synchronize it after a radio configuration change. • (Applies to MSM430, MSM460, MSM466, MSM466-R.) Dynamic VLAN assignment fails, causing user traffic to be placed onto the default network, preventing users from getting an IP address on the correct subnet. • Controllers configured for remote Active Directory authentication allow successful user authentication but falsely report errors similar to this in the system log: IsValidAccountingRequest: Invalid Accounting Request due to failure to resolve the primary address of the associated RADIUS profile (name='TAP') • When the controller is polled via LLDP for the Port Description value, the interface alias is returned instead of the Port Description. • (Applies to non-access-controlled VSCs with 802.1X (Dynamic VLAN) with external RADIUS authentication, and Allow traffic between all wireless clients configured.) Wireless clients connected to the same VSC are not able to ping each other. • When both Active Directory and local authentication are selected, neither works. • (Applies to MSM760 and MSM765zl Controllers.) The controller is not able to authenticate wired users with a remote RADIUS server. • The SNMP MIB OIDs for CS Transmit and CS Receive statistics are not reporting the correct data. • Static NAT mappings are incorrectly limited to a maximum of 63 via the CLI and 200 via the management tool. • Wireless clients roaming from one AP to another appear as connected to both APs and the connection is dropped. • (Applies to Active Directory in Windows Server 2008.) The computer name cannot be used instead of an actual user name. Other fixes 19 • Active Directory (AD) users of a VSC configured for HTML authentication cannot log in if both Local and Remote (Active Directory) is enabled. • When a controller switches from a primary to a secondary RADIUS server, the RADIUS accounting messages from the controller change the configured source port to use source port 0. • With free access configured and in the rare case of two wireless users attempting to connect at exactly the same time, the users will experience a dropped connection. Known teaming issues The following teaming-related issues are present in this release: • APs controlled by a Team Member controller report the serial number instead of the configured system name. • (Applies to Teaming with MSM720, MSM760, MSM765zl.) When roaming from an AP managed by the team manager to another AP managed by a team member, wireless clients may experience a delay of up to 15 seconds when trying to reach other wireless clients on the same VSC. • When the system time is set manually, if the team manager controller is shut down (power disconnected) when the team manager controller returns, the team manager controller time is set to the last saved time, which may cause team member controllers to fail to re-synchronize with the team manager controller. As a workaround, use an NTP service on the network for automatic system time setting. • When upgrading from 5.4.x or 5.5.x to 5.7.x, depending on the settings already in the configuration file, messages similar to the following may appear in the system log after the upgrade is complete. In this context, such messages can generally be safely ignored. Apr 19 14:32:38 err monitord Upgrade 200 failed: Unable to get IGMP inheritance section inside AP-1: 3 Apr 19 14:32:38 debug monitord Performing upgrade 201 (v13.4 reference:QC55390-QC42402). Required to update current version 10.22 to 13.5. Apr 19 14:32:38 err monitord Upgrade 201 failed: Failed to update provisioning phytype token: 3 Apr 19 14:32:39 err monitord Upgrade process error: Some upgrade scenarios failed. 20 • When a controller team attempts to manage the maximum number of APs as defined in its installed AP licenses, it may trigger one or more team members to restart. For example, assume a team has a total of 100 AP licenses installed. When the team attempts to manage the 100th AP, one or more team members may restart. To avoid this issue, keep the number of installed APs below the maximum number of installed licenses. • (Applies to MSM720, MSM760, MSM765zl.) GMS 5.7.0.x does not support interaction with MSM7xx Controller teams. GMS 5.7.0.x must only be used with standalone MSM7xx Controllers. • (Applies to MSM720, MSM760, MSM765zl with teaming and Mobility Manager.) After a failover to a team member controller has occurred, the Mobility Manager dashboard becomes unable to display correct information for the team. To display the correct information, the teamed controllers must be restarted, ensuring that the new master controller boots first. • (Applies to PCM interacting with APs controlled by an MSM7xx Controller team.) You cannot use PCM to manually disable sampling and statistics for active sFlow agents on MSM APs controlled by a team. As a workaround, use the management tool on the team master, and disable the AP sFlow agent on page Controller >> Tools > sFlow. Known teaming issues • (Applies to MSM720, MSM760, MSM765zl with Teaming.) A controller that has DNS discovery settings defined on the Controlled APs >> Provisioning > Discovery page may be unable to synchronize with a team in the following two scenarios: ◦ If the team members have different DNS discovery settings configured, the controller will not be able to synchronize. ◦ If the team initially has no DNS discovery settings configured, the controller will be able to synchronize, however, if the DNS settings on the team are then changed, the controller will no longer be able to synchronize. • (Applies to MSM720, MSM760, MSM765zl.) Teaming redundancy is not implemented for the sFlow feature. Therefore, upon master controller failover to a team member, sFlow will be shown as disabled on the team member that is temporarily filling the master role. As a workaround, manually configure the team, enabling the temporary master as the real master controller, and enabling sFlow on this master controller. • On a controller team, if a VSC has the DHCP relay agent feature enabled with the Subnet selection option, the relay does not work properly when the team manager recovers after a shutdown. Other known issues These other issues are present in this release: • Local Mesh APs may fail to synchronize with the controller after a software upgrade. When this occurs, reset the affected APs by pressing the reset button or power cycling them. • (Applies when there is more than one MSM7xx Controller on the same subnet (connected by Access network/LAN port).) With "Extend VSC egress subnet..." configured, the controller replies to ARP broadcast frames from other controllers, causing access controlled clients to be disconnected. To avoid this, when "Extend VSC egress subnet..." is configured, do not connect the Access network/LAN port interfaces of the controllers on the same subnet. • When HTTP/HTTPS support and Zero configuration are both enabled on a VSC, 802.1X RADIUS authenticated clients are redirected to the welcome page but they should not be. • In a local mesh link with no security configured, clients are shown as Authorized/802.1X. • When using Subnet-based mobility, wireless clients my be unable to get an IP address. Note that Subnet-based mobility is already documented as deprecated with advice given to use MTM (Mobility Traffic Manager) instead. • Access-controlled wireless clients lose network connectivity if they cache an IP address from a previous subnet. Try releasing and then renewing the IP address. • When a controlled AP configuration is updated after a MAC address is added or removed from the allowed stations list, other wireless clients associated with the same VSC lose connectivity until they are reauthenticated. As a workaround, reauthenticate the wireless clients. • Wireless clients connected to an AP adopted on the controller Internet interface are not able to ping and communicate with other wireless clients on the same VSC that are connected to an AP adopted on the controller LAN interface. As a workaround, use IP routes or external routing mechanisms. • The Save button on management tool page Controller > VPN > L2TP server does not apply the configuration settings. As a workaround, use alternative configuration interfaces (CLI, SOAP, SNMP). • When a second VSC is added, wireless clients on the first VSC are not able to ping each other (although wireless clients can ping their default gateway and retain network connectivity). • (Applies to MSM422 acting as a Slave in a Local Mesh configuration.) If the AP was directly provisioned before being adopted by a controller, the AP will not synchronize with the controller. Other known issues 21 This may be caused by a specific configuration where the Alt-Master only has the Local mesh provisioning profile enabled rather than having an additional Local mesh profile for the slave(s). • When sFlow is enabled, it cannot be disabled unless there is at least one controlled AP. • The show config CLI command generates an unable to read configuration error in the management tool syslog. • If the DHCP server/DHCP relay agent option is configured in a VSC (cannot be the default VSC) and then Access control is cleared in the VSC, the DHCP server/DHCP relay agent option is not disabled. This causes the routing table to still be populated even though the option is no longer used. Instead, disable the DHCP server/DHCP relay agent in the VSC before clearing the Access control option. • When adding an IPSec policy, the NAT option under Security Policy can not be enabled if the Accept any peer option is enabled under Peer Information. The only way to enable NAT in this context is to clear the Accept any peer option and to enable Tunnel under General > Mode. • (Applies to MSM410, MSM430, MSM460, MSM466, MSM466–R.) Due to a software design change, 802.11 LEAP authentication (some devices use terminology such as “Network EAP”) is no longer supported. • (Applies to MSM710, MSM720, MSM760.) Communications problems may occur if the controller and any connected Ethernet switch both have manual Duplex and Speed settings, even when the settings match. As a workaround, set at least the MSM7xx Controller to auto for both Duplex and Speed. • (Applies to HTML authentication on an access-controlled VSC with Active Directory as the authentication server.) Authenticated users are not displayed on the Controller > Controlled APs >> Overview > Wireless clients page. • (Applies to MSM410, MSM430, MSM460, MSM466, MSM466-R.) If a radio Channel setting of Automatic is enabled and all APs (affected by this issue) happen to boot up at the same time, for example after a power outage, then they are likely to end up on the same channel. This will happen mostly with autonomous APs. APs managed by an MSM7xx Controller are less likely to experience this. As a workaround, APs can be restarted/re-synchronized at specific intervals or fixed channels can be selected. • (Applies to MSM720.) IPSec is not supported in this release. • When a less specific static route is configured after a more specific static route has been configured, the controller forwards packets incorrectly. • When a Mobility Traffic Manager (MTM) user is assigned to network mapped to a VLAN range, the selected VLAN ID within the range may change when users roam. To avoid this, do not use VLAN ranges. • (Applies to MSM720 with Mobility Traffic Manager (MTM).) Egressing traffic on the Internet network and Access network is not supported. Egressing traffic onto a user-created network profile is supported. (Applies to MSM710, MSM760, and MSM765 with Mobility Traffic Manager (MTM).) Egressing traffic on a network profile mapped to the Internet port is not supported. Egressing traffic onto a network profile mapped to the LAN port or mapped to any VLAN interface is supported. 22 • When setting the SNMP Syslog trap level below Warning, no traps will be generated. • When an access-list is created to enable a proxy server using HTTPS, wireless clients may be unable to gain access to the secure site. As a workaround, restart the controller to activate the access list. • The management tools allows the Metric value for gateways to be set to 0. Ensure that you set a gateway metric to a value other than 0. Other known issues • (Applies to MSM410.) You need to add an extra VLAN to pass traffic over a local mesh link in controlled mode. In earlier MSM410 software versions you could discover and pass data over the same VLAN. You now cannot send data over the discovery VLAN. You must add another VLAN for data traffic. • (Applies to MSM720.) There is no Spanning Tree Protocol (STP) loop protection so avoid interconnecting two or more ports that are on the same VLAN. • VPN-based IPSec clients are unable to connect to MSM7xx Controllers, resulting in display of messages similar to this: XAUTH wrong UserId or Password. • The maximum quantity of CA certificates and Client certificates that can be installed on the system is 50 certificates each. In some cases when adding more than 45 certificates of either type, the certificate names may disappear and an access error may be generated when selecting a different management tool menu. As a workaround, restart the controller. • On the MSM720 there is no SNMP MIB support for Port Trunking. • (Applies to USA and Canada.) System Time is not being set back one hour when DST ends at 2:00 a.m. on the first Sunday in November. • If you configure the local DHCP server on a VSC to operate on the subnet 192.168.1.x/ 24, the route for users on this subnet will be deleted if the controller is restarted. The subnet 192.168.1.x/24 should not be used by a DHCP server on a VSC. • If you want to assign the Internet port as the Egress network in a VSC binding, it must have a VLAN. Mobility Traffic Manager currently cannot send user traffic onto the Internet port untagged. Other known issues 23