SYMBOL-CC-WS2000-MIB

type

TEXTUAL-CONVENTION

A date-time specification. field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UTC '+' / '-' 9 10 hours from UTC 0..11 10 11 minutes from UTC 0..59 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then timezone information (fields 8-10) is not present.

type

type

type

type

type

type

type

type

TEXTUAL-CONVENTION

The RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].) The status column has six defined values: - `active', which indicates that the conceptual row is available for use by the managed device; - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); - `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device; - `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; - `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row. Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: `notReady', `notInService' or `active'. That is, when queried, an existing conceptual row has only three states: it is either available for use by the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady'). NOTE WELL This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'. Also note that whenever any elements of a row exist, the RowStatus column must also exist. To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram: STATE +--------------+-----------+-------------+------------- | A | B | C | D | |status col.|status column| |status column | is | is |status column ACTION |does not exist| notReady | notInService| is active --------------+--------------+-----------+-------------+------------- set status |noError ->D|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndGo |inconsistent- | | | | Value| | | --------------+--------------+-----------+-------------+------------- set status |noError see 1|inconsist- |inconsistent-|inconsistent- column to | or | entValue| Value| Value createAndWait |wrongValue | | | --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError column to | Value| entValue| | active | | | | | | or | | | | | | | |see 2 ->D| ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|wrongValue --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError column to | | | | destroy | ->A| ->A| ->A| ->A --------------+--------------+-----------+-------------+------------- set any other |see 4 |noError |noError |see 5 column to some| | | | value | | see 1| ->C| ->D --------------+--------------+-----------+-------------+------------- (1) goto B or C, depending on information available to the agent. (2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, then return noError and goto C. (4) at the discretion of the agent, the return value may be either: inconsistentName: because the agent does not choose to create such an instance when the corresponding RowStatus instance does not exist, or inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or noError: because the agent chooses to create the instance. If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A. (5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned. NOTE: Other processing of the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc. Conceptual Row Creation There are four potential interactions when creating a conceptual row: selecting an instance-identifier which is not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device. Interaction 1: Selecting an Instance-Identifier The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics. In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.) Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different. Finally, the management station could select a pseudo-random number to use as the index. In the event that this index was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation. A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used. Interaction 2: Creating the Conceptual Row Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions. Interaction 2a: Creating and Activating the Conceptual Row The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes: - a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'. When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information available to the agent is provided by two sources: the management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row. NOTE WELL Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm. Interaction 2b: Negotiating the Creation of the Conceptual Row The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the columns indicated by its column requirements.) Otherwise, the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3. Interaction 3: Initializing non-defaulted Objects The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes: - a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column. - the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column. - the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column. If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4. Interaction 4: Making the Conceptual Row Available Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'. NOTE WELL A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device. If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absense of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Conceptual Row Suspension When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified). Conceptual Row Deletion For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady', `notInService' or `active'.) If the operation succeeds, then all instances associated with the conceptual row are immediately removed.

type

type

type

type

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-IDENTITY

WS2000 with 1 WAN port, 6 LAN ports.

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-TYPE

The serial number of the switch. This value is unique for each instance of the WS2000 switch.

OBJECT-TYPE

This value is a two-character representation of the country code. Note: when changing this _CountrySelection, the current channel and power levels are NOT changed. The prior settings for these values may or may not be valid/legal for the new country selected. It is up to the network management software to ensure that channel and/or power settings are changed BEFORE changing the country selection so that no such invalid/illegal state is reached, even for a short interim. country code: Argentina: ar Australia: au Austria: at Bahrain: bh Belarus: by Belgium: be Botswana: bw Brazil: br Bulgaria: bg Canada: ca Chile: cl China: cn Colombia: co Costa Rica: cr Croatia: hr Czech Republic: cz Denmark: dk Ecuador: ec Egypt: eg Estonia: ee Finland: fi France: fr Germany: de Greece: gr Hong Kong: hk Hungary: hu Iceland: is India: in Indonesia: id Ireland: ie Israel: il Italy: it Japan: jp Jordan: jo Kazakhstan: kz Kuwait: kw Latvia: lv Liechtenstein: li Lithuania: lt Luxembourg: lu Malaysia: my Mexico: mx Morocco: ma Namibia: na Netherlands: nl New Zealand: nz Norway: no Oman: om Peru: pe Philippines: ph Poland: pl Portugal: pt Qatar: qa Romania: ro Russia: ru Saudi Arabia: sa Singapore: sg Slovak Republic: sk Slovenia: si South Africa: za South Korea: kr Spain: es Sri Lanka: lk Sweden: se Switzerland: ch Taiwan: tw Thailand: th Turkey: tr Ukraine: ua United Arab Emirates: ae United Kingdom: uk United States: us Uruguay: uy Venezuela: ve Vietnam: vn

OBJECT-IDENTITY

OBJECT-TYPE

The same text that follows 'HW=' in sysDescr, EXCLUDING the 'HW='.

OBJECT-TYPE

The same text that follows 'FW=' in sysDescr, EXCLUDING the 'FW='. (The bootcode version).

OBJECT-TYPE

The same text that follows 'SW=' in sysDescr, EXCLUDING the 'SW='.

OBJECT-TYPE

The same text that follows 'MIB=' in sysDescr, EXCLUDING the 'MIB='. The MIB version is identified by a two-digit major version number (with a leading zero if needed), followed by a lower-case letter minor version and 0 or more character info number. The major MIB version is changed whenever it becomes incompatible to its previous version; i.e., some variables have been deleted or the behavior/meaning has been changed. Minor version number is changed when new features have been added, but existing behavior is completely unchanged.

OBJECT-TYPE

The same text that follows 'CLI=' in sysDescr, EXCLUDING the 'CLI='.

OBJECT-TYPE

Version of XML template implemented on this switch. (Much like MIB version - read details there).

OBJECT-TYPE

The serial number of the switch. This value is unique for each instance of a given switch type.

OBJECT-TYPE

Enable/Disable DNS Relay Mode

OBJECT-TYPE

Enable/Disable SSLV2 Support

OBJECT-TYPE

Enable/Disable SSHV1 Support

OBJECT-TYPE

Enable/Disable SSL Weak Cipher Support

OBJECT-IDENTITY

OBJECT-TYPE

Writing this value causes the switch to reset to factory conditions. NOTHING is retained, NOT the static IP address assignments (if any), NOR any non-factory-default SNMP settings, nor any other non-factory-default settings. Given this, be warned that setting this value may very well cause all communication paths to the WS2000 to be lost. (However, if DHCP is used to obtain an IP addr on the WAN port, and only default SNMP settings are used, communications may be possible after the factory reset).

OBJECT-TYPE

Writing this value causes the switch to reset in the same fashion as a common, (non-factory) reset.

OBJECT-TYPE

Writing this value resets all counters in the ccRf > ccMus sub-tree. Obsolete in WS2000 v1.5

OBJECT-TYPE

Performs a factory reset, EXCEPT that Wan IP and SNMP access settings are retained across the reset. Specifically: Wan Ip + related settings Pppoe settings WS2000 wan access SNMP setting SNMP v1/v2/v3 access settings

OBJECT-TYPE

Writing this value resets all counters in the ccRf sub-tree except for the ccPortalSystemStatsTable and ccPortalTable

OBJECT-IDENTITY

OBJECT-TYPE

Specifies if the firmware is to be loaded to the switch via FTP or TFTP or SFTP or CF Card.

OBJECT-TYPE

The interface to use in contacting the FTP or TFTP or SFTP server. This is required since the actual firmware load is accomplished via boot code that does not contain routing logic.

OBJECT-TYPE

The path to the firmware on the SFTP/TFTP/FTP server. Remember that the type of separator varies depending on the operating system of the server. For Windows, use '\', for Unix use '/'. No path need be specified, (in which case the default directory for the TFTP/FTP/SFTP server will be used); if a path is specified, remember to terminate it with a trailing '/' or '\'.

OBJECT-TYPE

The name, (on the server), of the firmware file to load. If operation is set to cfFirmwareToSwitch, this variable is the file name on the compact flash card.

OBJECT-TYPE

Set this value to start the firmware load operation. Note that the actual SFTP/TFTP/FTP does not begin immediately, as first the 'operational' firmware shuts-down, and returns to low-level boot code, which actually starts the transfer.

OBJECT-TYPE

This value reflects the result of the most-recent firmware load since reboot, (if any).

OBJECT-TYPE

The success/failure status of the most recent firmware load.

OBJECT-IDENTITY

OBJECT-TYPE

Specifies the type and direction of the transfer to perform involving the configuration file.

OBJECT-TYPE

The path to the firmware on the SFTP/TFTP/FTP server. Remember that the type of separator varies depending on the operating system of the server. For Windows, use '\', for Unix use '/'. No path need be specified, (in which case the default directory for the SFTP/TFTP/FTP server will be used); if a path is specified, remember to terminate it with a trailing '/' or '\'.

OBJECT-TYPE

The name, (on the server), of the configuration file to load/store from/to the server.

OBJECT-TYPE

Set this value to start the configuration file operation. Note that unlike a firmware load, the actual FTP/TFTP/SFTP transfer does begin virtually immediately.

OBJECT-TYPE

This value counts the total number of configuration file transfers completed, (whether they succeed or fail). The SNMP manager should save the value of this counter just before starting a LoadCfg operation, and then wait for this value to increment before checking the Result and/or Success values.

OBJECT-TYPE

This value reflects the result of the most-recent configuration file load/store.

OBJECT-TYPE

The success/failure status of the most recent configuration file load/store.

OBJECT-IDENTITY

OBJECT-TYPE

This value will increment by 1 or more for each config change. It persists across reboots. This variable can only be SET with the same value that it currently contains. Any other value will cause a SET-FAILED. Note that this is NOT a TEST-AND-INCREMENT semaphore, as this value does not immediately increment after a config change, but only after a short, though non-zero, delay. Because of this non-zero delay, it is not suitable as a semaphore. Note also that this value counts the number of times that Flash memory has been written, which may be greater than the number of config changes.

OBJECT-TYPE

A snapshot of sysUpTime as of the last config change.

OBJECT-TYPE

Can be used to solve the multiple-manager problem. Before performing any SETs, the manager reads this value. As a VAR-BIND of the only/last SET PDU, this value is written with that value read. If some other manager had made changes, this value would have incremented, and the SET to it will fail. Note that this only guards against other managers that use this semaphore. Changes made without using this value will NOT be protected against. For this reason, it is suggested that ccCfgHistChangeCount also be SET - though that is not a perfectly fail-safe semaphore, it will in most cases protect even against this latter case.

OBJECT-IDENTITY

OBJECT-TYPE

IP address of the server used for a firmware load, or configuration file load/store operation.

OBJECT-TYPE

Username for FTP LoadFw or LoadCfg operations.

OBJECT-TYPE

Password for FTP LoadFw or LoadCfg operations.

OBJECT-IDENTITY

OBJECT-TYPE

Counts the total number of SNMP requests rejected due to ACL violations since boot.

OBJECT-TYPE

The IP address of the last SNMP request to be denied due to ACL violation.

OBJECT-TYPE

SNMPv3 Engine ID

OBJECT-IDENTITY

OBJECT-TYPE

Table of SNMP v1/v2 access entries.

OBJECT-TYPE

Description.

OBJECT-TYPE

Simple Index.

OBJECT-TYPE

Community Name of the SNMP manager.

OBJECT-TYPE

Starting OID.

OBJECT-TYPE

OID Limit whether the entire MIB tree or a specific OID set.

OBJECT-TYPE

Access type whether RO or RW.

OBJECT-TYPE

Row Status.

OBJECT-TYPE

Table of SNMP v3 access entries.

OBJECT-TYPE

Description.

OBJECT-TYPE

Simple Index.

OBJECT-TYPE

v3 User Name.

OBJECT-TYPE

Security Level.

OBJECT-TYPE

Starting OID.

OBJECT-TYPE

OID Limit whether the entire MIB tree or a specific OID set.

OBJECT-TYPE

Access type whether RO or RW.

OBJECT-TYPE

Authentication Algorithm used.

OBJECT-TYPE

Authentication Password.

OBJECT-TYPE

Privacy Algorithm used.

OBJECT-TYPE

Privacy Password.

OBJECT-TYPE

Row Status.

OBJECT-TYPE

Table of SNMP access control entries.

OBJECT-TYPE

Description.

OBJECT-TYPE

Simple Index.

OBJECT-TYPE

Starting IP range of the SNMP manager allowed to access the switch.

OBJECT-TYPE

Ending IP range of the SNMP manager allowed to access the switch.

OBJECT-TYPE

Row Status.

OBJECT-IDENTITY

OBJECT-TYPE

Table of SNMP v1/v2 trap configuration entries.

OBJECT-TYPE

Description.

OBJECT-TYPE

Simple Index.

OBJECT-TYPE

Destination IP of Trap Manager.

OBJECT-TYPE

Destination Port of Trap Manager.

OBJECT-TYPE

Community Name.

OBJECT-TYPE

SNMP protocol version.

OBJECT-TYPE

Row Status.

OBJECT-TYPE

Table of SNMP v3 trap configuration entries.

OBJECT-TYPE

Description.

OBJECT-TYPE

Simple Index.

OBJECT-TYPE

Destination IP of Trap Manager.

OBJECT-TYPE

Destination Port of Trap Manager.

OBJECT-TYPE

User name of SNMP v3 user.

OBJECT-TYPE

Security Level.

OBJECT-TYPE

SNMP v3 Authentication Algorithm.

OBJECT-TYPE

SNMP v3 Authentication Password.

OBJECT-TYPE

SNMP v3 Privacy Algorithm.

OBJECT-TYPE

SNMP v3 Privacy Password.

OBJECT-TYPE

Row Status.

OBJECT-IDENTITY

OBJECT-TYPE

Capacity of the Compact Flash card in Kbyte.

OBJECT-TYPE

Number of Kbyte in use on the Compact Flash card.

OBJECT-IDENTITY

OBJECT-TYPE

The number of seconds backwards from the specified timestamp that the the 'Short' window extends backwards in time.

OBJECT-TYPE

The frequency at which the 'Short' summary stats are updated.

OBJECT-TYPE

Same as corresponding 'Short' value, for the 'Long' window.

OBJECT-TYPE

Same as corresponding 'Short' value, for the 'Long' window.

OBJECT-IDENTITY

OBJECT-TYPE

Types of network management access to permit.

OBJECT-IDENTITY

OBJECT-TYPE

Allow Airbeam smart. (If enabled, Airbeam access is only allowed from the LAN interfaces).

OBJECT-TYPE

Airbeam password. (username is 'airbeam').

OBJECT-IDENTITY

OBJECT-TYPE

The type of authentication used to authenticate the administrator.It can be a local database or a radius server.

OBJECT-TYPE

Administrator password. Can only be read, (via GET), using a community string capable of writing, (via SET), the value. If an otherwise valid community string is used, a string of length 0 is returned.

OBJECT-TYPE

The IP address of the radius server which is used to authenticate the administrator

OBJECT-TYPE

The port of the radius server which is used to authenticate the administrator

OBJECT-TYPE

The shared secret the radius server which is used to authenticate the administrator

OBJECT-IDENTITY

OBJECT-TYPE

The duration within which the user can enter the password after providing the user id.

OBJECT-TYPE

The duration within which the server should receive the keep alive responses from the client. In SSH v2, the server shall timeout if does not receive Keep alive responses from the client.

OBJECT-TYPE

HTTP/HTTPS connection timeout.

OBJECT-IDENTITY

OBJECT-TYPE

Level of logging to perform.

OBJECT-TYPE

Send logs to external syslog.

OBJECT-TYPE

IP addr of syslog server.

OBJECT-TYPE

Delete the Core File.

OBJECT-TYPE

Transfer the core file to external FTP server.

OBJECT-IDENTITY

OBJECT-TYPE

Enable NTP.

OBJECT-TYPE

Preferred NTP server IPaddr.

OBJECT-TYPE

Preferred NTP server port number.

OBJECT-TYPE

1st alternate NTP server IPaddr.

OBJECT-TYPE

1st alternate NTP server port number.

OBJECT-TYPE

2nd alternate NTP server IPaddr.

OBJECT-TYPE

2nd alternate NTP server port number.

OBJECT-TYPE

GMT Hour Offset. Not implemented in WS2000 2.0

OBJECT-TYPE

GMT Minute Offset. Not implemented in WS2000 2.0

OBJECT-TYPE

Current date/time. If NTP is not running, or has not yet synchronized the time, this value will be 0.

OBJECT-TYPE

Synchronization Interval (in minutes)

OBJECT-IDENTITY

OBJECT-TYPE

Enable updating of firmware using DHCP vendor options

OBJECT-TYPE

Enable updating of configuration using DHCP vendor options

OBJECT-TYPE

The interface to use in contacting the FTP or TFTP server. This is required since the actual firmware load is accomplished via boot code that does not contain routing logic.

OBJECT-TYPE

The firmware filename most recently provided via DHCP options. The success/failure of actually fetching that file via TFTP is reported in ccLoadFwSuccess and ccLoadFwResult.

OBJECT-TYPE

The config filename most recently provided via DHCP options. The success/failure of actually fetching that file via TFTP is reported in ccLoadCfgSuccess and ccLoadCfgResult.

OBJECT-IDENTITY

OBJECT-TYPE

The desired state of redundancy for this switch. 'standAlone' is for a switch with no redundancy. 'redundantPrimary' and 'redundantStandby' for when the switch is desired to be part of a pair of switches for redundancy. 'redundantUpgrade' is used to update the firmware of one switch of a pair configured for redundancy. This mode is just like 'standAlone' except that switch will not adopt portals. Note that when configuring two switches, both starting in 'standAlone' state, configure the primary first. (If you configure the desired standby first, it will NOT hear heartbeats from the primary, and will quickly transition to _OperState = 'redundantPrimary').

OBJECT-TYPE

The actual state of redundancy for this switch.

OBJECT-TYPE

The interface to use in contacting the FTP or TFTP server. This is required since the actual firmware load is accomplished via boot code that does not contain routing logic.

OBJECT-TYPE

The duration in seconds between consecutive heartbeats. User can control the frequency of hearbeats by tuning this parameter.

OBJECT-TYPE

The duration which the master WS2000 shall wait before taking over from a backup WS2000.

OBJECT-TYPE

Current Operational Mode of the switch.

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-TYPE

This table allows the admin to create and store up to three certificate signature requests. The required fields are ccSelfCertsReqKeyId and ccSelfCertReqSubject.

OBJECT-TYPE

OBJECT-TYPE

Simple index.

OBJECT-TYPE

The ID for the certificate. Use this field to distinguish between certificates. This is a required field.

OBJECT-TYPE

The subject of the certificate. This is a required field.

OBJECT-TYPE

The department that is making the request. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The name of the organization or company that is making the request. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The name of the city where the organization resides. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The name of the state where the organzation resides. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The postal code (zip code in US) for the organization. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The two-letter ISO code for the country where the organization resides. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The email address to be used for identification purposes. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The domain name to associate with the certificate. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The WAN IP of the WS 2000 Wireless Switch. Contact your CA to determine whether this field is required.

OBJECT-TYPE

The signature algorithm you want used for the certificate. The options are: MD5-RSA: This option uses the Message Digest 5 algorithm in combination with RSA encryption. SHA1-RSA: This options uses the Secure Hash Algorithm 1 in combination with RSA encryption. This is a required field.

OBJECT-TYPE

The desired length of the key. Possible values are 512, 1024, and 2048. Select a lower number to enhance performance. Select a large number to enhance security.

OBJECT-TYPE

Start generating certificate request.

OBJECT-TYPE

The generated certificate request string.

OBJECT-TYPE

Row status.

OBJECT-TYPE

ID Name of the signed certificate.

OBJECT-TYPE

The signed certificate.

OBJECT-TYPE

Start importing the signed certificate from ccCertMgntSelfCertsSignedStr to a new row in ccCertMgntSelfCertsSignedTable.

OBJECT-TYPE

This table allows the admin to store up to three signed certificates. This table supports a max size of three rows.

OBJECT-TYPE

OBJECT-TYPE

Simple index.

OBJECT-TYPE

The ID for the certificate. Use this field to distinguish between certificates.

OBJECT-TYPE

The name of the certificate authority who signed the certificate.

OBJECT-TYPE

The subject of the certificate.

OBJECT-TYPE

The serial number of the certificate.

OBJECT-TYPE

The date when the certificate expires.

OBJECT-TYPE

Delete row.

OBJECT-IDENTITY

OBJECT-TYPE

The CA certificate to be imported.

OBJECT-TYPE

Start import operation for the CA certificate stored in ccCACertsStr. This operation adds a row in ccCACertsTable.

OBJECT-TYPE

This table allows the admin to store up to three CA certificates. This table supports a max size of three rows.

OBJECT-TYPE

OBJECT-TYPE

Simple index.

OBJECT-TYPE

The ID for the certificate. Use this field to distinguish between certificates.

OBJECT-TYPE

The name of the certificate authority.

OBJECT-TYPE

The subject of the certificate.

OBJECT-TYPE

The serial number of the certificate.

OBJECT-TYPE

The date when the certificate expires.

OBJECT-TYPE

Delete Row.

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-TYPE

Table of Trap Enable entries.

OBJECT-TYPE

Description.

OBJECT-TYPE

Simple Index.

OBJECT-TYPE

Name of the Trap.

OBJECT-TYPE

Enable/Disbale a particular Trap.

OBJECT-IDENTITY

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

OBJECT-TYPE

A ccCfAlmostFull trap will be sent when less than this number of bytes are remained on the Compact Flash card. The trap is currently scheduled to fire every 5 minutes when the condition is met.

OBJECT-IDENTITY

OBJECT-TYPE

Description of Firewall Under Attack.

OBJECT-TYPE

The max rate at which ccFirewallUnderAttack traps/notifications will be sent from the switch. If the switch detects a FirewallUnderAttack condition and it has NOT been at least this many seconds since the last ccFirewallUnderAttack trap/notification, this current event will NOT result in a trap/notification. If this value is set to 0, every such event results in a trap/notification. Factory-default state is 1 [second].

OBJECT-IDENTITY

OBJECT-TYPE

MAC address of the Portal that has detected Radar. (Note that this variable is accessible-for-notify only).

OBJECT-TYPE

Channel on which Radar has been detected. (Note that this variable is accessible-for-notify only).

OBJECT-IDENTITY

OBJECT-TYPE

This table configures thresholds that can be monitored for - all MUs and/or - all Portals and/or - all WLANs and/or - for the entire switch When a given threshold is crossed, it generates the appropriate corresponding notification, (ccSumStats_: _MU, _Portal, _WLAN, or _Switch). Some thresholds result in notifications when exceeded, and some when the current value sinks below the threshold. This is indicated by the wording of the entry in the entry's _Descr value. In all cases, the summary stat being monitored is the Short value, never the Long value. Note that for thresholds of type thresholdsAvgMuSignal & thresholdsAvgMuNoise, the values being 'watched' are actually negative. In these cases the threshold is specified as a Unsigned32. For example, if you wish to trap on Signal being worse than -75dBm, enter '70'. This works since a user would never want to trap on a threshold of Sinal worse than +10dBm. (SNR is not an issue, since that is a positive value). Any values reported as var-binds in the resultant trap(s) are likewise reported as positive values.

OBJECT-TYPE

The rows/instances in this table occur at the exact same indices as the corresponding monitored data occurs in the _SumStats tables. For example, row #2 / instance .2 represents the threshold(s) for the _PktsPerSec values for MU, Portal, WLAN, and Switch. If a given threshold does not make sense for one of those 4 entities, its corresponding TruthValue will be false.

OBJECT-TYPE

Index into table. Note that specific thresholds occur at specific instance values as denoted by the enumeration values assigned to this variable.

OBJECT-TYPE

Description of the threshold.

OBJECT-TYPE

Units of the the threshold.

OBJECT-TYPE

If true, the threshold can be set for MUs. If false, attempting the threshold will return a READ-ONLY.

OBJECT-TYPE

The threshold for all MUs. If 0, no threshold checking is performed.

OBJECT-TYPE

If true, the threshold can be set for Portals. If false, attempting the threshold will return a READ-ONLY.

OBJECT-TYPE

The threshold for all Portals. If 0, no threshold checking is performed.

OBJECT-TYPE

If true, the threshold can be set for Wlans. If false, attempting the threshold will return a READ-ONLY.

OBJECT-TYPE

The threshold for all Wlans. If 0, no threshold checking is performed.

OBJECT-TYPE

If true, the threshold can be set for the entire switch. If false, attempting the threshold will return a READ-ONLY.

OBJECT-TYPE

The threshold for the entire Switch. If 0, no threshold checking is performed.

OBJECT-TYPE

The minimum number of packets that must be in a window/dataset before any of the threshold traps will 'fire'.

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

(place-holder for future use and to keep the last OID of each ccTrapCtrl_ item here to match the last OID of the corresponding notification).

OBJECT-IDENTITY

OBJECT-TYPE

VLAN ID to which MU has been associated. (Note that this variable is accessible-for-notify only).

OBJECT-IDENTITY

OBJECT-TYPE

DHCP request received. (Note that this variable is accessible-for-notify only).

OBJECT-IDENTITY

OBJECT-TYPE

The actual state of redundancy for this switch.

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-TYPE

This table lists all Access Ports that contain at least one Portal that has been adopted by this WS2000.

OBJECT-TYPE

OBJECT-TYPE

Small, arbitrary integer index.

OBJECT-TYPE

MAC address of this Access Port.

OBJECT-TYPE

Model number of the Access Port.

OBJECT-TYPE

Serial Number of this Access Port.

OBJECT-TYPE

Revision of the printed circuit board for this Access Port.

OBJECT-TYPE

Revision of the boot loader code in this Access Port.

OBJECT-TYPE

Version of the WISP (AP-switch) protocol implemented by this Access Port.

OBJECT-TYPE

Version of run-time code on this Access Port.

OBJECT-TYPE

The number of Portals implemented on this Access Port.

OBJECT-TYPE

If bit <n> of this value is set, this ApTable entry 'points' to entry <n> in the Portal Table. Such a reference conveys that the Portal entry pointed-to represents a Portal contained in the Access Port represented by this entry. Note that since one Access Port can implement 1, 2, (and in the future possibly more), Portals, this 'pointer' field had to be a bit-mask.

OBJECT-IDENTITY

OBJECT-TYPE

This table lists all Portals that have been adopted or have failed adoption (by this WS2000).

OBJECT-TYPE

OBJECT-TYPE

Small, arbitrary integer index.

OBJECT-TYPE

This value is the index in the ApTable for the entry representing the Access Port that contains this Portal. Since each Portal has one and only one Access Port as 'parent', this value is a simple integer, not a bit-mask.

OBJECT-TYPE

(Reserved for future implementation).

OBJECT-TYPE

Name of this Portal, as assigned by the Web UI or CLI.

OBJECT-TYPE

Location string for this Portal, as assigned by the Web UI or CLI.

OBJECT-TYPE

This value describes the presence/absence of internal and/or external primary and/or secondary antennas.

OBJECT-TYPE

MAC address of the Portal.

OBJECT-TYPE

The number of ESSs implemented by this Portal.

OBJECT-TYPE

The number of BSSs implemented by this Portal.

OBJECT-TYPE

The number of MUs currently associated to this Portal.

OBJECT-TYPE

Radio type of the Portal.

OBJECT-TYPE

The value describes the channel the Portal is currently operating on.

OBJECT-TYPE

Output power level for the Portal.

OBJECT-TYPE

A snapshot of the WS2000's sysUpTime when this Portal was last adopted.

OBJECT-TYPE

This value describes the state of the Portal. A healthy Portal would power-on, and quickly advance from portalUpAndWaitingForConfig and then on to portalReceivingConfig and then on to portalUpAndAdopted. A Portal that is denied adoption due to ACLs would show: portalDeniedAdoptionDueToAcl. A Portal that does not 'handshake' with the switch properly would be found in state: portalBroken.

OBJECT-TYPE

Total packets received via the Portal included in all the other counters reported in this row.

OBJECT-TYPE

The best Signal value seen from the Portal so far. (Remember that a -20dBm Signal is better than -60dBm). This value is initialized to 500dBm.

OBJECT-TYPE

The worst Signal value seen from the Portal so far. (Remember that a -80dBm Signal is worse than -60dBm). This value is initialized to -500dBm.

OBJECT-TYPE

A running sum of all Signal values calculated by the switch (using reported RSSI values), for packets received via this Portal. Note that this value is normally a negative value ranging from -10dBm to -80dBm. It is possible for this value to be positive, but that would be rare, and would signal an exceptionally strong signal. (This value divided by ccPortalRxRssiNumPkts yields the average Signal value for all packets received from this Portal).

OBJECT-TYPE

A sum of the squares of each Signal value calculated for packets received via this Portal. Unlike _SignalSum, this value is never negative, since the square of a negative number is a positive. (This value can be used to calculate the standard deviation for Signal values calculated for packets from this Portal).

OBJECT-TYPE

This scalar records the MAC address of the most recent Portal to be Adopted, UnAdopted, or Denied.

OBJECT-TYPE

This value notes the reason for the most-recent Portal UnAdoption or Denial.

OBJECT-TYPE

Table describing which WLANs are eligible to adopt a new portal. The illegal MAC address value of 'FF:FF:FF:FF:FF:FF' is used in both _StartMac and _EndMac fields to indicate the special row used to declare 'default' behavior. That is, if no other row in the table applies, which WLANs are eligible to adopt the portal. This one special row cannot be deleted.

OBJECT-TYPE

OBJECT-TYPE

Table that describes which portals can be adopted by which WLANs.

OBJECT-TYPE

Starting MAC address of range of MAC addresses.

OBJECT-TYPE

Ending MAC address of range of MAC addresses.

OBJECT-TYPE

Pointer to zero or more WLANs which are eligible to adopt portals whose MAC address falls within the specified range. Any WLAN selected by this value must first be removed from the 'default' row first. Note that to make an adoption rule apply to more than one WLAN, you must create multiple rows in this table. (This is due to the way the adoption rules are stored inside the switch).

OBJECT-TYPE

Simple row status.

OBJECT-TYPE

This table includes statistics for 802.11 system packets transmitted/received at each Portal.

OBJECT-TYPE

OBJECT-TYPE

The number of Beacons sent.

OBJECT-TYPE

The number of octets sent in Beacons.

OBJECT-TYPE

The number of Probe Request packets received.

OBJECT-TYPE

The number of octets received in Probe Request packets.

OBJECT-TYPE

The number of Probe Response packets sent with no retries.

OBJECT-TYPE

The number of Probe Response packets sent with exactly 1 retry.

OBJECT-TYPE

The number of Probe Response packets sent with exactly 2 retries.

OBJECT-TYPE

The number of Probe Response packets sent with exactly 3 retries or more retries.

OBJECT-TYPE

The number of Probe Response packets that were never successfully transmitted because the max retry count was reached.

OBJECT-TYPE

The number of octets successfully transmitted in Probe Response packets. (For example, the octets in a Probe Response that is transmitted twice - one retry - only counts once in this sum).

OBJECT-TYPE

Use ccPortalSettingsTable to view and set the properties of the Access Ports.

OBJECT-TYPE

OBJECT-TYPE

Name of Access Port.

OBJECT-TYPE

Site location of Access Port.

OBJECT-TYPE

The antenna diversity setting for the access port.

OBJECT-TYPE

Enable support for Short Preamble when MUs associate with the Access Port. Enabling Short Preamble may cause incompatibility with some older clients.

OBJECT-TYPE

Eable the Uniform Spreading feature of the AP300. To comply with Dynamic Frequency Selection(DFS) requirements in the European Union, the 802.11a radio on AP300 Access Ports will come up on a random channel each time it is powered on.

OBJECT-TYPE

The Request To Send(RTS) threshold(in bytes) for use by the WLAN's adopted Access Port.

OBJECT-TYPE

Specify a beacon interval in units of 1,000 microseconds (K-us). This is a multiple of the DTIM (ccPortalCfgDefaultADtimPrd) value, for example, 100 : 10.

OBJECT-TYPE

Specify a period for the Delivery Traffic Indication Message (DTIM). This is a divisor of the beacon interval (in milliseconds), for example, 10 : 100.

OBJECT-TYPE

Enable the Secure Beacon checkbox to disallow the Access Port from broadcasting an ESSID in its beacons. This is a safeguard to prevent intruders from tapping into the WLAN. Consider this security measure for a private, corporate network.

OBJECT-TYPE

Associate a primary WLAN with the Access Port for broadcast of the Extended Service Set Identification (ESSID). The purpose of such broadcasting is to allow mobile units to identify Access Ports that are associated with the WLAN.

OBJECT-TYPE

List of basic rates for the radio.

OBJECT-TYPE

List of supported rates for the radio.

OBJECT-TYPE

Radio mode.

OBJECT-TYPE

Enable the bits for the WLANs you wish to associate the Access Port with.

OBJECT-TYPE

Description.

OBJECT-TYPE

Use ccPortalCfgRadioTable to view and set the radio properties of the Access Ports. The process can be broken down into the following steps: 1. Set ccPortalCfgRadioReset to TRUE. 2. Set ccPortalCfgRadioDesPlacement 3. Get ccPortalCfgRadioPosChannel 4. Set ccPortalCfgRadioDesChannel 5. Get ccPortalCfgRadioPosPowerLevel 6. Set ccPortalCfgRadioDesPowerLevel 7. Get ccPortalCfgRadioPowerInMW 8. Set and pull progress of ccPortalCfgRadioSet 9. Validate the configuration has been set by getting ccPortalCfgRadioPlacement ccPortalCfgRadioChannel ccPortalCfgRadioPowerLevel

OBJECT-TYPE

OBJECT-TYPE

The desired placement for radio.

OBJECT-TYPE

The possible channels that can be set when placement = ccPortalCfgRadioDesPlacement.

OBJECT-TYPE

The desired channel for radio.

OBJECT-TYPE

The max possible power level (dBm) that can be set when channel= ccPortalCfgRadioDesChannel.

OBJECT-TYPE

The desired power level (dBm) for radio.

OBJECT-TYPE

ccPortalCfgRadioDesPowerLevel in mW.

OBJECT-TYPE

Validate values in ccPortalCfgRadioDes_ fields. If it is a valid combination, configure the switch with this combination and set ccPortalCfgRadio_ to these values.

OBJECT-TYPE

Reset the following OIDs. ccPortalCfgRadioDesPlacement ccPortalCfgRadioDesChannel ccPortalCfgRadioDesPowerLevel ccPortalCfgRadioPosChannel ccPortalCfgRadioPosPowerLevel ccPortalCfgRadioPowerInMW

OBJECT-TYPE

The placement configuration for radio.

OBJECT-TYPE

The channel configuration for radio.

OBJECT-TYPE

The power level (dBm) configuration for radio.

OBJECT-TYPE

ccPortalCfgRadioPowerLevel in mW.

OBJECT-TYPE

The ccPortalSettingsDefaultsTable contains the initial settings for the Access Ports.

OBJECT-TYPE

OBJECT-TYPE

The type of the radio

OBJECT-TYPE

The antenna diversity setting for the access port.

OBJECT-TYPE

Enable support for Short Preamble when MUs associate with the Access Port. Enabling Short Preamble may cause incompatibility with some older clients.

OBJECT-TYPE

Eable the Uniform Spreading feature of the AP300. To comply with Dynamic Frequency Selection(DFS) requirements in the European Union, the 802.11a radio on AP300 Access Ports will come up on a random channel each time it is powered on.

OBJECT-TYPE

The Request To Send(RTS) threshold(in bytes) for use by the WLAN's adopted Access Port.

OBJECT-TYPE

Specify a beacon interval in units of 1,000 microseconds (K-us). This is a multiple of the DTIM (ccPortalCfgDefaultADtimPrd) value, for example, 100 : 10.

OBJECT-TYPE

Specify a period for the Delivery Traffic Indication Message (DTIM). This is a divisor of the beacon interval (in milliseconds), for example, 10 : 100.

OBJECT-TYPE

Enable the Secure Beacon checkbox to disallow the Access Port from broadcasting an ESSID in its beacons. This is a safeguard to prevent intruders from tapping into the WLAN. Consider this security measure for a private, corporate network.

OBJECT-TYPE

Associate a primary WLAN with the Access Port for broadcast of the Extended Service Set Identification (ESSID). The purpose of such broadcasting is to allow mobile units to identify Access Ports that are associated with the WLAN.

OBJECT-TYPE

List of basic rates for the radio.

OBJECT-TYPE

List of supported rates for the radio.

OBJECT-TYPE

Radio mode.

OBJECT-TYPE

The ccPortalCfgRadioDefaultTable contains the initial settings for the radio settings of the Access Ports. Please refer to descriptions in ccPortalCfgRadioTable.

OBJECT-TYPE

OBJECT-TYPE

The default desired placement for radio type.

OBJECT-TYPE

The possible channels that can be set when placement = ccPortalCfgRadioDefaultDesPlacement.

OBJECT-TYPE

The default desired channel for radio type.

OBJECT-TYPE

The max possible power level (dBm) that can be set when channel= ccPortalCfgRadioDefaultDesChannel.

OBJECT-TYPE

The desired power level (dBm) for radio.

OBJECT-TYPE

ccPortalCfgRadioDefaultDesPowerLevel in mW.

OBJECT-TYPE

Validate values in ccPortalCfgRadioDefaultDes_ fields. If it is a valid combination, configure the switch with this combination and set ccPortalCfgRadioDefault_ to these values.

OBJECT-TYPE

Reset the following OIDs. ccPortalCfgRadioDefaultDesPlacement ccPortalCfgRadioDefaultDesChannel ccPortalCfgRadioDefaultDesPowerLevel ccPortalCfgRadioDefaultPosChannel ccPortalCfgRadioDefaultPosPowerLevel ccPortalCfgRadioDefaultPowerInMW

OBJECT-TYPE

The default placement configuration for radio type.

OBJECT-TYPE

The default channel configuration for radio type.

OBJECT-TYPE

The default power level (dBm) configuration for radio type.

OBJECT-TYPE

ccPortalCfgRadioDefaultPowerLevel in mW.

OBJECT-IDENTITY

OBJECT-TYPE

802.1x Port Authentication username.

OBJECT-TYPE

802.1x Port Authentication password.

OBJECT-TYPE

Set the username and password stored in cc802dt1xPortAuthLogin and cc802dt1xPortAuthPass on all AP 300 Access Ports adopted by the switch.

OBJECT-IDENTITY

OBJECT-TYPE

This table describes general statistics about packets sent/recieved via each Portal on the switch.

OBJECT-TYPE

OBJECT-TYPE

Count of unicast packets sent via the Portal.

OBJECT-TYPE

Count of unicast packets received via the Portal.

OBJECT-TYPE

Count of non-unicast (broadcast & multicast) packets received via the Portal.

OBJECT-TYPE

Count of unicast octets sent via the Portal.

OBJECT-TYPE

Count of unicast octets received via the Portal.

OBJECT-TYPE

Count of non-unicast (broadcast & multicast) octets received via the Portal.

OBJECT-TYPE

Count of packets received via the Portal that could not be decrypted.

OBJECT-TYPE

A snapshot of the switch's sysUpTime at the time of the last activity (packet sent or received) via the Portal.

OBJECT-TYPE

For each Portal on the switch, this table describes counts of packets received at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts received via this Portal at 1 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 2 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 5.5 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 6 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 9 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 11 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 12 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 18 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 22 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 24 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 36 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 48 Mb.

OBJECT-TYPE

Number of pkts received via this Portal at 54 Mb.

OBJECT-TYPE

For each Portal on the switch, this table describes counts of packets transmitted at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts transmitted via this Portal at 1 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 2 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 5.5 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 6 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 9 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 11 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 12 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 18 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 22 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 24 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 36 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 48 Mb.

OBJECT-TYPE

Number of pkts transmitted via this Portal at 54 Mb.

OBJECT-TYPE

For each Portal on this switch, this table describes counts of octets received at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of octets received via this Portal at 1 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 2 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 5.5 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 6 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 9 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 11 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 12 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 18 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 22 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 24 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 36 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 48 Mb.

OBJECT-TYPE

Number of octets received via this Portal at 54 Mb.

OBJECT-TYPE

For each Portal on this switch, this table describes counts of octets transmitted at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number octets transmitted via this Portal at 1 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 2 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 5.5 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 6 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 9 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 11 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 12 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 18 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 22 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 24 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 36 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 48 Mb.

OBJECT-TYPE

Number octets transmitted via this Portal at 54 Mb.

OBJECT-TYPE

For each Portal on the switch, this table describes counts of the number of packets affected by transmit retries, (no retries, 1 retry, 2 retries,... gave-up).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with no retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 1 retry.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 2 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 3 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 4 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 5 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 6 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 7 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 8 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 9 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 10 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 11 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 12 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 13 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 14 retries.

OBJECT-TYPE

Number of pkts successfully transmitted via this Portal with exactly 15 retries.

OBJECT-TYPE

Number of pkts that never were successfully transmitted to via this Portal because the max retry count was exceeded.

OBJECT-TYPE

For each Portal on the switch, this table describes counts of the number of octets affected by transmit retries, (no retries, 1 retry, 2 retries,... gave-up).

OBJECT-TYPE

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with no retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 1 retry.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 2 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 3 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 4 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 5 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 6 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 7 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 8 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 9 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 10 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 11 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 12 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 13 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 14 retries.

OBJECT-TYPE

Number of octets successfully transmitted via this Portal with exactly 15 retries.

OBJECT-TYPE

Number of octets that never were successfully transmitted to via this Portal because the max retry count was exceeded.

OBJECT-TYPE

This table describes statistics about RSSI, Signal, Noise, and SNR for packets recieved via each Portal on the switch.

OBJECT-TYPE

OBJECT-TYPE

Total packets received via the Portal included in all the other counters reported in this row.

OBJECT-TYPE

The best Signal value seen from the Portal so far. (Remember that a -20dBm Signal is better than -60dBm). This value is initialized to -500dBm.

OBJECT-TYPE

The worst Signal value seen from the Portal so far. (Remember that a -80dBm Signal is worse than -60dBm). This value is initialized to 500dBm.

OBJECT-TYPE

A running sum of all Signal values calculated by the switch (using reported RSSI values), for packets received via this Portal. Note that this value is normally a negative value ranging from -10dBm to -80dBm. It is possible for this value to be positive, but that would be rare, and would signal an exceptionally strong signal. (This value divided by ccPortalSigStatsNumPkts yields the average Signal value for all packets received from this MU).

OBJECT-TYPE

A sum of the squares of each Signal value calculated for packets received via this Portal. Unlike _SignalSum, this value is never negative, since the square of a negative number is a positive. (This value can be used to calculate the standard deviation for Signal values calculated for packets from this Portal).

OBJECT-TYPE

The best Signal value seen from the Portal so far. (Remember that a -20dBm Signal is better than -60dBm). This value does not make sense when ccPortalSigStatsNumPkts equals to 0.

OBJECT-TYPE

The best Noise value seen from the Portal so far. (Remember that -80dBm Noise is better than -70dBm). This value is initialized to 500dBm.

OBJECT-TYPE

The worst Noise value seen from the Portal so far. (Remember that -50dBm Noise is worse than -60dBm). This value is initialized to -500dBm.

OBJECT-TYPE

A running sum of all Noise values calculated by the switch (using reported RSSI values), for packets received via this Portal. Like _SignalSum, this value is normally a negative value. (This value divided by ccPortalSigStatsNumPkts yields the average Noise value for all packets received from this MU).

OBJECT-TYPE

A sum of the squares of each Noise value calculated for packets received via this Portal. As with _SignalSumSquares, this value is never negative. (This value can be used to calculate the standard deviation for Noise values calculated for packets from this Portal).

OBJECT-TYPE

The best Noise value seen from the Portal so far. (Remember that -80dBm Noise is better than -70dBm). This value does not make sense when ccPortalSigStatsNumPkts equals to 0.

OBJECT-TYPE

The best SNR value seen from the Portal so far. (Remember that +30dBm SNR is better than +20dBm). This value is initialized to -500dB.

OBJECT-TYPE

The worst SNR value seen from the Portal so far. (Remember that +10dBm SNR is worse than +20dBm). This value is initialized to 500dB.

OBJECT-TYPE

A running sum of all SNR values calculated by the switch (using reported RSSI values), for packets received via this Portal. Unlike _Signal and _Noise, this value is never negative. (This value divided by ccPortalSigStatsNumPkts yields the average SNR value for all packets received from this MU).

OBJECT-TYPE

A sum of the squares of each SNR value calculated for packets received via this Portal. This value is never negative. (This value can be used to calculate the standard deviation for SNR values calculated for packets from this Portal).

OBJECT-TYPE

The best SNR value seen from the Portal so far. (Remember that +30dBm SNR is better than +20dBm). This value does not make sense when ccPortalSigStatsNumPkts equals to 0.

OBJECT-TYPE

Averages and rates calculated over the SHORT window for each Portal.

OBJECT-TYPE

OBJECT-TYPE

Snapshot of sysUpTime as of the END of the 'window' of time that this entry of values represents.

OBJECT-TYPE

The number of packets used to calculate the statistics in this window.

OBJECT-TYPE

Packets per second as averaged over the 'window'. For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries). Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Packets per second TX as averaged over the 'window'. Each packet sucessfully sent counts as 1, (not N, where N is the number of retries). Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Packets per second RX as averaged over the 'window'. Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Actual number of bits sent and received over the window, divided by the number of seconds in the window. For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries).

OBJECT-TYPE

Actual number of bits TX over the window, divided by the number of seconds in the window. Each packet sucessfully sent counts as 1, (not N, where N is the number of retries).

OBJECT-TYPE

Actual number of bits RX over the window, divided by the number of seconds in the window.

OBJECT-TYPE

An octet-weighted average of the speeds of all packets sent/received. (For each possible speed, multiply the number of octets sent/received by that speed; divide the sum by the total number of octets; multiply by 8). For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries). This can be said in more plain english as: the average bit-speed at which packets were sent/received.

OBJECT-TYPE

The average of all signal values over the window. NOTE: dBm are normally negative. Here the NEGATIVE values are reported as POSITIVE values. PO

OBJECT-TYPE

The average of all noise values over the window.

OBJECT-TYPE

The average of all SNR values over the window.

OBJECT-TYPE

Ratio of packets that were NOT unicast. Expressed as parts-per-10000.

OBJECT-TYPE

Ratio of TX packets that experienced one or more retries. Expressed as parts-per-10000.

OBJECT-TYPE

Ratio of TX packets that were dropped due to excessive. Expressed as parts-per-10000.

OBJECT-TYPE

For all transmit packets (those that experienced some retries, those that were successfully transmitted with only 1 transmission, and those that attempted max times and gave-up), the average number of RE-transmission attempts. Said another (though identical) way: the sum of all tranmission attempts divided by the number of unique packets attempted to be sent. Since SNMP does not convey decimal values, the result above is multiplied by 100. If there were no RE-transmissions, this value would be 0. If every single packet required exactly two tranmissions, this value would be 100, (representing 1.00).

OBJECT-TYPE

Ratio of RX packets that were undecryptable. Expressed as parts-per-10000.

OBJECT-TYPE

The total number of MUs associated to the given Portal.

OBJECT-TYPE

The approximate utilization of the Portal's RF port. Calculated as Throughput divided by AvgBitSpeed. Expressed as parts-per-10000.

OBJECT-TYPE

Averages and rates calculated over the LONG window for each Portal. (Refer to ccPortalSumStatsShortTable for descriptions).

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-IDENTITY

OBJECT-TYPE

This table contains one entry for each Portal-MU association.

OBJECT-TYPE

OBJECT-TYPE

A snapshot of the switch's sysUpTime at the time of the first time this MU associated to this Portal.

OBJECT-TYPE

A snapshot of the switch's sysUpTime at the time of the time this MU most recently associated to this Portal.

OBJECT-TYPE

A count of the total number of times this MU has associated to this Portal.

OBJECT-IDENTITY

OBJECT-TYPE

This table describes general information about each MU serviced by the switch.

OBJECT-TYPE

OBJECT-TYPE

MAC address of the MU.

OBJECT-TYPE

(Reserved for future implementation).

OBJECT-TYPE

The name of the WLAN this MU is associated to.

OBJECT-TYPE

This value is true if the WS2000 is ready to forward/switch packets to/from this MU, (internally called the 'data ready' state). Otherwise this value is false.

OBJECT-TYPE

The index of the entry in the PortalTable to which this MU is associated.

OBJECT-TYPE

The MAC address of the Portal to which this MU is associated.

OBJECT-TYPE

If true, this MU supports Symbol's Rogue AP detection assist algorithm.

OBJECT-TYPE

IP address of the MU.

OBJECT-TYPE

Type of the MU.

OBJECT-TYPE

Radio type of the MU.

OBJECT-TYPE

A bit-mask of rates supported by this MU.

OBJECT-TYPE

Power-mode implemented by the MU. A MU's status will constantly switch between PSP and CAM mode when it is in PSP mode.

OBJECT-TYPE

Authentication method implemented by the MU.

OBJECT-TYPE

Encryption method implemented by the MU.

OBJECT-TYPE

The VLAN that this MU is assigned to.

OBJECT-TYPE

This table describes general statistics about packets sent/recieved via each MU serviced by the switch.

OBJECT-TYPE

OBJECT-TYPE

Count of unicast packets sent.

OBJECT-TYPE

Count of unicast packets received.

OBJECT-TYPE

Count of non-unicast (broadcast & multicast) packets received.

OBJECT-TYPE

Count of unicast octets sent.

OBJECT-TYPE

Count of unicast octets received.

OBJECT-TYPE

Count of non-unicast (broadcast & multicast) octets received.

OBJECT-TYPE

Count of packets received that could not be decrypted.

OBJECT-TYPE

Total RSSI packets received.

OBJECT-TYPE

A running sum of all RSSI values calculated by the switch for packets.

OBJECT-TYPE

A sum of the squares of each RSSI value calculated for packets received. This value is never negative.

OBJECT-TYPE

The best RSSI value seen so far. (Remember that -80dBm Noise is better than -70dBm). This value does not make sense when ccMuRxRssiNumPkts equals to 0.

OBJECT-TYPE

A snapshot of the switch's sysUpTime at the time of the last activity (packet sent or received).

OBJECT-TYPE

For each MU serviced by the switch, this table describes counts of packets received at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts received at 1 Mb.

OBJECT-TYPE

Number of pkts received at 2 Mb.

OBJECT-TYPE

Number of pkts received at 5.5 Mb.

OBJECT-TYPE

Number of pkts received at 6 Mb.

OBJECT-TYPE

Number of pkts received at 9 Mb.

OBJECT-TYPE

Number of pkts received at 11 Mb.

OBJECT-TYPE

Number of pkts received at 12 Mb.

OBJECT-TYPE

Number of pkts received at 18 Mb.

OBJECT-TYPE

Number of pkts received at 22 Mb.

OBJECT-TYPE

Number of pkts received at 24 Mb.

OBJECT-TYPE

Number of pkts received at 36 Mb.

OBJECT-TYPE

Number of pkts received at 48 Mb.

OBJECT-TYPE

Number of pkts received at 54 Mb.

OBJECT-TYPE

For each MU serviced by the switch, this table describes counts of packets transmitted at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts transmitted at 1 Mb.

OBJECT-TYPE

Number of pkts transmitted at 2 Mb.

OBJECT-TYPE

Number of pkts transmitted at 5.5 Mb.

OBJECT-TYPE

Number of pkts transmitted at 6 Mb.

OBJECT-TYPE

Number of pkts transmitted at 9 Mb.

OBJECT-TYPE

Number of pkts transmitted at 11 Mb.

OBJECT-TYPE

Number of pkts transmitted at 12 Mb.

OBJECT-TYPE

Number of pkts transmitted at 18 Mb.

OBJECT-TYPE

Number of pkts transmitted at 22 Mb.

OBJECT-TYPE

Number of pkts transmitted at 24 Mb.

OBJECT-TYPE

Number of pkts transmitted at 36 Mb.

OBJECT-TYPE

Number of pkts transmitted at 48 Mb.

OBJECT-TYPE

Number of pkts transmitted at 54 Mb.

OBJECT-TYPE

For each MU serviced by this switch, this table describes counts of octets received at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of octets received at 1 Mb.

OBJECT-TYPE

Number of octets received at 2 Mb.

OBJECT-TYPE

Number of octets received at 5.5 Mb.

OBJECT-TYPE

Number of octets received at 6 Mb.

OBJECT-TYPE

Number of octets received at 9 Mb.

OBJECT-TYPE

Number of octets received at 11 Mb.

OBJECT-TYPE

Number of octets received at 12 Mb.

OBJECT-TYPE

Number of octets received at 18 Mb.

OBJECT-TYPE

Number of octets received at 22 Mb.

OBJECT-TYPE

Number of octets received at 24 Mb.

OBJECT-TYPE

Number of octets received at 36 Mb.

OBJECT-TYPE

Number of octets received at 48 Mb.

OBJECT-TYPE

Number of octets received at 54 Mb.

OBJECT-TYPE

For each MU serviced by this switch, this table describes counts of octets transmitted at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of octets transmitted at 1 Mb.

OBJECT-TYPE

Number of octets transmitted at 2 Mb.

OBJECT-TYPE

Number of octets transmitted at 5.5 Mb.

OBJECT-TYPE

Number of octets transmitted at 6 Mb.

OBJECT-TYPE

Number of octets transmitted at 9 Mb.

OBJECT-TYPE

Number of octets transmitted at 11 Mb.

OBJECT-TYPE

Number of octets transmitted at 12 Mb.

OBJECT-TYPE

Number of octets transmitted at 18 Mb.

OBJECT-TYPE

Number of octets transmitted at 22 Mb.

OBJECT-TYPE

Number of octets transmitted at 24 Mb.

OBJECT-TYPE

Number of octets transmitted at 36 Mb.

OBJECT-TYPE

Number of octets transmitted at 48 Mb.

OBJECT-TYPE

Number of octets transmitted at 54 Mb.

OBJECT-TYPE

For each MU serviced by the switch, this table describes counts of the number of packets affected by transmit retries, (no retries, 1 retry, 2 retries,... gave-up).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts successfully transmitted with no retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 1 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 2 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 3 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 4 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 5 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 6 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 7 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 8 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 9 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 10 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 11 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 12 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 13 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 14 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 15 retries.

OBJECT-TYPE

Number of pkts that never were successfully transmitted to because the max retry count was exceeded.

OBJECT-TYPE

A total sum of all retries across all packets sent to this MU. For example, if 4 packets have been sent, with the following number of retires: 2, 0, 5, gave-up, this value would be 2+0+5+16 = 23.

OBJECT-TYPE

Most recent retry done by MU.

OBJECT-TYPE

This scalar records the MAC address of the most recent MU to be Adopted, UnAdopted, or Denied.

OBJECT-TYPE

This value notes the reason for the most-recent MU UnAdoption or Denial. Enum item associationFailed indicates that a key association field was missing, or a mismatch of supported rates, etc.

OBJECT-TYPE

This value notes the reason for the most-recent MU UnAdoption or Denial.

OBJECT-IDENTITY

OBJECT-TYPE

For each MU serviced by the switch, this table describes counts of the number of octets affected by transmit retries, (no retries, 1 retry, 2 retries,... gave-up).

OBJECT-TYPE

OBJECT-TYPE

Number of octets successfully transmitted with no retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 1 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 2 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 3 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 4 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 5 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 6 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 7 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 8 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 9 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 10 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 11 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 12 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 13 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 14 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 15 retries.

OBJECT-TYPE

Number of octets that never were successfully transmitted to because the max retry count was exceeded.

OBJECT-TYPE

This table describes statistics about RSSI, Signal, Noise, and SNR for packets recieved via each MU serviced by the switch.

OBJECT-TYPE

OBJECT-TYPE

Total packets received included in all the other counters reported in this row.

OBJECT-TYPE

The best Signal value seen so far. (Remember that a -20dBm Signal is better than -60dBm). This value is initialized to -500dBm.

OBJECT-TYPE

The worst Signal value seen so far. (Remember that a -80dBm Signal is worse than -60dBm). This value is initialized to 500dBm.

OBJECT-TYPE

A running sum of all Signal values calculated by the switch (using reported RSSI values), for packets received. Note that this value is normally a negative value ranging from -10dBm to -80dBm. It is possible for this value to be positive, but that would be rare, and would signal an exceptionally strong signal.

OBJECT-TYPE

A sum of the squares of each Signal value calculated for packets received. Unlike _SignalSum, this value is never negative, since the square of a negative number is a positive.

OBJECT-TYPE

The best Signal value seen so far. (Remember that a -20dBm Signal is better than -60dBm). This value does not make sense when ccMuSigStatsNumPkts equals to 0.

OBJECT-TYPE

The best Noise value seen so far. (Remember that -80dBm Noise is better than -70dBm). This value is initialized to 500dBm.

OBJECT-TYPE

The worst Noise value seen so far. (Remember that -50dBm Noise is worse than -60dBm). This value is initialized to -500dBm.

OBJECT-TYPE

A running sum of all Noise values calculated by the switch (using reported RSSI values), for packets. Like _SignalSum, this value is normally a negative value.

OBJECT-TYPE

A sum of the squares of each Noise value calculated for packets received. As with _SignalSumSquares, this value is never negative.

OBJECT-TYPE

The best Noise value seen so far. (Remember that -80dBm Noise is better than -70dBm). This value does not make sense when ccMuSigStatsNumPkts equals to 0.

OBJECT-TYPE

The best SNR value seen so far. (Remember that +30dBm SNR is better than +20dBm). This value is initialized to -500dB.

OBJECT-TYPE

The worst SNR value seen so far. (Remember that +10dBm SNR is worse than +20dBm). This value is initialized to 500dB.

OBJECT-TYPE

A running sum of all SNR values calculated by the switch (using reported RSSI values), for packets received. Unlike _Signal and _Noise, this value is never negative.

OBJECT-TYPE

A sum of the squares of each SNR value calculated for packets received. This value is never negative.

OBJECT-TYPE

The best SNR value seen so far. (Remember that +30dBm SNR is better than +20dBm). This value does not make sense when ccMuSigStatsNumPkts equals to 0.

OBJECT-TYPE

Averages and rates calculated over the SHORT window for each MU.

OBJECT-TYPE

OBJECT-TYPE

Snapshot of sysUpTime as of the END of the 'window' of time that this entry of values represents.

OBJECT-TYPE

The number of packets used to calculate the statistics in this window.

OBJECT-TYPE

Packets per second as averaged over the 'window'. For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries). Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Packets per second TX as averaged over the 'window'. Each packet sucessfully sent counts as 1, (not N, where N is the number of retries). Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Packets per second RX as averaged over the 'window'. Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Actual number of bits sent and received over the window, divided by the number of seconds in the window. For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries).

OBJECT-TYPE

Actual number of bits TX over the window, divided by the number of seconds in the window. Each packet sucessfully sent counts as 1, (not N, where N is the number of retries).

OBJECT-TYPE

Actual number of bits RX over the window, divided by the number of seconds in the window.

OBJECT-TYPE

An octet-weighted average of the speeds of all packets sent/received. (For each possible speed, multiply the number of octets sent/received by that speed; divide the sum by the total number of octets; multiply by 8). For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries). This can be said in more plain english as: the average bit-speed at which packets were sent/received.

OBJECT-TYPE

The average of all signal values over the window. NOTE: dBm are normally negative. Here the NEGATIVE values are reported as POSITIVE values. PO

OBJECT-TYPE

The average of all noise values over the window.

OBJECT-TYPE

The average of all SNR values over the window.

OBJECT-TYPE

Ratio of packets that were NOT unicast. Expressed as parts-per-10000.

OBJECT-TYPE

Ratio of TX packets that experienced one or more retries. Expressed as parts-per-10000.

OBJECT-TYPE

Packets dropped divided by packets sent. Dropped here means dropped intentionally due to the appropriate QoS queue being full. Other reasons for dropped packets are not counted in this ratio. Calculated as an average for all WLANs implemented on this MU.

OBJECT-TYPE

For all transmit packets (those that experienced some retries, those that were successfully transmitted with only 1 transmission, and those that attempted max times and gave-up), the average number of RE-transmission attempts. Said another (though identical) way: the sum of all tranmission attempts divided by the number of unique packets attempted to be sent. Since SNMP does not convey decimal values, the result above is multiplied by 100. If there were no RE-transmissions, this value would be 0. If every single packet required exactly two tranmissions, this value would be 100, (representing 1.00).

OBJECT-TYPE

Ratio of RX packets that were undecryptable. Expressed as parts-per-10000.

OBJECT-TYPE

Averages and rates calculated over the LONG window for each MU. (Refer to ccMuSumStatsShortTable for descriptions).

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-TYPE

OBJECT-IDENTITY

OBJECT-TYPE

Table of wireless LANs configured on the switch.

OBJECT-TYPE

OBJECT-TYPE

Simple index. (In the ccRfSum tables, entry 1001 is used to represent the roll-up of all RF communications on this switch).

OBJECT-TYPE

Name of the WLAN.

OBJECT-TYPE

ESSID of the WLAN.

OBJECT-TYPE

The subnet/LAN this WLAN is associated with. If not associated with any subnet/LAN, this value will be 0.

OBJECT-TYPE

Pointer to portal(s) adopted by this WLAN.

OBJECT-TYPE

Row enable.

OBJECT-TYPE

Set to true to prohibit MU-to-MU communication.

OBJECT-TYPE

Enable voice prioritization.

OBJECT-TYPE

Answer broadcast ESS.

OBJECT-TYPE

Multicast address 1.

OBJECT-TYPE

Multicast address 2.

OBJECT-TYPE

Describes the default behavior if none of this WLAN's ccWlanMuAclTable entries match the MAC address of an MU attempting to associate with this WLAN.

OBJECT-TYPE

If auth802dot1xEap, additional EAP settings for this WLAN will be used from the matching entry in the ccWlanAuthEapTable. Likewise, if authKerberos, use the settings in the matching entry in the ccWlanAuthKerberosTable.

OBJECT-TYPE

If cryptoWep40 or cryptoWep128, additional WEP settings for this WLAN will be used from the matching entry in the ccWlanCryptoWepTable. Likewise, if cryptoWpaTkip, use the settings in the matching entry in the ccWlanCryptoWpaTable. Likewise, if cryptoKeyguardMcm, use the settings in the matching entry in the ccWlanCryptoKeyguardTable.

OBJECT-TYPE

The weight to be used when QoS for all WLANs is set to weighted-round-robin. Note that the sum of all weights across all WLANs need not total 100.

OBJECT-IDENTITY

OBJECT-TYPE

Table of EAP authentication settings for each WLAN.

OBJECT-TYPE

OBJECT-TYPE

Enable reauthentication.

OBJECT-TYPE

Reauthentication period.

OBJECT-TYPE

Reauthentication max retries.

OBJECT-TYPE

IP address of the primary RADIUS server.

OBJECT-TYPE

Port number of the primary RADIUS server.

OBJECT-TYPE

Shared secret of the primary RADIUS server.

OBJECT-TYPE

IP address of the secondary RADIUS server.

OBJECT-TYPE

Port number of the secondary RADIUS server.

OBJECT-TYPE

Shared secret of the secondary RADIUS server.

OBJECT-TYPE

MU quiet period.

OBJECT-TYPE

MU timeout.

OBJECT-TYPE

MU Tx period.

OBJECT-TYPE

MU max retries.

OBJECT-TYPE

Server timeout.

OBJECT-TYPE

Server max retries.

OBJECT-TYPE

Radius Accounting Mode.

OBJECT-TYPE

Radius Accounting MU Timeout.

OBJECT-TYPE

Radius Accounting MU Retries.

OBJECT-TYPE

Logging Mode.

OBJECT-TYPE

Syslog Server IP Address.

OBJECT-TYPE

Table of Kerberos authentication settings for each WLAN.

OBJECT-TYPE

OBJECT-TYPE

Realm name.

OBJECT-TYPE

Username.

OBJECT-TYPE

Password.

OBJECT-TYPE

Primary KDC server IP addr.

OBJECT-TYPE

Primary KDC port.

OBJECT-TYPE

Backup KDC server IP addr.

OBJECT-TYPE

Backup KDC port.

OBJECT-TYPE

Remote KDC server IP addr.

OBJECT-TYPE

Remote KDC port.

OBJECT-IDENTITY

OBJECT-TYPE

Table of WEP encryption settings for each WLAN.

OBJECT-TYPE

OBJECT-TYPE

Pass key. If this value is written, the four WepKey1..4 will be overwritten.

OBJECT-TYPE

WEP key #1 exactly 13 octets for WEP-128 (104-bit key); exactly 5 octets for WEP-64 (40-bit key).

OBJECT-TYPE

WEP key #2 exactly 13 octets for WEP-128 (104-bit key); exactly 5 octets for WEP-64 (40-bit key).

OBJECT-TYPE

WEP key #3 exactly 13 octets for WEP-128 (104-bit key); exactly 5 octets for WEP-64 (40-bit key).

OBJECT-TYPE

WEP key #4 exactly 13 octets for WEP-128 (104-bit key); exactly 5 octets for WEP-64 (40-bit key).

OBJECT-TYPE

Specifies which WEP key to use.

OBJECT-TYPE

Table of WPA-TKIP encryption settings for each WLAN.

OBJECT-TYPE

OBJECT-TYPE

Use broadcast key rotation.

OBJECT-TYPE

Broadcast key rotation, (if enabled), occurs every this many seconds.

OBJECT-TYPE

Specifies which key to use.

OBJECT-TYPE

Passphrase.

OBJECT-TYPE

Key.

OBJECT-TYPE

Table of KeyGuard-MCM encryption settings for each WLAN.

OBJECT-TYPE

OBJECT-TYPE

Pass key.

OBJECT-TYPE

Key #1.

OBJECT-TYPE

Key #2.

OBJECT-TYPE

Key #3.

OBJECT-TYPE

Key #4.

OBJECT-TYPE

Specifies which WEP key to use.

OBJECT-TYPE

Table of WPA-CCMP encryption settings for each WLAN.

OBJECT-TYPE

Description.

OBJECT-TYPE

Use broadcast key rotation.

OBJECT-TYPE

Broadcast key rotation, (if enabled), occurs every this many seconds.

OBJECT-TYPE

Specifies which key to use.

OBJECT-TYPE

Passphrase.

OBJECT-TYPE

Key.

OBJECT-TYPE

WPA2-CCMP Mixed Mode enables WPA2-CCMP and WPA-TKIP Clients to operate simultaneously on the network. Enabling this option allows backwards compatiblity for clients that support WPA-TKIP but do not support WPA2-CCMP.

OBJECT-TYPE

Enabling this option enables a client associated with one Access Port to carry out an 802.1x authentication with another Access Port before it roams over to it. The WS2000 will cache the keying information of the client until it roams to the new Access Port. This enables the roaming the client to start sending and receiving data sooner by not having to do 802.1x authentication after it roams. Note: This option only works when 802.1x authentication is enabled for the WLAN.

OBJECT-TYPE

This option enables the WS2000 to use a Pairwise Master Key (PMK) derived with a client on one Access Port, with the same client when it roams over to another Access Port. Upon roaming the client does not have to do 802.1x authentication and can start sending/receiving data sooner. Note: This option only works when 802.1x authentication is enabled for the WLAN.

OBJECT-TYPE

Table describing ACLs for allowing or denying, (depending on default behavior for the WLAN specified in ccWlanMuAclDefault), MU association with each WLAN.

OBJECT-TYPE

OBJECT-TYPE

Simple index.

OBJECT-TYPE

Starting MAC address in a range of addresses.

OBJECT-TYPE

Ending MAC address in a range of addresses.

OBJECT-TYPE

Row status.

OBJECT-TYPE

This variable configures the manner in which bandwidth is shared among the WLANs. Only in mode 'weightedRoundRobin' are the ccWlanWeight values for each WLAN used.

OBJECT-TYPE

Table of QOS values.

OBJECT-TYPE

Description.

OBJECT-TYPE

Packets Sent.

OBJECT-TYPE

Packets Dropped.

OBJECT-IDENTITY

OBJECT-TYPE

This table describes general statistics about packets sent/recieved via each WLAN on the switch.

OBJECT-TYPE

OBJECT-TYPE

Count of unicast packets sent.

OBJECT-TYPE

Count of unicast packets received.

OBJECT-TYPE

Count of non-unicast (broadcast & multicast) packets received.

OBJECT-TYPE

Count of unicast octets sent.

OBJECT-TYPE

Count of unicast octets received.

OBJECT-TYPE

Count of non-unicast (broadcast & multicast) octets received.

OBJECT-TYPE

Count of packets received that could not be decrypted.

OBJECT-TYPE

A snapshot of the switch's sysUpTime at the time of the last activity (packet sent or received).

OBJECT-TYPE

For each WLAN on the switch, this table describes counts of packets received at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts received at 1 Mb.

OBJECT-TYPE

Number of pkts received at 2 Mb.

OBJECT-TYPE

Number of pkts received at 5.5 Mb.

OBJECT-TYPE

Number of pkts received at 6 Mb.

OBJECT-TYPE

Number of pkts received at 9 Mb.

OBJECT-TYPE

Number of pkts received at 11 Mb.

OBJECT-TYPE

Number of pkts received at 12 Mb.

OBJECT-TYPE

Number of pkts received at 18 Mb.

OBJECT-TYPE

Number of pkts received at 22 Mb.

OBJECT-TYPE

Number of pkts received at 24 Mb.

OBJECT-TYPE

Number of pkts received at 36 Mb.

OBJECT-TYPE

Number of pkts received at 48 Mb.

OBJECT-TYPE

Number of pkts received at 54 Mb.

OBJECT-TYPE

For each MU serviced by the switch, this table describes counts of packets transmitted at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts transmitted at 1 Mb.

OBJECT-TYPE

Number of pkts transmitted at 2 Mb.

OBJECT-TYPE

Number of pkts transmitted at 5.5 Mb.

OBJECT-TYPE

Number of pkts transmitted at 6 Mb.

OBJECT-TYPE

Number of pkts transmitted at 9 Mb.

OBJECT-TYPE

Number of pkts transmitted at 11 Mb.

OBJECT-TYPE

Number of pkts transmitted at 12 Mb.

OBJECT-TYPE

Number of pkts transmitted at 18 Mb.

OBJECT-TYPE

Number of pkts transmitted at 22 Mb.

OBJECT-TYPE

Number of pkts transmitted at 24 Mb.

OBJECT-TYPE

Number of pkts transmitted at 36 Mb.

OBJECT-TYPE

Number of pkts transmitted at 48 Mb.

OBJECT-TYPE

Number of pkts transmitted at 54 Mb.

OBJECT-TYPE

For each MU serviced by this switch, this table describes counts of octets received at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of octets received at 1 Mb.

OBJECT-TYPE

Number of octets received at 2 Mb.

OBJECT-TYPE

Number of octets received at 5.5 Mb.

OBJECT-TYPE

Number of octets received at 6 Mb.

OBJECT-TYPE

Number of octets received at 9 Mb.

OBJECT-TYPE

Number of octets received at 11 Mb.

OBJECT-TYPE

Number of octets received at 12 Mb.

OBJECT-TYPE

Number of octets received at 18 Mb.

OBJECT-TYPE

Number of octets received at 22 Mb.

OBJECT-TYPE

Number of octets received at 24 Mb.

OBJECT-TYPE

Number of octets received at 36 Mb.

OBJECT-TYPE

Number of octets received at 48 Mb.

OBJECT-TYPE

Number of octets received at 54 Mb.

OBJECT-TYPE

For each WLAN on this switch, this table describes counts of octets transmitted at each possible speed, (1Mb, 2Mb, 5.5Mb, 6Mb...).

OBJECT-TYPE

OBJECT-TYPE

Number of octets transmitted at 1 Mb.

OBJECT-TYPE

Number of octets transmitted at 2 Mb.

OBJECT-TYPE

Number of octets transmitted at 5.5 Mb.

OBJECT-TYPE

Number of octets transmitted at 6 Mb.

OBJECT-TYPE

Number of octets transmitted at 9 Mb.

OBJECT-TYPE

Number of octets transmitted at 11 Mb.

OBJECT-TYPE

Number of octets transmitted at 12 Mb.

OBJECT-TYPE

Number of octets transmitted at 18 Mb.

OBJECT-TYPE

Number of octets transmitted at 22 Mb.

OBJECT-TYPE

Number of octets transmitted at 24 Mb.

OBJECT-TYPE

Number of octets transmitted at 36 Mb.

OBJECT-TYPE

Number of octets transmitted at 48 Mb.

OBJECT-TYPE

Number of octets transmitted at 54 Mb.

OBJECT-TYPE

For each WLAN on the switch, this table describes counts of the number of packets affected by transmit retries, (no retries, 1 retry, 2 retries,... gave-up).

OBJECT-TYPE

OBJECT-TYPE

Number of pkts successfully transmitted with no retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 1 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 2 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 3 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 4 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 5 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 6 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 7 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 8 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 9 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 10 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 11 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 12 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 13 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 14 retries.

OBJECT-TYPE

Number of pkts successfully transmitted with exactly 15 retries.

OBJECT-TYPE

Number of pkts that never were successfully transmitted to because the max retry count was exceeded.

OBJECT-TYPE

For each WLAN on the switch, this table describes counts of the number of octets affected by transmit retries, (no retries, 1 retry, 2 retries,... gave-up).

OBJECT-TYPE

OBJECT-TYPE

Number of octets successfully transmitted with no retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 1 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 2 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 3 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 4 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 5 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 6 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 7 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 8 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 9 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 10 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 11 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 12 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 13 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 14 retries.

OBJECT-TYPE

Number of octets successfully transmitted with exactly 15 retries.

OBJECT-TYPE

Number of octets that never were successfully transmitted to because the max retry count was exceeded.

OBJECT-TYPE

This table describes statistics about RSSI, Signal, Noise, and SNR for packets recieved via each WLAN on the switch.

OBJECT-TYPE

OBJECT-TYPE

Total packets received included in all the other counters reported in this row.

OBJECT-TYPE

The best Signal value seen so far. (Remember that a -20dBm Signal is better than -60dBm). This value is initialized to -500dBm.

OBJECT-TYPE

The worst Signal value seen so far. (Remember that a -80dBm Signal is worse than -60dBm). This value is initialized to 500dBm.

OBJECT-TYPE

A running sum of all Signal values calculated by the switch (using reported RSSI values), for packets received. Note that this value is normally a negative value ranging from -10dBm to -80dBm. It is possible for this value to be positive, but that would be rare, and would signal an exceptionally strong signal.

OBJECT-TYPE

A sum of the squares of each Signal value calculated for packets received. Unlike _SignalSum, this value is never negative, since the square of a negative number is a positive.

OBJECT-TYPE

The best Noise value seen so far. (Remember that -80dBm Noise is better than -70dBm). This value is initialized to 500dBm.

OBJECT-TYPE

The worst Noise value seen so far. (Remember that -50dBm Noise is worse than -60dBm). This value is initialized to -500dBm.

OBJECT-TYPE

A running sum of all Noise values calculated by the switch (using reported RSSI values), for packets. Like _SignalSum, this value is normally a negative value.

OBJECT-TYPE

A sum of the squares of each Noise value calculated for packets received. As with _SignalSumSquares, this value is never negative.

OBJECT-TYPE

The best SNR value seen so far. (Remember that +30dBm SNR is better than +20dBm). This value is initialized to -500dB.

OBJECT-TYPE

The worst SNR value seen so far. (Remember that +10dBm SNR is worse than +20dBm). This value is initialized to 500dB.

OBJECT-TYPE

A running sum of all SNR values calculated by the switch (using reported RSSI values), for packets received. Unlike _Signal and _Noise, this value is never negative.

OBJECT-TYPE

A sum of the squares of each SNR value calculated for packets received. This value is never negative.

OBJECT-TYPE

Averages and rates calculated over the SHORT window for each WLAN.

OBJECT-TYPE

OBJECT-TYPE

Snapshot of sysUpTime as of the END of the 'window' of time that this entry of values represents.

OBJECT-TYPE

The number of packets used to calculate the statistics in this window.

OBJECT-TYPE

Packets per second as averaged over the 'window'. For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries). Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Packets per second TX as averaged over the 'window'. Each packet sucessfully sent counts as 1, (not N, where N is the number of retries). Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Packets per second RX as averaged over the 'window'. Since SNMP does not convey decimal values, the result is multiplied by 100.

OBJECT-TYPE

Actual number of bits sent and received over the window, divided by the number of seconds in the window. For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries).

OBJECT-TYPE

Actual number of bits TX over the window, divided by the number of seconds in the window. Each packet sucessfully sent counts as 1, (not N, where N is the number of retries).

OBJECT-TYPE

Actual number of bits RX over the window, divided by the number of seconds in the window.

OBJECT-TYPE

An octet-weighted average of the speeds of all packets sent/received. (For each possible speed, multiply the number of octets sent/received by that speed; divide the sum by the total number of octets; multiply by 8). For transmitted packets, each packet sucessfully sent counts as 1, (not N, where N is the number of retries). This can be said in more plain english as: the average bit-speed at which packets were sent/received.

OBJECT-TYPE

The average of all signal values over the window. NOTE: dBm are normally negative. Here the NEGATIVE values are reported as POSITIVE values. PO

OBJECT-TYPE

The average of all noise values over the window.

OBJECT-TYPE

The average of all SNR values over the window.

OBJECT-TYPE

Ratio of packets that were NOT unicast. Expressed as parts-per-10000.

OBJECT-TYPE

Ratio of TX packets that experienced one or more retries. Expressed as parts-per-10000.

OBJECT-TYPE

Packets dropped divided by packets sent. Dropped here means dropped intentionally due to the appropriate QoS queue being full. Other reasons for dropped packets are not counted in this ratio.

OBJECT-TYPE

For all transmit packets (those that experienced some retries, those that were successfully transmitted with only 1 transmission, and those that attempted max times and gave-up), the average number of RE-transmission attempts. Said another (though identical) way: the sum of all tranmission attempts divided by the number of unique packets attempted to be sent. Since SNMP does not convey decimal values, the result above is multiplied by 100. If there were no RE-transmissions, this value would be 0. If every single packet required exactly two tranmissions, this value would be 100, (representing 1.00).

OBJECT-TYPE

Ratio of RX packets that were undecryptable. Expressed as parts-per-10000.

OBJECT-TYPE

The number of packets used to calculate the statistics in this window for all MUs associated with WLAN.