ACCESS/ONE FIRMWARE User Manual. (An Addendum to based User Manual) September 29, 2009

Transcription

1 ACCESS/ONE FIRMWARE User Manual (An Addendum to based User Manual) September 29, 2009 Copyright Strix Systems, Inc. All Rights Reserved. 1 ACCESS/ONE FIRMWARE USER MANUAL

2 Table of Contents Access / One Network 1 INTRODUCTION ATTACHING ETHERNET TRAFFIC TO SPECIFIC SSID SIB AGING TIMEOUT RADIUS AUTHENTICATION FORMAT TKIP COUNTER MEASURE ACTIVATION MOBILE DEPLOYMENT RELATED ENHANCEMENTS INFRASTRUCTURE NETWORK / TRAIN-TRACK NETWORK CONNECTION BETWEEN TRAIN AND INFRASTRUCTURE NETWORK IN-TRAIN CARRIAGE NETWORK WIRELESS ACCESS FOR USERS ON TRAIN CUSTOMER PREMISE VLANS CPE MANAGEMENT CPE MANAGEMENT FROM WITHIN VLAN VLAN TAG FOR CPE MANAGEMENT CLOUD PROVISIONING CLOUD SELF PROVISIONING KEY STORAGE OF ENCRYPTED PROVISIONING KEY PROBE CHANGES FOR KEY CHALLENGE NETWORK SERVER INVENTORY UPDATE INVENTORY AGING FAST ACCESS/ONE AUTHENTICATION SCHEME IMPROVED BACKGROUND SCANNING SOFTWARE ACKNOWLEDGEMENT FOR POWERSAVE REQUESTS CONFIGURABLE QUEUE DEPTH ON AP FOR CPE AND BH CONNECTIONS US PUBLIC SAFETY (4.9 GHZ) PS CAPABILITY PER RADIO USPS CONFIGURATION FROM NS CREATION OF PS-ONLY SSIDS WPA2 SECURITY DATA RATE RANGE TELNET / WEB RADIUS AUTHENTICATION RADIUS AUTHENTICATION FOR TELNET / WEB USERS CACHING FOR WEB USERS AUTHENTICATED BY RADIUS NODENAME IN SNMP TRAPS AGING FOR POWER-SAVE CLIENTS CCA SUPPORT MAXIMUM DISTANCE BETWEEN AP AND BH DISCONNECTING WEAKER CLIENTS ACCESS/ONE FIRMWARE USER MANUAL

3 21 USEFUL SYSTEM SANITY MONITOR AND NOTIFICATION FEATURES SYSTEM CPU & MEMORY USAGE NODE TEMPERATURE & PEER RSSI RF UTILIZATION & NUMBER OF USERS ACCESS/ONE FIRMWARE USER MANUAL

4 Table of Figures FIGURE 1: ETHERNET SSID 7 FIGURE 2: TIMEOUT FOR DISSOCIATED CLIENTS 9 FIGURE 3: RADIUS AUTHENTICATION 11 FIGURE 4: TKIP COUNTER MEASURE 13 FIGURE 5: TRACKSIDE MESH NETWORK 15 FIGURE 6: CONNECTION BETWEEN TRAIN & INFRASTRUCTURE NETWORK 16 FIGURE 7: IN-TRAIN CARRIAGE NETWORK 17 FIGURE 8 : WIRELESS ACCESS FOR USERS ON TRAIN 18 FIGURE 9: CUSTOMER PREMISES VLAN 19 FIGURE 10: VLAN IDS 20 FIGURE 11: CPE MANAGEMENT 21 FIGURE 12: VLAN TAG 22 FIGURE 13: CLOUD SELF PROVISIONING KEY 23 FIGURE 14: PROBE CHANGES FOR KEY CHALLENGES 25 FIGURE 15: INVENTORY AGING 26 FIGURE 16: AUTHENTICATION SCHEME 27 FIGURE 17: ACCESS POINT PACKET QUEUES 29 FIGURE 18: USPS CONFIGURATION 30 FIGURE 19: PS-ONLY SSIDS 31 FIGURE 20: WAP2 SECURITY 32 FIGURE 21: DATA RATE 33 FIGURE 22: RADIUS SERVER 35 FIGURE 23: CCA MODE 39 FIGURE 24: MANAGE WEAKER CLIENT TRIGGERS 42 FIGURE 25: ENABLE/DISABLE WEAKER LINKS 42 FIGURE 26: ADD NEW WEAKER CLIENT TRIGGER 43 FIGURE 27: DELETE WEAKER CLIENT TRIGGER 43 FIGURE 28: CPU AND MEMORY USAGE ALARM THRESHOLD 44 FIGURE 29: NODE TEMPERATURE AND PEER RSSI ALARM THRESHOLD 45 FIGURE 30: OTHER THRESHOLD ALARM 46 4 ACCESS/ONE FIRMWARE USER MANUAL

5 1 Introduction This document describes various software features and enhancements implemented in Access/One firmware GA releases after GA release. This document is an addendum document to the previous user manual based on GA release. This document must be read, once the user has gone through the based user manual. Organization The addendum is organized as follows. Sections 2 to 5 describe the features introduced in GA release Sections 6 to 19 describe the features introduced in GA release Sections 20 to 21 describe the features introduced in GA release Some abbreviations used in this document are: OWS - Outdoor Wireless System IWS - Indoor Wireless System EWS - Edge Wireless System MWS - Mobile Wireless System NS - Network Server AP - Access Point (Client Connect) BH - BackHaul (Network Connect) CPE - Customer Premises Equipment 5 ACCESS/ONE FIRMWARE USER MANUAL

6 2 Attaching Ethernet Traffic to specific SSID Ethernet port on the Access/One stack can be attached to a SSID that has a VLAN associated with it. Any client connected over Ethernet port of OWS, can be part of that VLAN. In case this feature is not enabled (default case), all traffic coming and going out of Ethernet port will be untagged, unless the traffic is pretagged or separated by a Layer 2 or Layer 3 device. This feature can be configured only on the stack controller (bottom most module) module of the OWS and not the IWS or HSX. When we have multiple SSID profiles on a radio, one and only one of these profiles can be attached to the Ethernet port. The untagged SSID cannot be used for this purpose. Once a specific SSID is attached to the Ethernet, only traffic from stations using the specified SSID with the same VLAN tag will be sent onto the Ethernet, and the packets will be untagged on the Ethernet. Traffic from other stations will not be sent on the Ethernet. Similarly, untagged packets coming into the Ethernet port will be sent only to those stations that are on the same SSID attached to the Ethernet. Packets coming into a node from an Ethernet port attached to the SSID, will behave just like packets coming into the node from stations associating on that SSID (in terms of VLAN tagging/untagging). This feature can be enabled only when one radio of OWS works as BH (Network Connect) & another radio works as AP (Client Connect). CLI on AP (device level): set etherssid <ssid-name> -- To enable the EtherSSID get ethressid -- Displays on which SSID, etherssid is enabled set etherssid <blank> -- To disable the EtherSSID SNMP Configuration: SNMP mib items on AP: Configuration: strix-config-system.mib: sysethernetssid (Display String) -- device level SNMP mib items on NS: Configuration: strix-config-system.mib: sysethernetssid (Display String) -- cloud level 6 ACCESS/ONE FIRMWARE USER MANUAL

7 Web Configuration: Device-> Configure-> Wi-Fi -> a/g Radio -> Client Connect Figure 1: Ethernet SSID 7 ACCESS/ONE FIRMWARE USER MANUAL

8 3 Sib Aging Timeout When clients are turned off or disassociated, the Strix AP keeps the MAC of the client as authenticated for a very long time before finally letting it go. The Strix interval by default is 5 minutes before removal. This duration configured by entering minutes or seconds before removing disassociated clients. The Strix CPEs and Backhauls will be affected by this configuration. This timeout can be configured per SSID profile on the AP. The clientagingtimeout is used for aging out of the client entries when they are not in PS mode. CLI on AP: (device Level) set cleintagingtimeout <1-5 minutes> get clientagingtimeout CLI on NS: (cloud level) this command will apply on both the radios bc setview cloud set cleintagingtimeout <1-5 minutes> get clientagingtimeout bc sendcfg cloud -- For applying configuration to whole cloud SNMP Configuration: Mib items on AP: Configuration: wifissidprofile table: (client-connect per-ssid web page ) wificlientagingtimeout(integer) -- device level: per radio, per ssid Mib items on NS: Configuration: wifissidprofile table: ( client-connect per-ssid web page ) wificlientagingtimeout (INTEGER) -- cloud level (same value will apply to both radios ) 8 ACCESS/ONE FIRMWARE USER MANUAL

9 Web Configuration: Rdio -> Configure > Wi-Fi > a/g Radio > Client Connect Figure 2: Timeout for Dissociated Clients 9 ACCESS/ONE FIRMWARE USER MANUAL

10 4 RADIUS Authentication Format This feature is available mainly for the APs. When any station is trying to associate with AP with Dynamic (802.1x) / WPA / WPA2 authentication, AP sends the RADIUS authentication request to the RADIUS server based on selected RADIUS authentication format. Two RADIUS formats currently supported are 1. Standard 2. Cisco When administrator has a Radius server compatible with Cisco format, s/he can set Radius authentication format as Cisco, and for rest of the Radius servers s/he can set Radius authentication format as Standard one (default). RADIUS format can be configured per SSID profile of AP. CLI on AP (device level) set radauthformat [standard-format cisco-format] get radauthforamt CLI on NS (cloud level) bc setview cloud set radauthformat [standard-format cisco-format] get radauthforamt bc sendcfg cloud -- For applying configuration to whole cloud SNMP Configuration: Mib items on AP: Configuration: wifissidprofile table: (client-connect per-ssid web page ) wifiradiusauthformat (INTEGER enumeration : standard(1), cisco(2) ) -- device level: per radio, per ssid Mib items on NS: Configuration: wifissidprofile table: (client-connect per-ssid web page ) wifiradiusauthformat (INTEGER enumeration : standard(1), cisco(2) ) -- cloud level ( same value will apply to both radios ) 10 ACCESS/ONE FIRMWARE USER MANUAL

11 Web Configuration: Configure > Wi-Fi > a/g Radio > Client Connect and select the Radius Authentication format Figure 3: RADIUS Authentication 4 11 ACCESS/ONE FIRMWARE USER MANUAL

12 5 TKIP Counter Measure Activation TKIP Counter Measure Activation is a mechanism designed to protect against modification attacks. If two MIC failures occur in 60 seconds TKIP Counter Measure Activation shuts down an access point and its communications for 60 seconds. When the access point is operational again, as a prerequisite all clients trying to reconnect change their keys and undergo a re-keying. MIC failure is generated when AP is not able to encrypt/decrypt the data packets. TKIP counter measure gets activated when administrator configures the authentication type either of WPA/WPA2/WPA-PSK/WPA2-PSK along with cipher as TKIP/Auto Negotiated. By default TKIP counter measure activation is enabled. CLI on AP (device level) set tcm enable disable get tcm 5 CLI on NS (cloud level) bc setview cloud set tcm enable disable get tcm bc sendcfg cloud -- For applying configuration to whole cloud SNMP Configuration: Mib items on AP: Configuration: wifissidprofile table: (client-connect per-ssid web page ) wifitcmactivationenable (TruthValue) -- device level:per radio, per ssid Monitor: wifiradiostats table: (for stats entry pertaining to radio itself ) (monitor radio-statistics web page ) statstcmconditioncount (INTEGER) statstcmconditionmac (MacAddress) 12 ACCESS/ONE FIRMWARE USER MANUAL

13 Mib items on NS: Configuration: wifissidprofile table : (client-connect per-ssid web page) wifitcmactivationenable (TruthValue) -- cloud level:per radio, per ssid ( same value will apply to both radios ) Monitor: nswifimoduleslist table: ( monitor ap-monitor web page ) strixtcmconditioncount (INTEGER) strixtcmconditionmac (MacAddress) Web Configuration: Configure > Wi-Fi > a/g Radio > Client Connect Figure 4: TKIP Counter Measure 5 13 ACCESS/ONE FIRMWARE USER MANUAL

14 6 Mobile Deployment Related Enhancements 6 For Mobility related deployment the suggested approach is to use one of the CPE device (EWS, MWS) as the mobile node and OWS / IWS as the infrastructure network. This section and following sections explain mobility related to trains but mobility is applicable to any scenario Vehicular, Truck, Bus, Maritime Boat/Ship etc. Following are some of the important points to note before mobile node related use-case and features are explained in more details: Mobile node is a separate Strix CPE device. This CPE device consists of a single / dual radio unit that is responsible for connecting the train to the OWS network infrastructure. Mobile node is not a part of the OWS side track network inventory. This means that mobile node is not required to be included by the network server and also does not require to be updated with new configurations files each time there are modifications in the infrastructure network. With this approach the solution is more flexible and allows a higher level of scalability. The mobile node associates to specific SSID in the OWS side track network and the traffic is sent in a specific VLAN associated to that SSID. Mobile node performs layer 2 NAT for the stations that are either connected to its Ethernet port or connected wirelessly on the other radio. Mobile node transparently passes through other VLANs from the Ethernet port to the wireless port and vice versa. If the traffic in the Ethernet port comes untagged it will be put by the side track node in the specific VLAN for the SSID where the mobile node is associated. If the traffic comes already tagged it will go through the mobile node untouched and will travel in the infrastructure network keeping the same VLAN tags values and priority. Mobile node can be managed remotely. It will be accessible via the VLAN SSID where it is connected. It can have a static or dynamic IP address. Specific scan list for foreground scanning is introduced. It makes the scanning behavior more optimized when the mobile node is not connected and is scanning only channels that are operational in the infrastructure network and discerns scanning unnecessary channels. Sections 6.1 to 6.4, explain the typical train mobility deployment scenario, for better understanding of the mobility feature. 14 ACCESS/ONE FIRMWARE USER MANUAL

15 6.1 Infrastructure Network / Train-track network The infrastructure network for a mobile deployment consists of a number of OWS APs connected to one another using a chain of BH s. If the infrastructure network needs more than 100 OWS nodes, the nodes need to be split into subnets. Each subnet can have a maximum of 100 nodes. For an infrastructure network to support train deployment, the OWS nodes should be mounted on poles beside the railway track. Service Provider Monitoring & Control Authentication & Billing Internet Tier 1 - Service Provider Network 6 Tier 2 - Trackside Mesh Network Figure 5: Trackside Mesh Network Access/One firmware supports building a network like the one described above Enhancements have been made in firmware for the following: User access to the infrastructure network on multiple VLANs over This feature is detailed in Section 7 Customer Premise VLANs. Ability to manage CPE connections to the infrastructure network on the untagged network or over a VLAN. This is detailed in Section 8 CPE Management. 15 ACCESS/ONE FIRMWARE USER MANUAL

16 6.2 Connection between Train and Infrastructure Network In a mobile deployment for trains, the train is connected to the infrastructure track network by mounting a CPE unit on the train. The CPE station establishes a wireless connection to the OWS AP of the infrastructure network. As the train moves, the CPE station roams from one AP to the next along the track, thus providing continuous and seamless connectivity between the train and the infrastructure network. MWS Figure 6: Connection between Train & Infrastructure Network To provide better connection between CPE and OWS APs, the following enhancements are made in the firmware: 6 Fast authentication protocol between CPE and OWS. This is detailed in Section 10 Fast Access/One authentication scheme. Improved background scanning algorithms. This is detailed in Section 11 Improved Background Scanning. New protocol for switching between AP s. This protocol does preauthentication of the CPE client before it roams to the new AP. 16 ACCESS/ONE FIRMWARE USER MANUAL

17 6.3 In-train Carriage Network Within a train, the network behind the CPE consists of a chain of AP / BH OWS units, with one OWS per carriage. The 11g APs are used for user access, while the 11a AP / BHs are used to link carriages. The in-train carriage network is a cloud by itself, separate from the infrastructure cloud. A CPE connects the intrain network to the infrastructure network. Tier 3 - In-train Wi-Fi User Access network Figure 7: In-Train Carriage Network Given the fact that train configuration / formation is not static, it is frequently reconfigured to accommodate the required passenger nodes, the train operator will add or remove passenger carriages without further notice or regard for underlying wireless network and its fixed inventory. Given the fact that a wireless Node within a passenger carriage will end up either in the train yard or will be attached to a different train altogether (completely different cloud). To facilitate carriages to be moved from one train to another, the concept of Supercloud has been developed and implemented in firmware. This is detailed in Section 9 Cloud Provisioning ACCESS/ONE FIRMWARE USER MANUAL

18 6.4 Wireless Access for Users on Train The 11g APs on the train carriages will provide wireless access to users on the train. Multiple SSID profiles may be created in the in-train carriage network to provide different levels of service. The data for the different SSID s will be carried over different VLAN s all the way to the infrastructure network. To provide this facility, the Customer Premise VLAN feature is implemented. This is detailed in Section 3 Customer Premise VLANs. Figure 8 : Wireless Access for Users on Train 6 As the train moves, the CPE breaks its link with the AP it is associated with on the infrastructure network, and establishes a new connection with the next AP on the infrastructure network which provides a better signal strength. The connection between the User and the Internet remains continuously maintained, even as the train moves along the track. Note: Based on the actual deployment scenarios, a router or switch may be needed between the in-carriage train network and the CPE on the train. 18 ACCESS/ONE FIRMWARE USER MANUAL

19 7 Customer Premise VLANs For an OWS AP to which a train CPE is connected, the packets received on the AP from the CPE over the air will be tagged with a specific VLAN ID. This VLAN ID needs to be preserved as the packets flow out on the Ethernet interface on the infrastructure side. To allow this, each SSID profile can be configured with multiple VLAN IDs (up to 16). Example: SSID-X mapped to VLAN ID 101, configured with Customer Premise VLAN IDs 200, 300. If a packet is received on the WLAN interface of the OWS AP on SSID-X with VLAN ID 200 (or 300), the packet is sent onto the Ethernet interface with VLAN ID 200 (or 300), that is, without being double-tagged. The packet simply is forwarded without modification. If the packet received on WLAN contains any other VLAN ID (say 400), it is double-tagged with 101, 400. This is the existing behavior before this enhancement. 7 If a packet is received on the Ethernet interface of the OWS AP with VLAN ID 200 (or 300), it is sent on the WLAN interface on SSID-X with VLAN ID 200 (or 300), i.e. without the VLAN ID being stripped. Again, the packet is forwarded without modification. If the packet is received on Ethernet interface with VLAN ID 101, it will be sent on the WLAN interface with the VLAN ID stripped. CPE WIRELESS AP SSID-X, WIRED SSID-X, SSID-X, , 400 SSID-X, , 400 SSID-X, untagged 101 SSID-X, untagged 101 Figure 9: Customer Premises VLAN 19 ACCESS/ONE FIRMWARE USER MANUAL

20 Wlan0 config ssid ssid-x Wlan0 ssid-x set customerpremisevlanid {add delete} [ ] (upto 16 vlan ids can be preserved per ssid) Wlan0 ssid-x get customerpremisevlanid SNMP Configuration: strixconfigwifi.mib: New snmp table: wificustomerpremisevlan wificustomerpremisevlan table: customerpremisevlanid INTEGER ( ) *acting as an index customerpremisevlanssid DisplayString customerpremisevlanrowstatus RowStatus Web Configuration: Configure > Wi-Fi > a Radio > Client Connect: (per ssid) 7 Figure 10: VLAN IDs 20 ACCESS/ONE FIRMWARE USER MANUAL

21 8 CPE Management 8.1 CPE Management from within VLAN A CPE connected to an OWS can be managed either from the untagged network on the infrastructure side, or from within the VLAN corresponding to the SSID used by the CPE to connect to the OWS. This capability can be configured on the OWS on a per-ssid basis. set ewsmgmtfromvlan {enable disable } get ewsmgmtfromvlan SNMP Configuration: wificlientconnect > wifissidprofiletable: wifiewsmgmtfromvlanenabled TruthValue Web Configuration: Configure-> Wi-Fi -> radio Client Connect 8 Figure 11: CPE Management 21 ACCESS/ONE FIRMWARE USER MANUAL

22 8.2 VLAN Tag for CPE Management The data from the CPE and the data behind the CPE are distinguished from one another by carrying the former over a specific VLAN ID between the CPE and the OWS AP. The VLAN ID used for this specific purpose cannot be one of the VLAN s used in the network for user traffic. This VLAN ID is controlled on the AP which relays the information to the CPE at association time. The CPE management VLAN ID is unique for the device, and is not configurable per SSID. set ewsmgmtvlanid <0-4095> get ewsmgmtvlanid SNMP Configuration: strixconfigsystem > sysgeneraltable : sysewsmgmtvlanid INTEGER( ) Web Configuration: Configure-> Wi-Fi -> radio Client Connect 8 Figure 12: VLAN Tag 22 ACCESS/ONE FIRMWARE USER MANUAL

23 9 Cloud Provisioning 9.1 Cloud Self Provisioning Key A Supercloud is defined as a set of Strix nodes which share the same provisioning key. BH modules will be able to associate with an AP in the same Supercloud, even if they are in different clouds. The Supercloud feature is enabled by default but can be deactivated by a CLI superuser command only. In Superuser CLI mode: set supercloud enable/disable ( to enable or disable supercloud feature ) This may be done on the NS cloud level CLI and applied to the whole cloud. Also, for the Supercloud feature to be active, the provisioningkey must be configured. If no provisioningkey is configured, the Supercloud feature is inactive, and the nodes will behave just like GA firmware for BH-AP connection. set provisioningkey <string: spaces allowed: 6 to 60 char> get provisioningkey SNMP Configuration: STRIX-CONFIG-SYSTEM mib, sysgeneraltable: sysprovisioningkey: DisplayString (SIZE(6..60)), read-write 9 Web Configuration: Configure > System > Self Provisioning: Figure 13: Cloud Self Provisioning Key 23 ACCESS/ONE FIRMWARE USER MANUAL

24 9.2 Storage of encrypted provisioning key As mentioned above, a Supercloud is a set of Strix nodes which share the same provisioning key. BH modules will be able to associate with an AP in the same Supercloud, even if they are in different clouds. This is achieved by generating a pre-shared key derived from the provisioningkey on the BH as well as the AP, and then letting the BH use this pre-shared key to verify that the AP is a valid AP to join (as detailed in next section). This pre-shared key is called the Supercloud secret key and is generated from the provisioning key by encrypting it using AES. The Supercloud secret key is never exposed to the user in any interface. Neither the provisioning key nor the Supercloud secret key is sent in any message over the wireless interface or wired Ethernet interface. When the cloud config file is sent from the NS to other modules as part of an Apply Configuration command, the cloud config file contains only the AES encrypted Supercloud secret key, and not the provisioning key. The provisioning key is not stored in unencrypted form in the flash file system. Only the AES encrypted key is stored in apcfg and clcfg files. 9.3 Probe Changes for Key Challenge When a BH module does not find an AP to connect to in its own cloud for more than a certain time, it will attempt to associate with an AP in its Supercloud, if it is configured with a provisioning key. Before associating, it will verify whether the AP has the same provisioning key using a challenge mechanism. 9 The challenge action is initiated by a BH unit only if it cannot find an AP to connect to in its own cloud for a period of time, defined by the cloudroamingtime parameter. set cloudroamingtime <integer: minutes: 1 to 60 min> [ 0 to disable ] get cloudroamingtime This is the time that the BH tries to look for an AP in its own cloud, before trying to associate with an AP in its Supercloud. 24 ACCESS/ONE FIRMWARE USER MANUAL

25 SNMP Configuration: STRIX-CONFIG-SYSTEM mib, sysgeneraltable: syscloudroamingtime: INTEGER(1..60), read-write Web Configuration: Configure > System > Self Provisioning: Figure 14: Probe Changes for Key Challenges 9.4 Network Server Inventory Update When a BH module associates with an AP in its Supercloud, the AP will not have the BH and modules behind the BH in its inventory list (since they were in different clouds). This will keep the BH in restricted mode. 9 The NS on the AP side will continuously challenge all modules via CIMS messaging. If the new BH module successfully authenticates itself in the challenge response, the NS will automatically update its inventory with the BH s information and send the BH and the AP a new inventory list, thereby taking it out of restriction mode. 9.5 Inventory Aging NS will keep track of the last time it received a CIMS message from any module in its inventory list. If a module is not seen for more than a configurable time, the NS will age out the entry for that module in its inventory list and send out the updated list to all modules in the Supercloud. The inventory aging applies to non- NS modules only (that is, NS s are never aged out) and is performed by the master NS only. set inventoryagingtime <integer: minutes: 20 to 1440 min> [ 0 to disable] get inventoryagingtime 25 ACCESS/ONE FIRMWARE USER MANUAL

26 SNMP Configuration: STRIX-CONFIG-SYSTEM mib, sysgeneraltable: sysinventoryagingtime : INTEGER ( ), read-write Web Configuration: NS: Configure > System > Self Provisioning: Figure 15: Inventory Aging 9 26 ACCESS/ONE FIRMWARE USER MANUAL

27 10 Fast Access/One Authentication Scheme To shorten the time required to authenticate a CPE to an OWS AP, and to keep the link secure, a proprietary fast authentication scheme, called Access/One authentication, has been developed. Normally the authentication request/response happens between client and AP followed by association request/response, which may be further supplemented by key exchange messages in case of WPA/WPA2. If the fast authentication is enabled, a secure link can be established using a single request/response. With Access/One authentication, both the CPE and the AP will install AES keys for unicast data encryption. The key used will be generated from the PSK passphrase (which is based on SSID and passphrase string), and each part s MAC address. This will ensure that each CPE uses a different unicast key for robust security. All stations in one BSS will use the same broadcast key based on PSK passphrase and BSSID. AccessOne authentication scheme uses AES encryption only. set auth AccessOne set passphrase 10 SNMP Configuration: wifissidprofiletable: wifiauthmethod : { accessone } Web Configuration: NS Configure > Client Connect Figure 16: Authentication Scheme 27 ACCESS/ONE FIRMWARE USER MANUAL

28 11 Improved Background Scanning 11.1 Software Acknowledgement for PowerSave requests When a BH initiates a background scan, it sends a PowerSave request to the AP so that it buffers up packets destined to the BH, while the BH moves to a different channel. Under high loads, this could cause data loss as the BH would move away from its original channel before the AP got a chance to process the PowerSave request. To prevent this, a software level acknowledgement has been added. The BH moves to a different channel only after it receives this acknowledgement. Using this mechanism, the AP-BH or AP-CPE link does not show any packet drop every background scanning interval time, under ideal RF conditions Configurable queue depth on AP for CPE and BH connections To sustain a high data throughput between AP & CPE and between AP & BH, it is necessary to have sufficient queue depth to buffer the packets on the AP, while the CPE or BH is scanning a different channel. This queue depth can now be configured on the AP. A queue depth of 100 is able to sustain a 20Mbps downstream traffic with 1500 byte packets without interruption, under ideal RF conditions. 11 set cpepsqdepth <50 250> -- for CPE connection get cpepsqdepth set wlncpsqdepth < > -- for Backhaul connection get wlncpsqdepth SNMP Configuration: wifiradioparams: radioparamstable wificpepsqueuedepth INTEGER( ) wifiwlncpsqueuedepth INTEGER ( ) 28 ACCESS/ONE FIRMWARE USER MANUAL

29 Web Configuration: NS - Configure > Wi-Fi > General Figure 17: Access Point Packet Queues ACCESS/ONE FIRMWARE USER MANUAL

30 12 US Public Safety (4.9 GHz) 12.1 PS capability per Radio Manufacturing command has been added to set the PS capability per radio on a dual-radio board. Note: If a PS-capable radio is restricted to 4.9 Ghz only, it will not be operational in any country code except USPS. Note: This feature applies to OWS model , and OWS 11AG21 specifically and will not be available for other models USPS Configuration from NS The US Public Safety country code can now be applied on a cloud-wide basis by setting it on the master NS. USPS country code is treated as a superset for US (5.x Ghz) channels and PS (4.9Ghz) channels. Those radios that are PS-capable will operate on the 4.9Ghz band. Other radios will operate on the 5.x Ghz band. Web Configuration: NS Configure > Wi-Fi > 4.9 USPS Radio Parameters: 12 Figure 18: USPS Configuration 30 ACCESS/ONE FIRMWARE USER MANUAL

31 12.3 Creation of PS-only SSIDs SSID profiles can now be created at the cloud level that would apply only to PScapable radios in the cloud. These profiles would not be activated on radios that do not have the PS capability bit set. Web Configuration: NS Configure > Client Connect > Add/Remove SSID Figure 19: PS-only SSIDs ACCESS/ONE FIRMWARE USER MANUAL

32 13 WPA2 Security WPA2 security feature is supported on Access/One AP s. Both WPA2-PSK (using pre-shared passphrase) and WPA2 (using Radius) are supported. These authentication schemes will work with AES, TKIP or auto-negotiated encryption. set auth <WPA2 WPA2-PSK> set encryption enable set cipher < aes tkip auto > SNMP Configuration: wifissidprofiletable: wifiauthmethod : { wpa2-psk, wpa2 } wifiencryptionmethod: { aes, tkip, auto } Web Configuration: NS Configure > Client Connect Figure 20: WAP2 Security ACCESS/ONE FIRMWARE USER MANUAL

33 14 Data Rate Range The transmit data rate can be controlled between a minimum rate and a maximum rate. Earlier, the system enabled only to set it to a fixed rate or allow it to pick any data rate across the range of all possible data rates. set rate range <minrate> <maxrate> 14 SNMP Configuration: wifiradioparams: radioparamstable: wifidataraterangemin and wifidataraterangemax { rate-best(1), rate-250kb(2), rate-500kb(3), rate-1mb(4), rate-2mb(5), rate-3mb(6), rate-4-5mb(7), rate-5-5mb(8), rate-6mb(9), rate-9mb(10), rate-11mb(11), rate-12mb(12), rate-18mb(13), rate-24mb(14), rate-27mb(15), rate-36mb(16), rate-48mb(17), rate-54mb(18), rate-72mb(19), rate-96mb(20), rate-108mb(21), rate-range(22), } Web Configuration: Radio Configure > Wi-Fi > a/g Radio > Parameters Figure 21: Data Rate 33 ACCESS/ONE FIRMWARE USER MANUAL

34 15 Telnet / Web RADIUS Authentication 15.1 RADIUS Authentication for Telnet / Web users In order to accommodate network administrative situations in which simply having an "Admin" and "Guest" login is not sufficient; Access/One modules has the ability to authenticate administrative users via RADIUS server. Earlier, only "Admin" or "Guest" were acceptable login names. Now the user will be able to configure a management RADIUS server, which will be responsible for checking any attempted login with other than "Admin" or "Guest" as the user name. This means that if a user attempts to log into a Strix module, either via telnet or via the web interface, using a username other than Admin/Guest, and if management radius is enabled, the configured RADIUS server will be used to authenticate the username/password. If successful, the user will be logged into the system. Only CHAP authentication is currently supported for management radius authentication. set mgmtradius {enable disable } set mgmtradius name {primary secondary } <ip address> set mgmtradius port <port number> set mgmtradius secret <radius secret> SNMP Configuration: strixconfigsystem sysmgmtradiustable { sysmgmtradiusenabled, sysmgmtradiusserver1, sysmgmtradiusserver2, sysmgmtradiusport, sysmgmtradiussecret } 15 Web Configuration: NS Configure > System > User Login 34 ACCESS/ONE FIRMWARE USER MANUAL

35 Figure 22: RADIUS Server 15.2 Caching for WEB users authenticated by RADIUS When a user logs in via the web using RADIUS authentication, the RADIUS authentication server may be queried excessively. This is because various elements of each web page are individually protected, each requiring authentication before providing them. Loading just the home page on an NS, for example, may cause approximately 20 to 30 messages to the authentication server. To solve this problem, the frequency of messages to the RADIUS server is reduced. This is accomplished by caching any user who successfully authenticates. Any time there is a need to send some element of a web page, which requires authentication; system will first reference the cache. If the user is found in the cache, it will simply approve him and send the required data. The cache will have the feature of aging out users after a configurable period of time. By default, the aging time will be set to 10 minutes. The cache will allow up to 20 users to be cached. When the cache is full and another user needs to be cached, the least-recently-used entry in the cache will be deleted and the new user entered. 15 set mgmtradius cachetime <seconds> 35 ACCESS/ONE FIRMWARE USER MANUAL

36 16 Nodename in SNMP traps All SNMP traps generated by Strix AccessOne modules will have the nodename (also known as Stackname) of the node on which the module is located. The OID: trapnodename will be carried by the SNMP trap PDU ACCESS/ONE FIRMWARE USER MANUAL

37 17 Aging for Power-Save Clients Some client devices like WIFI phones stay in Power Save mode for many minutes or even hours. Aging them out on the AP within 5 minutes (default aging time for clients) causes a loss of performance. For such devices, aging can be configured separately from normal clients. The Strix CPE and Backhauls will not be affected by this configuration. This timeout can be configured per SSID profile on the AP. The clientagingpstimeout is used for aging out of the client entries when in PS mode. Meaning when there is no packet received from this station for clientagingpstimeout (only when the station was in power save mode) the Station entry is removed. set clientagingpstimeout <0-120 minutes> [ 0 means disabled ] get clientagingpstimeout SNMP Configuration: wifissidprofiletable: wifipsclientagingtimeout INTEGER (0..120) Web Configuration: No web configuration is available for this ACCESS/ONE FIRMWARE USER MANUAL

38 18 CCA Support Clear Channel Assessment (CCA) is a logical function within the physical layer that determines the current state of use of the wireless medium. This function helps in contention avoidance by denying the service to send a packet when the channel is not clear to do so. Support has been added for controlling Clear Channel Assessment by the Radio. When the mode is manual, the configured threshold value is used to determine whether the channel is clear for transmission. The hardware obeys a threshold level of the clarity of wireless medium below which the channel is considered clear to send. The selection or tuning of such threshold level can be done with the set/get cca commands. CCA mode selection command is used to configure whether to use a threshold level that is: 1. Fixed (manual mode): In this mode, the CCA value is read from the radio chip-set at system start up time, and is fixed for the entire duration when radio is enabled. The user is permitted to change this value of the threshold. 2. Automatically determined by software algorithm (Auto mode): In this mode, the software senses the highest RSSI level of interference from the same channel or from other channel interference due to channel cross-talk, and uses this highest level of interference to determine the CCA threshold level prior to tuning on this channel. Once tuned on a channel, the CCA threshold level does not change. Note that this value will also update upon channel reselection. set cca mode { manual auto } set cca threshold <value> SNMP Configuration: wifiradioparams wificcamode { auto, manual } wificcathreshold INTEGER 18 Web Configuration: NS Configure > Wi-Fi > General 38 ACCESS/ONE FIRMWARE USER MANUAL

39 Figure 23: CCA Mode ACCESS/ONE FIRMWARE USER MANUAL

40 19 Maximum Distance between AP and BH The possible distance between an AP and a BH unit depends on the acknowledgement timeout. The greater the timeout, further the distance is possible. But this will also increase the timeout for retry in case of a failed packet and cause unnecessary delays. Hence the optimal timeout will be different for different deployments. The maximum distance is configurable on APs and BHs with the following CLI command. set maxdistance <value> [ Default is 3.0 miles] To allow tuning the maxdistance parameter between AP s and BH s, the user can choose to make the BH follow the AP. In other words, the AP transmits its maxdistance value in its beacons and probe responses in the information element, and every BH connected to that AP will use the maxdistance value received from the AP, rather than its own configured maxdistance. AP can be configured to transmit its max distance setting via beacon/probe response: set apmaxdistance <enable/disable> [Default: enabled] BH can be configured to use its own max distance setting or max distance setting received from AP: set useapmaxdistance <enable/disable> [Default: enabled] ACCESS/ONE FIRMWARE USER MANUAL

41 20 Disconnecting Weaker Clients In the standard, the so-called performance anomaly is a well-known issue. It is observed that when some mobile / fixed clients use a lower bit rate than the others, the performance of all other clients is considerably degraded. Such a situation is a common case in wireless local area networks in which a host far away from an Access Point is subject to signal fading and interference. To cope with this problem, the client changes its modulation type, which degrades its bit rate to some lower value. To cope up with this issue, this feature is introduced for administrator to define rules or trigger points which helps system to isolate those weaker clients and then depending on the rule, take appropriate action for those clients. The triggers can be defined by administrator for % radio utilization (RX and/or TX or both) or % packet transfers of the overall switching capacity of AP. These triggers can be defined for different traffic situation i.e. for different number of clients connected on different SSIDs of same AP. There can be multiple triggers defined per set of users range (e.g. trigger 1 for 1-5 users, trigger 2 for 6 to 10 users and so on.). By default, this feature is disabled. When the feature is enabled, and based on the configured triggers system finds out weaker clients, it applies one of the following actions, which is again configurable per trigger by the administrator. The possible actions are: 1. Disconnect the client for configurable time and generate Syslog event for the same. 2. Generate the Syslog event but do not disconnect the client. The Syslog event will have information about radio utilization of the client, % packet transfers, SSID, MAC address of the client and disconnect timeout period. 20 CLI on AP (device level) set wctrigger enable disable set wctrigger donothing <from client no.> <to client no.> <utilization> <packet threshold> <RxTxBoth BothSeparately TxOnly RxOnly> set wctrigger disconnect <from client no.> <to client no.> <utilization> <packet threshold> <RxTxBoth BothSeparately TxOnly RxOnly> <disconnect period (sec)> get wctrigger del wctrigger <wctrigger no.> CLI on NS (cloud level) bc setview cloud 41 ACCESS/ONE FIRMWARE USER MANUAL

42 set wctrigger enable disable set wctrigger donothing <from client no.> <to client no.> <utilization> <packet threshold> <RxTxBoth BothSeparately TxOnly RxOnly> set wctrigger disconnect <from client no.> <to client no.> <utilization> <packet threshold> <RxTxBoth BothSeparately TxOnly RxOnly> <disconnect period (sec)> get wctrigger del wctrigger <wctrigger no.> bc sendcfg cloud -- For applying configuration to whole cloud SNMP Configuration: Mib items on AP: Configuration: WifiWCTriggerTable WifiWCTriggerEntry -- device level; per radio; per ssid Mib items on NS: Configuration: WifiWCTriggerTable WifiWCTriggerEntry -- cloud level; per radio; per ssid Web Configuration: Configure > Wi-Fi > a/g Radio > Client Connect > Weaker Client Trigger > Manage Trigger Enable or disable as per the requirement Figure 24: Manage Weaker Client Triggers Figure 25: Enable/Disable Weaker Links 20 Now add a new Trigger entry & click on the update button. 42 ACCESS/ONE FIRMWARE USER MANUAL

43 Figure 26: Add New Weaker Client Trigger Now again click the update button. If we want to delete the weaker client trigger entry then click on the X. Figure 27: Delete Weaker Client Trigger ACCESS/ONE FIRMWARE USER MANUAL

44 21 Useful System Sanity Monitor and Notification Features 21.1 System CPU & Memory Usage Sometimes it is desirable for the administrator to know the System properties like System s current CPU utilization and Memory utilization in order to make sure that System is working fine and is well under control and get notification when things start to go out of control, in the worst case. With this feature, such properties are constantly analyzed. It is also possible for the administrator to configure the threshold values for them as well through CLI and M1 interface. Whenever system memory or CPU utilization goes beyond those configured threshold values, SNMP trap and Syslog event will be generated for indicating the same. CLI on AP (device level) set cpuusagealarmthreshold <0-100> get cpuusagealarmthreshold set memoryusagealarmthreshold <0-100> get memoryusagealarmthreshold CLI on NS (cloud level) bc setview cloud -- Set the view as cloud level set cpuusagealarmthreshold <0-100> get cpuusagealarmthreshold set memoryusagealarmthreshold <0-100> get memoryusagealarmthreshold bc sendcfg cloud -- Apply configuration to whole cloud SNMP Configuration: Not Supported. Web Configuration: Go to Configure > System > Network Management > General 21 Figure 28: CPU and Memory Usage Alarm Threshold 44 ACCESS/ONE FIRMWARE USER MANUAL

45 21.2 Node Temperature & Peer RSSI Administrator already has capability to get temperature and peer RSSI of BH (backhaul) radio. Administrator now also has capability to configure threshold values through CLI & M1 interface for temperature and peer RSSI as well. So, whenever node temperature or per RSSI of BH goes beyond the configured threshold values, SNMP trap and Syslog event will be generated for indicating the same. CLI on AP (device level) set nodetempmaxalarmthreshold <0-100> get nodetempmaxalarmthreshold set nodetempminalarmthreshold <-50-0> get nodetempminalarmthreshold set peerrssi11aalarmthreshold < > get peerrssi11aalarmthreshold set peerrssi11bgalarmthreshold < > get peerrssi11bgalarmthreshold CLI on NS (cloud level) bc setview cloud -- Set the view as cloud level set nodetempmaxalarmthreshold <0-100> get nodetempmaxalarmthreshold set nodetempminalarmthreshold <-50-0> get nodetempminalarmthreshold set peerrssi11aalarmthreshold < > get peerrssi11aalarmthreshold set peerrssi11bgalarmthreshold < > get peerrssi11bgalarmthreshold bc sendcfg cloud -- Apply configuration to whole cloud SNMP Configuration: Not Supported Web Configuration: Go to Configure > System > Network Management > General 21 Figure 29: Node Temperature and Peer RSSI Alarm Threshold 45 ACCESS/ONE FIRMWARE USER MANUAL

46 21.3 RF Utilization & Number of Users This is a feature that is added for providing alert / event in Syslog and SNMP for following situation: 1. When no. of users connected per radio goes beyond a user configured threshold value. 2. When % TX / RX utilization of a particular radio goes beyond user configured threshold value. CLI on AP (device level) set thresholdalarm datarxth <1-100> set thresholdalarm datatxth <1-100> set thresholdalarm noofclientth <1-128> get threshold -- Displays configured Rx, Tx data threshold & number of client threshold value CLI on NS (cloud level) bc setview cloud -- Set the view as cloud level set thresholdalarm datarxth <1-100> set thresholdalarm datatxth <1-100> set thresholdalarm noofclientth <1-128> get threshold -- Displays configured Rx, Tx data threshold & number of client threshold value bc sendcfg cloud -- Apply configuration to whole cloud SNMP Configuration: Not Supported. Web Configuration: Go to Configure > Wi-Fi > a/g Radio > Parameters Figure 30: Other Threshold Alarm ACCESS/ONE FIRMWARE USER MANUAL