2014-06-26
Download AIRESPACE-WIRELESS-MIB.txt Open AIRESPACE-WIRELESS-MIB.txt in a new tab
This MIB is intended to be implemented on all those devices operating as Central Controllers (CC) that terminate the Light Weight Access Point Protocol tunnel from Light-weight LWAPP Access Points. This MIB provides configuration and status information for 802.11 Access Points, LAN configuration, AAA, Mobility, IpSec, Radio Rescouce Management and 802.11 global parameters. The relationship between controller and the LWAPP APs can be depicted as follows: +......+ +......+ +......+ +......+ + + + + + + + + + CC + + CC + + CC + + CC + + + + + + + + + +......+ +......+ +......+ +......+ .. . . . .. . . . . . . . . . . . . . . . . . . . . . . . +......+ +......+ +......+ +......+ +......+ + + + + + + + + + + + AP + + AP + + AP + + AP + + AP + + + + + + + + + + + +......+ +......+ +......+ +......+ +......+ . . . . . . . . . . . . . . . . . . . . . . . . +......+ +......+ +......+ +......+ +......+ + + + + + + + + + + + MN + + MN + + MN + + MN + + MN + + + + + + + + + + + +......+ +......+ +......+ +......+ +......+ The LWAPP tunnel exists between the controller and the APs. The MNs communicate with the APs through the protocol defined by the 802.11 standard. LWAPP APs, upon bootup, discover and join one of the controllers and the controller pushes the configuration, that includes the WLAN parameters, to the LWAPP APs. The APs then encapsulate all the 802.11 frames from wireless clients inside LWAPP frames and forward the LWAPP frames to the controller. GLOSSARY Access Point ( AP ) An entity that contains an 802.11 medium access control ( MAC ) and physical layer ( PHY ) interface and provides access to the distribution services via the wireless medium for associated clients. LWAPP APs encapsulate all the 802.11 frames in LWAPP frames and sends it to the controller to which it is logically connected. Basic Service Set Identifier (BSSID) The identifier for the service set comprising of all the 802.11 stations under the control of one coordinating Access Point. This identifier happens to be the MAC address of the dot11 radio interface of the Access Point. The wireless clients that associate with the Access Point get the wired uplink through this particular dot11 interface. Central Controller ( CC ) The central entity that terminates the LWAPP protocol tunnel from the LWAPP APs. Throughout this MIB, this entity also referred to as 'controller'. Light Weight Access Point Protocol ( LWAPP ) This is a generic protocol that defines the communication between the Access Points and the Central Controller. Mobile Node ( MN ) A roaming 802.11 wireless device in a wireless network associated with an access point. Station Management (SMT) This term refers to the internal management of the 802.11 protocol operations by the AP to work cooperatively with the other APs and 802.11 devices in the network. REFERENCE [1] Part 11 Wireless LAN Medium Access Control ( MAC ) and Physical Layer ( PHY ) Specifications. [2] Draft-obara-capwap-lwapp-00.txt, IETF Light Weight Access Point Protocol.
SCALARS (341) · TABLES (67) · TRAPS (82)
END OF TOC
1.3.6.1.4.1.14179.2.3.1.1
INTEGER0 = notimplemented1 = implemented · Integer32
This attribute, when true, shall indicate that the IEEE 802.11 WEP option is implemented. The default value of this attribute shall be false.
1.3.6.1.4.1.14179.2.3.1.2
Unsigned32 (5..60)
This attribute shall specify the number of TU that a responding STA should wait for the next frame in the authentication sequence.
1.3.6.1.4.1.14179.2.3.1.3
INTEGER0 = no1 = yes · Integer32
This attribute, when TRUE, indicates that the station implementation is capable of supporting multiple regulatory domains. The capability is disabled, otherwise. The default value of this attribute is FALSE.
1.3.6.1.4.1.14179.2.3.1.4
INTEGER0 = no1 = yes · Integer32
This attribute, when TRUE, indicates that the capability of the station to operate in multiple regulatory domains is enabled. The capability is disabled, otherwise. The default value of this attribute is FALSE.
1.3.6.1.4.1.14179.2.3.1.5
INTEGER1 = usa2 = canada3 = france4 = japan5 = mexico6 = spain7 = usalegacy8 = korearepublic9 = australia10 = austria11 = belgium12 = denmark13 = finland14 = germany15 = greece16 = ireland17 = italy18 = luxembourg19 = netherlands20 = portugal21 = sweden22 = unitedkingdom23 = none24 = india25 = hongkong26 = switzerland27 = iceland28 = norway29 = singapore30 = thailand31 = taiwan33 = cyprus34 = czechrepublic35 = estonia36 = hungary37 = lithuania38 = latvia39 = malaysia40 = newzealand41 = poland42 = slovenia43 = slovakrepublic44 = southafrica45 = usachan16546 = israel47 = israelOutdoor48 = argentina49 = brazil51 = saudiArabia52 = turkey53 = indonesia54 = china55 = koreaExtended56 = japan257 = gibraltar58 = liechtenstein59 = malta60 = monaco61 = romania62 = russianfederation63 = chile64 = colombia65 = panama66 = peru67 = venezuela68 = philippines · Integer32
This attribute identifies the country in which the station is operating.
1.3.6.1.4.1.14179.2.3.1.6
INTEGER0 = disable1 = enable · Integer32
This attribute specifies if load balancing of clients is enabled on disabled. Global configuration of Load Balancing is now removed. Use cLWlanLoadBalancingEnable to configure it per WLAN.
1.3.6.1.4.1.14179.2.3.1.7
Integer32 (120..3600)
This attribute specifies in seconds, the time interval after which a Rogue Entry in Rogue Table will expire if no beacon is heard from a Rogue.
1.3.6.1.4.1.14179.2.3.1.8
INTEGER0 = disable1 = enable · Integer32
This attribute specifies if this Switch acts a Master Switch for the Airespace APs. So if an Airespace AP doesn't find its Primary Switch, it will associate with this Switch.
1.3.6.1.4.1.14179.2.3.1.9
INTEGER0 = nopriority1 = highpriority · Integer32
Real Time Protocol Priority.
1.3.6.1.4.1.14179.2.3.1.10
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
This attribute will display the Current System time on the Switch.
1.3.6.1.4.1.14179.2.3.1.11
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..32) · OCTET STRING · hint 255a
Use this attribute to change the System time on the Switch. Specify the new time in this Format MM/DD/YYYY HH:MM:SS
1.3.6.1.4.1.14179.2.3.1.12
INTEGER1 = commercial2 = industrial0 = unknown · Integer32
Operating Environment of the Airespace Switch. commercial is Commercial (0 to 40 C) and industrial is Industrial (-10 to 70 C)
1.3.6.1.4.1.14179.2.3.1.13
Integer32
Current Internal Temperature of the unit in Centigrade
1.3.6.1.4.1.14179.2.3.1.14
Integer32
Internal Temperature Alarm Low Limit in Centigrade. If the bsnSensorTemperature goes below this limit bsnSensedTemperatureTooLow Alarm will be sent out
1.3.6.1.4.1.14179.2.3.1.15
Integer32
Internal Temperature Alarm High Limit in Centigrade. If the bsnSensorTemperature goes above this limit bsnSensedTemperatureTooHigh Alarm will be sent out
1.3.6.1.4.1.14179.2.3.1.16
IpAddress SIZE (4)
Virtual Gateway Address of the Switch. This is used by web auth and Ipsec. If the virtual IP Address is changed, the Switch has to be rebooted for the new Address to take effect. This is now replaced by the Virtual Interface in bsnswitching MIB.
1.3.6.1.4.1.14179.2.3.1.17
OCTET STRING SIZE (0..32)
RF Mobility Group Name to which this Airespace Switch belongs. Airespace Switches on a network form a RF Group as well as a Mobility Group. RF Groups does the channel and power management of AP while Mobility Group does load balancing and hand off for clients.
1.3.6.1.4.1.14179.2.3.1.18
INTEGER0 = disable1 = enable · Integer32
This flag should be turned on for the client watch lists to be enabled on the switch. When enabled, the switch generates Client Association and Authentication traps for the watchlisted clients.
1.3.6.1.4.1.14179.2.3.1.19
INTEGER0 = disable1 = allAPs2 = monitorAPOnly · Integer32
This flag should be turned on to enable the Rogue Location Discovery Protocol feature on the switch. We can either enable this feature for all the APs or only for APs in monitor mode.
1.3.6.1.4.1.14179.2.3.1.20
INTEGER0 = disable1 = enable · Integer32
This flag should be turned on to allow the switch to contain the rogues automatically if detected on the wired network.
1.3.6.1.4.1.14179.2.3.1.21
INTEGER0 = disable1 = enable · Integer32
Over the Air Provisioning Mode for APs
1.3.6.1.4.1.14179.2.3.1.22
Integer32 (0..8)
This attribute specifies the maximum number of concurrent logins that the switch will allow for a single user. A value 0 implies that there is no restriction on the number of concurrent logins with a single username.
1.3.6.1.4.1.14179.2.3.1.23
INTEGER0 = alarmOnly1 = contain · Integer32
This flag should be set to 1 to allow the switch to contain automatically those rogues that are advertising our SSID. If value is 0, only an alarm will be generated when such a rogue is detected.
1.3.6.1.4.1.14179.2.3.1.24
INTEGER0 = alarmOnly1 = contain · Integer32
This flag should be set to 1 to allow the switch to contain automatically the adhoc networks detected by the switch. If value is 0, only an alarm will be generated when such a network is detected.
1.3.6.1.4.1.14179.2.3.1.25
INTEGER0 = alarmOnly1 = contain · Integer32
This flag should be set to 1 to allow the switch to contain automatically those trusted clients that are associated to rogue APs. If value is 0, only an alarm will be generated when such a client is detected.
1.3.6.1.4.1.14179.2.3.1.26
INTEGER0 = disable1 = enable · Integer32
This flag should be turned on to allow the switch to validate 'valid' mobiles associating with rogue APs. For example, if a client's MAC Address is found in the local MAC filter table, that client can be validated.
1.3.6.1.4.1.14179.2.3.1.27
Integer32
The delta (difference) between the local time and the Universal Coordinated Time in hours. For example, it is -8 for the PST and +1 for France. If the delta is -5.30 then this attribute will store -5 and bsnSystemTimezoneDeltaMinutes will store 30. This value i should be between -23 to +23
1.3.6.1.4.1.14179.2.3.1.28
INTEGER0 = disable1 = enable · Integer32
This flag specifies if daylight savings are enabled for the current timezone.
1.3.6.1.4.1.14179.2.3.1.29
INTEGER0 = disable1 = enable · Integer32
This flag specifies if LWAPP is allowed to get authorization via RADIUS or local database for an AP.
1.3.6.1.4.1.14179.2.3.1.30
Integer32
The minutes component of delta (difference) between the local time and the Universal Coordinated Time.
1.3.6.1.4.1.14179.2.3.1.31
INTEGER0 = disable1 = enable · Integer32
This flag specifies if the APs should continue LWAPP discoveries to fallback to the primary switch in case they are not already associated with it i.e they are associated with their respective secondary or tertiary switch instead.
1.3.6.1.4.1.14179.2.3.1.32
INTEGER0 = disable1 = enable · Integer32
This flag turns on the appletalk bridging in the switch such that the packets from Apple clients that use appletalk format can be processed by the switch. When this flag is off, these packets are dropped.
1.3.6.1.4.1.14179.2.3.1.40.1
INTEGER0 = alarmOnly1 = contain · Integer32
This flag should be turned on to allow the switch to contain misconfigured APs.
1.3.6.1.4.1.14179.2.3.1.40.2
INTEGER0 = none1 = open2 = wep3 = wpa · Integer32
The encryption policy that is enforced on the trusted APs.
1.3.6.1.4.1.14179.2.3.1.40.3
INTEGER0 = none1 = short2 = long · Integer32
The preamble policy that is enforced on the trusted APs.
1.3.6.1.4.1.14179.2.3.1.40.4
INTEGER0 = none1 = dcfOnly2 = pcfOnly · Integer32
The 802.11 Mode policy that is enforced on the trusted APs.
1.3.6.1.4.1.14179.2.3.1.40.5
INTEGER0 = none1 = aOnly2 = bOnly3 = bgOnly · Integer32
The radio type policy that is enforced on the trusted APs.
1.3.6.1.4.1.14179.2.3.1.40.6
INTEGER0 = disable1 = enable · Integer32
If enabled, the SSID of trusted APs will be validated by the switch.
1.3.6.1.4.1.14179.2.3.1.40.7
INTEGER0 = disable1 = enable · Integer32
If enabled, an alert will be generated when a trusted AP is missing.
1.3.6.1.4.1.14179.2.3.1.40.8
Integer32 (120..3600)
This attribute specifies in seconds, the time interval after which a Trusted AP Entry will expire if no beacon is heard from that AP.
1.3.6.1.4.1.14179.2.3.1.41.1
INTEGER0 = disable1 = enable · Integer32
This flag specifies if client should be excluded (blacklisted) if repeated 802.11 Association Failures occurs with a client.
1.3.6.1.4.1.14179.2.3.1.41.2
INTEGER0 = disable1 = enable · Integer32
This flag specifies if client should be excluded (blacklisted) if repeated 802.11 Authentication Failures occurs with a client.
1.3.6.1.4.1.14179.2.3.1.41.3
INTEGER0 = disable1 = enable · Integer32
This flag specifies if client should be excluded (blacklisted) if repeated 802.1x Authentication Failures occurs with a client.
1.3.6.1.4.1.14179.2.3.1.41.4
INTEGER0 = disable1 = enable · Integer32
This flag specifies if client should be excluded (blacklisted) if repeated external policy server failures occurs with a client.
1.3.6.1.4.1.14179.2.3.1.41.5
INTEGER0 = disable1 = enable · Integer32
This flag specifies if client should be excluded (blacklisted) if repeated Web Authentication Failures occurs with a client.
1.3.6.1.4.1.14179.2.3.1.41.6
INTEGER0 = disable1 = enable · Integer32
This flag specifies if client should be excluded (blacklisted) if it appears to be reusing an IP Address.(Possible IP Theft)
1.3.6.1.4.1.14179.2.3.1.42.5
INTEGER0 = disable1 = enable · Integer32
This flag should be enabled to enforce check of all standard and custom signatures. If disabled, there will be no check for signatures, both custom and standard, by the switch.
1.3.6.1.4.1.14179.2.3.1.43.1
INTEGER0 = disable1 = enable · Integer32
This flag should be turned on to allow the switch to collect data for tags.
1.3.6.1.4.1.14179.2.3.1.43.2
Unsigned32 (60..7200)
This is the number of seconds after which the tag data is deleted by the switch from its database if it didn't hear from the tag again.
1.3.6.1.4.1.14179.2.3.1.43.3
INTEGER0 = disable1 = enable · Integer32
This flag should be turned on to allow auto deletion of tag data in the switch after expiration of Tag Data Timeout
1.3.6.1.4.1.14179.2.3.1.44.1
INTEGER0 = disable1 = enable · Integer32
This flag should be turned on to allow the AP-Neighbor Authentication feature.
1.3.6.1.4.1.14179.2.3.1.44.2
INTEGER (1..255) · Integer32
Authentication alarm trigger threshold.
1.3.6.1.4.1.14179.2.3.1.45
OCTET STRING SIZE (0..19)
RF Network Group Name to which this Airespace Switch belongs. Airespace Switches on a network form a RF Network Group as well as a Mobility Group. RF Network Groups does the channel and power management of AP while Mobility Group does load balancing and hand off for clients.
1.3.6.1.4.1.14179.2.3.1.46
INTEGER0 = disable1 = enable · Integer32
Configures Fast SSID changing feature for mobile-stations. When enabled, permits mobile-stations to change SSIDs without having to block and wait for SSID-cleanup on the switch to occur.
1.3.6.1.4.1.14179.2.3.1.47.1
INTEGER0 = disable1 = enable · Integer32
If enabled, allows new bridging APs to negotiate with the switch to acquire the shared secret key.
1.3.6.1.4.1.14179.2.3.1.47.2
OCTET STRING SIZE (0..32)
Key that is used to negotiate a secure LWAPP connection between a switch and a bridging or mesh AP.
1.3.6.1.4.1.14179.2.3.1.48
INTEGER0 = disable1 = enable · Integer32
This flag specifies if controller will accept Self Signed Certificate from AP as part of authorization.
1.3.6.1.4.1.14179.2.3.1.49
Unsigned32 · seconds
This object represents the current clock time of the controller and expressed as the number of seconds elapsed since 00:00:00 on January 1, 1970, Coordinated Universal Time (UTC).
1.3.6.1.4.1.14179.2.3.2.1.1
INTEGER0 = disable1 = enable · Integer32
802.11b Network Admin Status.
1.3.6.1.4.1.14179.2.3.2.1.2
INTEGER (20..1000) · Integer32
This attribute shall specify the number of TU that a AP Radio shall use for scheduling Beacon tranmissions. This value is transmitted in Beacon and Probe Response frames.
1.3.6.1.4.1.14179.2.3.2.1.3
INTEGER1 = automatic2 = runOnce3 = static · Integer32
Dynamic channel assignment(DCA) has three modes. When the mode is auto, the channel assignment will be periodically updated for all Airespace APs that permit this operation. When the DCA is runOnce, channel assignments are updated based on the UPDATE_CMD received from the management. When the DCA is static, no dynamic channel assignments occurs and value are set to their global default. Default is auto.
1.3.6.1.4.1.14179.2.3.2.1.4
INTEGER (1..14) · Integer32
The current operating frequency channel of the DSSS PHY. Valid channel numbers are as defined in 15.4.6.2. This attribute will be read-only if bsnAPIfPhyChannelAutomaticOn is true.
1.3.6.1.4.1.14179.2.3.2.1.5
Unsigned32
When Channel dynamic alogirthm is running, this interval (in secs) specifies how often Channel assignement updates are attempted on an Airespace AP. NOTE: hysteresis is built into the algorithms so we will not have uproductive changes occuring. Default value is 600 secs
1.3.6.1.4.1.14179.2.3.2.1.6
Unsigned32
This attribute is a bit mask specifying what to include in DCA optimization.Below is a list of parameters and their corresponding bits identifiers. options bit -------------------------------------- none 0 SIGNAL STRENGTH 1 NOISE 2 FOREIGN INTERFERENCE 4 LOAD 8 DEVICE INTERFERENCE 32 Default value is 63( all bits on).
1.3.6.1.4.1.14179.2.3.2.1.7
INTEGER0 = default1 = activate · Integer32
When set to activate this starts a DCA calculation regardless of the dynamic update interval. This command should be invoke on Group Leader Airespace Switch.Invoking on a Airespace Switch which is not a Group leader has no effect.
1.3.6.1.4.1.14179.2.3.2.1.8
Integer32
After setting bsnGlobalDot11bChannelUpdateCmdInvoke to activate, the result of action can be monitored from here. It takes 5 minutes for the command to complete.
1.3.6.1.4.1.14179.2.3.2.1.9
INTEGER1 = automatic2 = runOnce3 = static · Integer32
Dynamic transmit power (DTP) has three modes. When the mode is auto, the transmit power of each Airespace AP will be periodically updated for all Airespace APs that permit this operation. When the DTP is runOnce,transmit power update will occur based on the UPDATE_CMD received from the management. When the DTP is static, no dynamic transmit power updates occur and their global defaults are used. Default is auto.
1.3.6.1.4.1.14179.2.3.2.1.10
Unsigned32
When Tx PowerControl dynamic alogirthm is running, this interval(in secs) specifies how often TxPower control updates are attempted on an Airespace AP. NOTE: hysteresis is build into the algorithms so we will not have uproductive changes occuring. Default value is 600 secs
1.3.6.1.4.1.14179.2.3.2.1.11
INTEGER (0..5) · Integer32
The TxPowerLevel N currently being used to transmit data. Some PHYs also use this value to determine the receiver sensitivity requirements for CCA.
1.3.6.1.4.1.14179.2.3.2.1.12
Unsigned32
This attribute is a bit mask specifying what to include in DCA optimization.Below is a list of parameters and their corresponding bits identifiers. options bit -------------------------------------- none 0 LOAD 1 SIGNAL STRENGTH 2 FOREIGN INTERFERENCE 4 NOISE 8 Default value is 15( all bits on).
1.3.6.1.4.1.14179.2.3.2.1.13
INTEGER0 = default1 = activate · Integer32
When set to activate this starts a DTP calculation regardless of the dynamic update interval. This command should be invoke on Group Leader Airespace Switch.Invoking on a Airespace Switch which is not a Group leader has no effect.
1.3.6.1.4.1.14179.2.3.2.1.14
Integer32
After setting bsnGlobalDot11aChannelUpdateCmdInvoke to activate, the result of action can be monitored from here. It takes 5 minutes for the command to complete.
1.3.6.1.4.1.14179.2.3.2.1.15
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.2.1.16
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.2.1.17
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.2.1.18
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.2.1.19
INTEGER0 = disable1 = enable · Integer32
802.11b Short Preamble.
1.3.6.1.4.1.14179.2.3.2.1.20
INTEGER0 = disable1 = enable · Integer32
This attribute is enabled to also support 802.11g protocol on the 802.11b network. Enabling 802.11g allows additional data rates: 6, 9, 12, 18, 24, 36, 48, 54 Mbps.
1.3.6.1.4.1.14179.2.3.2.1.21
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.22
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.23
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.24
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.25
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.26
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.27
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.28
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled. This is configurable only if 802.11g support is enabled.
1.3.6.1.4.1.14179.2.3.2.1.29
INTEGER1 = enable0 = disable · Integer32
Configures the 802.11b pico-cell mode. This cannot be enabled when the Fast Roaming Mode is enabled.
1.3.6.1.4.1.14179.2.3.2.1.30
INTEGER0 = disable1 = enable · Integer32
Configures the 802.11b fast-roaming mode. This cannot be enabled when the Pico Cell Mode is enabled.
1.3.6.1.4.1.14179.2.3.2.1.31
INTEGER0 = undefined1 = rate1Mbps2 = rate2Mbps3 = rate5andHalfMbps4 = rate11Mbps · Integer32
Configures the minimum transmission rate allowed for VoIP on any 802.11b radio.
1.3.6.1.4.1.14179.2.3.2.1.32
INTEGER1 = zero2 = twentyfive3 = fifty4 = seventyfive5 = hundred · Integer32
Configures the percentage of effective bandwidth for the minimum rate reserved for VoIP.
1.3.6.1.4.1.14179.2.3.2.1.33
INTEGER (0..100) · Integer32
This represents the maximum bandwidth allocated to 802.11e clients. It is expressed as percentage of the total bandwidth of 802.11b network. The value of this attribute can vary from 0 to 100.
1.3.6.1.4.1.14179.2.3.2.1.34
INTEGER0 = disable1 = enable · Integer32
This attribute may be used to enable the DTPC support on all 802.11b/g radios. DTPC or Dynamic Transmit Power Control support means that the radio's transmit power will be advertised in the beacons and probe responses.
1.3.6.1.4.1.14179.2.3.2.2.1
INTEGER (0..1000) · Integer32
This attribute shall indicate the maximum amount of time, in TU, that a point coordinator may control the usage of the wireless medium without relinquishing control for long enough to allow at least one instance of DCF access to the medium. The default value of this attribute shall be 100, and the maximum value shall be 1000.
1.3.6.1.4.1.14179.2.3.2.2.2
INTEGER (0..255) · Integer32
The attribute shall describe the number of DTIM intervals between the start of CFPs. It is modified by MLME-START.request primitive.
1.3.6.1.4.1.14179.2.3.2.2.3
INTEGER (0..65535) · Integer32
The attribute shall describe the maximum duration of the CFP in TU that may be generated by the PCF. It is modified by MLME-START.request primitive.
1.3.6.1.4.1.14179.2.3.2.2.5
INTEGER0 = no1 = yes · Integer32
When this attribute is true, it shall indicate that the STA is able to respond to a CF-Poll with a data frame within a SIFS time. This attribute shall be false if the STA is not able to respond to a CF-Poll with a data frame within a SIFS time.
1.3.6.1.4.1.14179.2.3.2.2.6
INTEGER0 = no1 = yes · Integer32
Specifies wheather CFP
1.3.6.1.4.1.14179.2.3.2.2.7
INTEGER (1..255) · Integer32
This attribute shall specify the number of beacon intervals that shall elapse between transmission of Beacons frames containing a TIM element whose DTIM Count field is 0. This value is transmitted in the DTIM Period field of Beacon frames.
1.3.6.1.4.1.14179.2.3.2.2.8
Integer32
This attribute shall indicate the maximum transmit power, in dBm, allowed in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.3.2.2.9
Integer32
This attribute shall indicate the value of the lowest channel number in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.3.2.2.10
Integer32
This attribute shall indicate the value of the total number of channels allowed in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.3.2.2.11
INTEGER (0..2347) · Integer32
This attribute shall indicate the number of octets in an MPDU, below which an RTS/CTS handshake shall not be performed. An RTS/CTS handshake shall be performed at the beginning of any frame exchange sequence where the MPDU is of type Data or Management, the MPDU has an individual address in the Address1 field, and the length of the MPDU is greater than this threshold. (For additional details, refer to Table 21 in 9.7.) Setting this attribute to be larger than the maximum MSDU size shall have the effect of turning off the RTS/CTS handshake for frames of Data or Management type transmitted by this STA. Setting this attribute to zero shall have the effect of turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by this STA. The default value of this attribute shall be 2347.
1.3.6.1.4.1.14179.2.3.2.2.12
INTEGER (1..255) · Integer32
This attribute shall indicate the maximum number of transmission attempts of a frame, the length of which is less than or equal to bsnGlobalDot11RTSThreshold, that shall be made before a failure condition is indicated. The default value of this attribute shall be 7.
1.3.6.1.4.1.14179.2.3.2.2.13
INTEGER (1..255) · Integer32
This attribute shall indicate the maximum number of transmission attempts of a frame, the length of which is greater than bsnGlobalDot11RTSThreshold, that shall be made before a failure condition is indicated. The default value of this attribute shall be 4.
1.3.6.1.4.1.14179.2.3.2.2.14
INTEGER (256..2346) · Integer32
This attribute shall specify the current maximum size, in octets, of the MPDU that may be delivered to the PHY. An MSDU shall be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers. An MSDU or MMPDU shall be fragmented when the resulting frame has individual address in the Address1 field, and the length of the frame is larger than this threshold. The default value for this attribute shall be the lesser of 2346 or the aMPDUMaxLength of the attached PHY and shall never exceed the lesser of 2346 or the aMPDUMaxLength of the attached PHY. The value of this attribute shall never be less than 256.
1.3.6.1.4.1.14179.2.3.2.2.15
Unsigned32 (1..4294967295)
The MaxTransmitMSDULifetime shall be the elapsed time in TU, after the initial transmission of an MSDU, after which further attempts to transmit the MSDU shall be terminated. The default value of this attribute shall be 512.
1.3.6.1.4.1.14179.2.3.2.2.16
Unsigned32 (1..4294967295)
The MaxReceiveLifetime shall be the elapsed time in TU, after the initial reception of a fragmented MMPDU or MSDU, after which further attempts to reassemble the MMPDU or MSDU shall be terminated. The default value shall be 512.
1.3.6.1.4.1.14179.2.3.2.2.17
Integer32
The current Energy Detect Threshold being used by the DSSS PHY.
1.3.6.1.4.1.14179.2.3.2.2.18
INTEGER0 = no1 = yes · Integer32
This attribute indicates that the PHY channel agility functionality is enabled.
1.3.6.1.4.1.14179.2.3.2.2.19
INTEGER0 = no1 = yes · Integer32
This attribute, when true, shall indicate that the PBCC modulation option as defined in subclause 18.4.6.6 is implemented. The default value of this attribute shall be false.
1.3.6.1.4.1.14179.2.3.2.2.20
INTEGER0 = no1 = yes · Integer32
This attribute, when true, shall indicate that the short preamble option as defined in subclause 18.2.2.2 is implemented. The default value of this attribute shall be false.
1.3.6.1.4.1.14179.2.3.3.1.1
INTEGER0 = disable1 = enable · Integer32
Dot11a Network Status
1.3.6.1.4.1.14179.2.3.3.1.2
INTEGER0 = disable1 = enable · Integer32
Dot11a Low Band Network Status
1.3.6.1.4.1.14179.2.3.3.1.3
INTEGER0 = disable1 = enable · Integer32
Dot11a Mid Band Network Status
1.3.6.1.4.1.14179.2.3.3.1.4
INTEGER0 = disable1 = enable · Integer32
Dot11a High Band Network Status
1.3.6.1.4.1.14179.2.3.3.1.5
INTEGER (20..1000) · Integer32
This attribute shall specify the number of TU that a AP Radio shall use for scheduling Beacon tranmissions. This value is transmitted in Beacon and Probe Response frames.
1.3.6.1.4.1.14179.2.3.3.1.6
INTEGER1 = automatic2 = runOnce3 = static · Integer32
Dynamic channel assignment(DCA) has three modes. When the mode is auto, the channel assignment will be periodically updated for all Airespace APs that permit this operation. When the DCA is runOnce, channel assignments are updated based on the UPDATE_CMD received from the management. When the DCA is static, no dynamic channel assignments occurs and value are set to their global default. Default is auto.
1.3.6.1.4.1.14179.2.3.3.1.7
INTEGER (0..99) · Integer32
The number of the current operating frequency channel of the OFDM PHY.
1.3.6.1.4.1.14179.2.3.3.1.8
Unsigned32
When Channel dynamic alogirthm is running, this interval(in secs) specifies how often Channel assignement updates are attempted on an Airespace AP. NOTE: hysteresis is build into the algorithms so we will not have uproductive changes occuring. Default value is 600 secs
1.3.6.1.4.1.14179.2.3.3.1.9
Unsigned32
This attribute is a bit mask specifying what to include in DCA optimization.Below is a list of parameters and their corresponding bits identifiers. options bit -------------------------------------- none 0 SIGNAL STRENGTH 1 NOISE 2 FOREIGN INTERFERENCE 4 LOAD 8 DEVICE INTERFERENCE 32 Default value is 63( all bits on).
1.3.6.1.4.1.14179.2.3.3.1.10
INTEGER0 = default1 = activate · Integer32
When set to activate this starts a DCA calculation regardless of the dynamic update interval. This command should be invoke on Group Leader Airespace Switch.Invoking on a Airespace Switch which is not a Group leader has no effect.
1.3.6.1.4.1.14179.2.3.3.1.11
Integer32
After setting bsnGlobalDot11aChannelUpdateCmdInvoke to activate, the result of action can be monitored from here. It takes 5 minutes for the command to complete.
1.3.6.1.4.1.14179.2.3.3.1.12
INTEGER1 = automatic2 = runOnce3 = static · Integer32
Dynamic transmit power (DTP) has three modes. When the mode is auto, the transmit power of each Airespace AP will be periodically updated for all Airespace APs that permit this operation. When the DTP is runOnce,transmit power update will occur based on the UPDATE_CMD received from the management. When the DTP is static, no dynamic transmit power updates occur and their global defaults are used. Default is auto.
1.3.6.1.4.1.14179.2.3.3.1.13
INTEGER (0..5) · Integer32
The TxPowerLevel N currently being used to transmit data. Some PHYs also use this value to determine the receiver sensitivity requirements for CCA.
1.3.6.1.4.1.14179.2.3.3.1.14
Unsigned32
When Tx PowerControl dynamic alogirthm is running, this interval(in secs) specifies how often TxPower control updates are attempted on an Airespace AP. NOTE: hysteresis is build into the algorithms so we will not have uproductive changes occuring. Default value is 600 secs
1.3.6.1.4.1.14179.2.3.3.1.15
Unsigned32
This attribute is a bit mask specifying what to include in DCA optimization.Below is a list of parameters and their corresponding bits identifiers. options bit -------------------------------------- none 0 LOAD 1 SIGNAL STRENGTH 2 FOREIGN INTERFERENCE 4 NOISE 8 Default value is 15( all bits on).
1.3.6.1.4.1.14179.2.3.3.1.16
INTEGER0 = default1 = activate · Integer32
When set to activate this starts a DTP calculation regardless of the dynamic update interval. This command should be invoke on Group Leader Airespace Switch.Invoking on a Airespace Switch which is not a Group leader has no effect.
1.3.6.1.4.1.14179.2.3.3.1.17
Integer32
After setting bsnGlobalDot11aChannelUpdateCmdInvoke to activate, the result of action can be monitored from here. It takes 5 minutes for the command to complete.
1.3.6.1.4.1.14179.2.3.3.1.19
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.20
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.21
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.22
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.23
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.24
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.25
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.26
INTEGER1 = supported2 = mandatory0 = disabled · Integer32
Specify if this rate is supported or mandatory or disabled
1.3.6.1.4.1.14179.2.3.3.1.27
INTEGER1 = enable0 = disable · Integer32
Configures the 802.11a pico-cell mode. This cannot be enabled when the Fast Roaming Mode is enabled.
1.3.6.1.4.1.14179.2.3.3.1.28
INTEGER0 = disable1 = enable · Integer32
Configures the 802.11a fast-roaming mode. This cannot be enabled when the Pico Cell Mode is enabled.
1.3.6.1.4.1.14179.2.3.3.1.29
INTEGER0 = undefined1 = rate1Mbps2 = rate2Mbps3 = rate5andHalfMbps4 = rate11Mbps · Integer32
Configures the minimum transmission rate allowed for VoIP on any 802.11a radio.
1.3.6.1.4.1.14179.2.3.3.1.30
INTEGER1 = zero2 = twentyfive3 = fifty4 = seventyfive5 = hundred · Integer32
Configures the percentage of effective bandwidth for the minimum rate reserved for VoIP.
1.3.6.1.4.1.14179.2.3.3.1.31
INTEGER (0..100) · Integer32
This represents the maximum bandwidth allocated to 802.11e clients. It is expressed as percentage of the total bandwidth of 802.11a network. The value of this attribute can vary from 0 to 100.
1.3.6.1.4.1.14179.2.3.3.1.32
INTEGER0 = disable1 = enable · Integer32
This attribute may be used to enable the DTPC support on all 802.11a radios. DTPC or Dynamic Transmit Power Control support means that the radio's transmit power will be advertised in the beacons and probe responses.
1.3.6.1.4.1.14179.2.3.3.2.1
INTEGER (0..1000) · Integer32
This attribute shall indicate the maximum amount of time, in TU, that a point coordinator may control the usage of the wireless medium without relinquishing control for long enough to allow at least one instance of DCF access to the medium. The default value of this attribute shall be 100, and the maximum value shall be 1000.
1.3.6.1.4.1.14179.2.3.3.2.2
INTEGER (0..255) · Integer32
The attribute shall describe the number of DTIM intervals between the start of CFPs. It is modified by MLME-START.request primitive.
1.3.6.1.4.1.14179.2.3.3.2.3
INTEGER (0..65535) · Integer32
The attribute shall describe the maximum duration of the CFP in TU that may be generated by the PCF. It is modified by MLME-START.request primitive.
1.3.6.1.4.1.14179.2.3.3.2.5
INTEGER0 = no1 = yes · Integer32
When this attribute is true, it shall indicate that the STA is able to respond to a CF-Poll with a data frame within a SIFS time. This attribute shall be false if the STA is not able to respond to a CF-Poll with a data frame within a SIFS time.
1.3.6.1.4.1.14179.2.3.3.2.6
INTEGER0 = no1 = yes · Integer32
Specifies whether CFP
1.3.6.1.4.1.14179.2.3.3.2.7
INTEGER (1..255) · Integer32
This attribute shall specify the number of beacon intervals that shall elapse between transmission of Beacons frames containing a TIM element whose DTIM Count field is 0. This value is transmitted in the DTIM Period field of Beacon frames.
1.3.6.1.4.1.14179.2.3.3.2.8
Integer32
This attribute shall indicate the maximum transmit power, in dBm, allowed in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.3.3.2.9
Integer32
This attribute shall indicate the value of the lowest channel number in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.3.3.2.10
Integer32
This attribute shall indicate the value of the total number of channels allowed in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.3.3.2.11
INTEGER (0..2347) · Integer32
This attribute shall indicate the number of octets in an MPDU, below which an RTS/CTS handshake shall not be performed. An RTS/CTS handshake shall be performed at the beginning of any frame exchange sequence where the MPDU is of type Data or Management, the MPDU has an individual address in the Address1 field, and the length of the MPDU is greater than this threshold. (For additional details, refer to Table 21 in 9.7.) Setting this attribute to be larger than the maximum MSDU size shall have the effect of turning off the RTS/CTS handshake for frames of Data or Management type transmitted by this STA. Setting this attribute to zero shall have the effect of turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by this STA. The default value of this attribute shall be 2347.
1.3.6.1.4.1.14179.2.3.3.2.12
INTEGER (1..255) · Integer32
This attribute shall indicate the maximum number of transmission attempts of a frame, the length of which is less than or equal to bsnGlobalDot11RTSThreshold, that shall be made before a failure condition is indicated. The default value of this attribute shall be 7.
1.3.6.1.4.1.14179.2.3.3.2.13
INTEGER (1..255) · Integer32
This attribute shall indicate the maximum number of transmission attempts of a frame, the length of which is greater than bsnGlobalDot11RTSThreshold, that shall be made before a failure condition is indicated. The default value of this attribute shall be 4.
1.3.6.1.4.1.14179.2.3.3.2.14
INTEGER (256..2346) · Integer32
This attribute shall specify the current maximum size, in octets, of the MPDU that may be delivered to the PHY. An MSDU shall be broken into fragments if its size exceeds the value of this attribute after adding MAC headers and trailers. MSDU or MMPDU shall be fragmented when the resulting frame has an individual address in the Address1 field, and the length of the frame is larger than this threshold. The default value for this attribute shall be the lesser of 2346 or the aMPDUMaxLength of the attached PHY and shall never exceed the lesser of 2346 or the aMPDUMaxLength of the attached PHY. The value of this attribute shall never be less than 256.
1.3.6.1.4.1.14179.2.3.3.2.15
Unsigned32 (1..4294967295)
The MaxTransmitMSDULifetime shall be the elapsed time in TU, after the initial transmission of an MSDU, after which further attempts to transmit the MSDU shall be terminated. The default value of this attribute shall be 512.
1.3.6.1.4.1.14179.2.3.3.2.16
Unsigned32 (1..4294967295)
The MaxReceiveLifetime shall be the elapsed time in TU, after the initial reception of a fragmented MMPDU or MSDU, after which further attempts to reassemble the MMPDU or MSDU shall be terminated. The default value shall be 512.
1.3.6.1.4.1.14179.2.3.3.2.17
Integer32
The Threshold being used to detect a busy medium (frequency). CCA shall report a busy medium upon detecting the RSSI above this threshold.
1.3.6.1.4.1.14179.2.3.3.2.18
INTEGER0 = no1 = yes · Integer32
This attribute indicates that the PHY channel agility functionality is enabled.
1.3.6.1.4.1.14179.2.3.4.1.1
INTEGER (0..30) · Integer32 · decibels
Local maximum transmit power for a channel is defined as maximum transmit power level specified for the channel in the Country element minus the local power constraint specified for the channel in the Power Constraint element.The power constraint is coded as an unsigned integer in units of decibels. To disable power constraint set Power Constraint to 0.
1.3.6.1.4.1.14179.2.3.4.1.2
INTEGER0 = disable1 = enable · Integer32
To enable or disable channel switch. When disabling Channel Switch no need to pass mode and count
1.3.6.1.4.1.14179.2.3.4.1.3
INTEGER0 = disable1 = enable · Integer32
The Channel Switch Mode indicates any restriction on transmission until a channel switch. An Channel mode set to 1 means that the STA in a BSS to which the frame containing the element is addressed shall tranmit no further frames with in the BSS until the scheduled channel switch. A Channel switch mode set to 0 does not impose any requirement on the receiving STA.
1.3.6.1.4.1.14179.2.4.1.1.1
INTEGER1 = automatic2 = off · Integer32
Dynamic grouping has two modes: on and off. When the grouping is off, no dynamic grouping occurs. Each Airespace Switch optimizes only its own Airespace APs' parameters. When grouping is on, the Airespace Switches form groups and elect leaders to perform better dynamic parameter optimization.
1.3.6.1.4.1.14179.2.4.1.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
This is the MAC address of the group leader for the dot11a group containing this Airespace Switch.
1.3.6.1.4.1.14179.2.4.1.1.3
INTEGER0 = no1 = yes · Integer32
If this Airespace Switch is a Dot11a Group Leader then this attribute will be true else it will be false.
1.3.6.1.4.1.14179.2.4.1.1.4
Unsigned32
Last time the dot11a grouping was updated on this Airespace Switch. This is valid only if the Airespace Switch is a group leader.
1.3.6.1.4.1.14179.2.4.1.1.5
Unsigned32
When grouping is on, this interval(in secs) represents the period with which the grouping algorithm is run. Grouping algorithm will also run when the group contents changes and the automatic grouping is enabled. A dynamic grouping can be started upon request from the system administrator. Default value is 3600 secs.
1.3.6.1.4.1.14179.2.4.1.6.1
INTEGER (0..100) · Integer32
foreign 802.11A interference threshold between 0 and 100 percent.
1.3.6.1.4.1.14179.2.4.1.6.2
INTEGER (-127..0) · Integer32
802.11A foreign noise threshold between -127 and 0 dBm.
1.3.6.1.4.1.14179.2.4.1.6.3
INTEGER (0..100) · Integer32
802.11A RF utlization threshold between 0 and 100 percent.
1.3.6.1.4.1.14179.2.4.1.6.4
Unsigned32 (1000..1000000)
802.11A throughput threshold between 1000 and 1000000
1.3.6.1.4.1.14179.2.4.1.6.5
INTEGER (1..75) · Integer32
802.11A mobiles threshold between 1 and 75
1.3.6.1.4.1.14179.2.4.1.6.6
INTEGER (3..50) · Integer32
802.11A coverage threshold between 3 and 50.
1.3.6.1.4.1.14179.2.4.1.6.7
INTEGER (1..75) · Integer32
802.11A mobile minimum exception level between 1 and 75
1.3.6.1.4.1.14179.2.4.1.6.8
INTEGER (0..100) · Integer32
802.11A coverage exception level between 0 and 100 percent.
1.3.6.1.4.1.14179.2.4.1.6.9
Unsigned32 (60..3600)
This interval (in secs) specifies how often do we get new signal strength measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.1.6.10
Unsigned32 (60..3600)
This interval( in secs) specifies how often do we get new noise and interference measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.1.6.11
Unsigned32 (60..3600)
This interval( in secs) specifies how often do we get new load measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.1.6.12
Unsigned32 (60..3600)
This interval( in secs) specifies how often do we get new coverage measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.1.6.13
INTEGER1 = all2 = country3 = dca · Integer32
This attribute specifies the channels on which the switch monitors noise, interference and rogues. The first option allows monitoring on all channels while the second one on only those that are supported by the country of operation. the option dca implies that the monitor channel list will include those channels that are used by automatic channel assignment.
1.3.6.1.4.1.14179.2.4.1.7
INTEGER0 = default1 = activate · Integer32
When set to activate all rrm parameters are reset to factory defaults
1.3.6.1.4.1.14179.2.4.2.1.1
INTEGER1 = automatic2 = off · Integer32
Dynamic grouping has two modes: on and off. When the grouping is off, no dynamic grouping occurs. Each Airespace Switch optimizes only its own Airespace APs' parameters. When grouping is on, the Airespace Switchs form groups and elect leaders to perform better dynamic parameter optimization. This has been deprecated for clrRrmDot11BandGrpTable.
1.3.6.1.4.1.14179.2.4.2.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
This is the MAC address of the group leader for the dot11b group containing this Airespace Switch. This has been deprecated for clrRrmDot11BandGrpTable.
1.3.6.1.4.1.14179.2.4.2.1.3
INTEGER0 = no1 = yes · Integer32
If this Airespace Switch is a Dot11b Group Leader then this attribute will be true else it will be false. This has been deprecated for clrRrmDot11BandGrpTable.
1.3.6.1.4.1.14179.2.4.2.1.4
Unsigned32
Last time the dot11b grouping was updated on this Airespace Switch. This is valid only if the Airespace Switch is a group leader. This has been deprecated for clrRrmDot11BandGrpTable.
1.3.6.1.4.1.14179.2.4.2.1.5
Unsigned32
When grouping is on, this interval(in secs) represents the period with which the grouping algorithm is run. Grouping algorithm will also run when the group contents changes and the automatic grouping is enabled. A dynamic grouping can be started upon request from the system administrator. Default value is 3600 secs. This has been deprecated for clrRrmDot11BandGrpTable.
1.3.6.1.4.1.14179.2.4.2.6.1
INTEGER (0..100) · Integer32
Foreign 802.11A interference threshold between 0 and 100 percent.
1.3.6.1.4.1.14179.2.4.2.6.2
INTEGER (-127..0) · Integer32
802.11A foreign noise threshold between -127 and 0 dBm.
1.3.6.1.4.1.14179.2.4.2.6.3
INTEGER (0..100) · Integer32
802.11A RF utlization threshold between 0 and 100 percent.
1.3.6.1.4.1.14179.2.4.2.6.4
Unsigned32 (1000..1000000)
802.11A Airespace AP data-rate threshold between 1000 and 1000000
1.3.6.1.4.1.14179.2.4.2.6.5
INTEGER (1..75) · Integer32
802.11A Airespace AP mobiles threshold between 1 and 75
1.3.6.1.4.1.14179.2.4.2.6.6
INTEGER (3..50) · Integer32
802.11A Airespace AP coverage threshold between 3 and 50.
1.3.6.1.4.1.14179.2.4.2.6.7
INTEGER (1..75) · Integer32
802.11A Airespace AP mobile minimum exception level between 1 and 75
1.3.6.1.4.1.14179.2.4.2.6.8
INTEGER (0..100) · Integer32
802.11A Airespace AP coverage exception level between 0 and 100 percent.
1.3.6.1.4.1.14179.2.4.2.6.9
Unsigned32 (60..3600)
This interval( in secs) specifies how often do we get new signal strength measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.2.6.10
Unsigned32 (60..3600)
This interval( in secs) specifies how often do we get new noise and interference measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.2.6.11
Unsigned32 (60..3600)
This interval( in secs) specifies how often do we get new load measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.2.6.12
Unsigned32 (10..3600)
This interval( in secs) specifies how often do we get new coverage measurements at each Airespace AP. Default is 300 secs
1.3.6.1.4.1.14179.2.4.2.6.13
INTEGER1 = all2 = country3 = dca · Integer32
This attribute specifies the channels on which the switch monitors noise, interference and rogues. The first option allows monitoring on all channels while the second one on only those that are supported by the country of operation. the option dca implies that the monitor channel list will include those channels that are used by automatic channel assignment.
1.3.6.1.4.1.14179.2.4.2.7
INTEGER0 = default1 = activate · Integer32
When set to activate all rrm parameters are reset to factory defaults
1.3.6.1.4.1.14179.2.5.12
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
When keyWrap is enable then for 801.1X and 802.11i client Authentication, request is sent to those radius servers which has KEK and MACK keys are configured. Radius servers are widely used for user authentications. In 802.11i and 802.1X type authentication, the controller recives Pairwise Master KEy(PMK) from RADIUS sever using vendor specific RADIUS attributes, which uses MPPE RFC3078. Since MPPE uses RC4 algorithm to provide data confidentiality, it is not FIPS approved. For this RADIUS key WRAP attributes, bsnRadiusAuthServerKeyWrap and bsnRadiusAuthServerKeyWrapMACKkey have been added, which are used to securely transfer encryption keys using non-proprietary techniques.
1.3.6.1.4.1.14179.2.5.14
INTEGER0 = disable1 = enable · Integer32
Enable or disable caching of credentials locally for RADIUS Auth servers. This is used when a client uses a one time password authentication scheme.
1.3.6.1.4.1.14179.2.5.15
INTEGER0 = noDelimiter1 = colon2 = hyphen3 = singleHyphen · Integer32
The delimiter to be used for mac filtering. It can be colon as in xx:xx:xx:xx:xx:xx or hyphen as in xx-xx-xx-xx-xx-xx or single hyphen as in xxxxxx-xxxxxx or no delimiter as in xxxxxxxxxxxx.
1.3.6.1.4.1.14179.2.5.16
INTEGER0 = ciscoACS1 = orinocoRadius2 = other · Integer32
The required compatibility mode for MAC filtering. For ciscoACS, the expected MAC delimiter setting is colon and for orinocoRadius, it is singleHyphen.
1.3.6.1.4.1.14179.2.5.17
INTEGER0 = ipAddr1 = macAddr2 = apMacAddress · Integer32
This attribute configures the call station ID information sent in RADIUS messages. The value undefined cannot be set during the write operation.
1.3.6.1.4.1.14179.2.5.18
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..32) · OCTET STRING · hint 255a
This attribute configures the ACL Name for External Policy Servers
1.3.6.1.4.1.14179.2.5.20
Integer32 (512..2048)
This attribute is the total number of entries permitted in the local users database. This is the combined total of entries for Local Management Users, Local Net Users, Disabled Clients (previously known as blacklistclients and the MAC Filters. If the database size limit is reached, no more entries in any of these user lists are allowed to be created. To continue creating more entries, one should increase the size of the database. This value is applied on reboot and then matches the bsnAACurrentLocalDatabaseSize.
1.3.6.1.4.1.14179.2.5.21
Integer32 (512..2048)
This attribute is the maximum number of entries in the local users database that is effective currently. This is the combined total of entries for Local Management Users, Local Net Users, Disabled Clients (previously known as blacklist clients) and the MAC Filters.
1.3.6.1.4.1.14179.2.6.1.1
Unsigned32
This mask describes what events merit traps to network management. If the bit for a particular event is turned on then notification will be generated on event occurence. Event corresponding value ----- ----------------- bsnDot11StationDisassociate 1 bsnDot11StationDeauthenticate 2 bsnDot11StationAuthenticateFail 4 bsnDot11StationAssociateFail 8 bsnDot11StationBlacklisted 16 bsnDot11StationAssociate 32 ciscoLwappDot11ClientMovedToRunState 64 By Default all bits are off.
1.3.6.1.4.1.14179.2.6.1.2
Unsigned32
This mask describes what events merit traps to network management. If the bit for a particular event is turned on then notification will be generated on event occurance. Event corresponding bit ----- ----------------- bsnAPAssociate/Disassociate 1 bsnAPIfUp/Down 4 bsnAPAuthorizationFailureCause 16 By Default all bits are on.
1.3.6.1.4.1.14179.2.6.1.3
Unsigned32
This mask describes what events merit traps to network management. If the bit for a particular event is turned on then notification will be generated on event occurance. Event corresponding bit ----- ----------------- LoadProfileFail 1 NoiseProfileFail 2 InterferenceProfileFail 4 CoverageProfileFailed 8
1.3.6.1.4.1.14179.2.6.1.4
Unsigned32
Mac Parameters are updated for a Airespace AP interface whenever Dynamic Algorithm are run. This mask describes what update events merit traps to network management. If the bit for a particular event is turned on then notification will be generated on event occurance. Event corresponding bit ----- ----------------- TxPowerChange 1 ChannelChange 2 AntennaChange 4 RTSCTSThresholdChange 8 EDThresholdChange 16 FragmentationThresholdChange 32
1.3.6.1.4.1.14179.2.6.1.5
Unsigned32
This mask describes what events merit traps to network management. If the bit for a particular event is turned on then notification will be generated on event occurance. Event corresponding bit ----- ----------------- bsnIpsecEspAuthFailureTrap 1 bsnIpsecEspReplayFailureTrap 2 bsnIpsecEspPolicyFailureTrap 4 bsnIpsecEspInvalidSpiTrap 8 bsnIpsecOtherPolicyFailureTrap 16 bsnIpsecIkeNegFailure 32 bsnIpsecSuiteNegFailure 64 bsnIpsecInvalidCookieTrap 128
1.3.6.1.4.1.14179.2.6.1.6
INTEGER0 = disable1 = enable · Integer32
If Rogue AP Detection and Removed Traps need to be sent
1.3.6.1.4.1.14179.2.6.1.7
INTEGER0 = disable1 = enable · Integer32
if RADIUS Server Traps need to be sent
1.3.6.1.4.1.14179.2.6.1.8
INTEGER0 = disable1 = enable · Integer32
If Authentication Failure Traps need to be sent
1.3.6.1.4.1.14179.2.6.1.9
INTEGER0 = disable1 = enable · Integer32
If Rogue AP Detection and Removed Traps need to be sent
1.3.6.1.4.1.14179.2.6.1.10
Unsigned32
This mask is for Security related trap controls. Event corresponding bit ----- ----------------- bsnWepKeyDecryptError 1 bsnSignatureAttackDetected 2 By Default all bits are off.
1.3.6.1.4.1.14179.2.6.1.11
INTEGER0 = disable1 = enable · Integer32
This control is for WPS(Wireless Intrusion Protection System) related traps.
1.3.6.1.4.1.14179.2.6.2.1
OCTET STRING SIZE (0..32)
1.3.6.1.4.1.14179.2.6.2.2
INTEGER1 = mgmtUser2 = wlanUser3 = macFilter · Integer32
1.3.6.1.4.1.14179.2.6.2.3
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.4
Integer32
1.3.6.1.4.1.14179.2.6.2.5
Integer32
1.3.6.1.4.1.14179.2.6.2.6
Integer32 (0..65535)
1.3.6.1.4.1.14179.2.6.2.7
Integer32
1.3.6.1.4.1.14179.2.6.2.8
Integer32
1.3.6.1.4.1.14179.2.6.2.9
Integer32
1.3.6.1.4.1.14179.2.6.2.10
Integer32
1.3.6.1.4.1.14179.2.6.2.11
Integer32
1.3.6.1.4.1.14179.2.6.2.12
Integer32
1.3.6.1.4.1.14179.2.6.2.13
Integer32
1.3.6.1.4.1.14179.2.6.2.14
Integer32
1.3.6.1.4.1.14179.2.6.2.15
OCTET STRING SIZE (8)
The initiator cookie used in an ISAKMP message, to be associated with a trap.
1.3.6.1.4.1.14179.2.6.2.16
OCTET STRING SIZE (8)
The responder cookie used in an ISAKMP message, to be associated with a trap.
1.3.6.1.4.1.14179.2.6.2.17
Integer32
1.3.6.1.4.1.14179.2.6.2.18
Integer32
1.3.6.1.4.1.14179.2.6.2.19
Integer32
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.21
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
1.3.6.1.4.1.14179.2.6.2.22
Integer32
Number of Radio Interfaces on the Airespace AP.
1.3.6.1.4.1.14179.2.6.2.23
Integer32
1.3.6.1.4.1.14179.2.6.2.24
Integer32
1.3.6.1.4.1.14179.2.6.2.25
Integer32
1.3.6.1.4.1.14179.2.6.2.26
Integer32
1.3.6.1.4.1.14179.2.6.2.27
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.28
Integer32
1.3.6.1.4.1.14179.2.6.2.29
Integer32
1.3.6.1.4.1.14179.2.6.2.30
Integer32
1.3.6.1.4.1.14179.2.6.2.31
Integer32
1.3.6.1.4.1.14179.2.6.2.32
Integer32
1.3.6.1.4.1.14179.2.6.2.33
Integer32
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.37
INTEGER1 = unspecified2 = previousAuthNotValid3 = deauthenticationLeaving4 = disassociationDueToInactivity5 = disassociationAPBusy6 = class2FrameFromNonAuthStation7 = class2FrameFromNonAssStation8 = disassociationStaHasLeft9 = staReqAssociationWithoutAuth40 = invalidInformationElement41 = groupCipherInvalid42 = unicastCipherInvalid43 = akmpInvalid44 = unsupportedRsnVersion45 = invalidRsnIeCapabilities46 = cipherSuiteRejected99 = missingReasonCode101 = maxAssociatedClientsReached200 = unSpecifiedQosFailure201 = qosPolicyMismatch202 = inSufficientBandwidth203 = inValidQosParams · Integer32
unspecified - Unspecified. previousAuthNotValid - Previous Authentication was not valid. deauthenticationLeaving - Leaving due to deauthentication. disassociationDueToInactivity - Disassociation due to Inactivity. disassociationAPBusy - Disassociation since AP was busy. class2FrameFromNonAuthStation - Class 2 frame from non authenticated station. class2FrameFromNonAssStation - Class 2 frame from non associated station. disassociationStaHasLeft - Station has left due to disassociation. staReqAssociationWithoutAuth - Station send association request without authentication. invalidInformationElement - Invalid information element. groupCipherInvalid - Invalid group Cipher. unicastCipherInvalid - Invalid unicast cipher. akmpInvalid - Invalid AKMP. unsupportedRsnVersion - Unsupported RSN version. invalidRsnIeCapabilities - Invalid RSN IE capabilities. cipherSuiteRejected - Cipher suite rejected. missingReasonCode - Reason code is missing. maxAssociatedClientsReached - Maximum allowed associated client number has reached. unSpecifiedQosFailure - Unsupported QOS failure. qosPolicyMismatch - Mismatch on QOS policy. inSufficientBandwidth - Insufficient bandwidth. inValidQosParams - Invalid QOS parameters.
1.3.6.1.4.1.14179.2.6.2.38
INTEGER1 = failed80211Auth2 = failedAssociation3 = ipTheft4 = failed8021xAuth5 = failedWebAuth · Integer32
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.6.2.40
INTEGER0 = no1 = yes · Integer32
This is the flag used on the bsnRogueAPDetected trap to state if the rogue is found on the wired network. Typically, after a rogue is found, there may be another bsnRogueAPDetected trap that will have the value of this flag 1 if the rogue is detected on the wired network.
1.3.6.1.4.1.14179.2.6.2.41
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC address generating the attack.
1.3.6.1.4.1.14179.2.6.2.42
INTEGER (1..517) · Integer32
WLAN ID used by the client when the WPA MIC error counter measure was activated.
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.44
INTEGER0 = no1 = yes · Integer32
This is the flag used on the bsnRogueAPDetected trap to state if the rogue found is an Adhoc rogue or it is an AP.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.2.46
IpAddress SIZE (4)
This field is used on the bsnDuplicateIpAddressReported trap to contain the IP Address in question when switch or an AP detected a duplicate IP Address on another machine.
1.3.6.1.4.1.14179.2.6.2.47
INTEGER0 = false1 = true · Integer32
This is the flag used to indicate clear state for the bsnDuplicateIpAddressReported trap.
1.3.6.1.4.1.14179.2.6.2.48
INTEGER0 = no1 = yes · Integer32
This is the flag used on the bsnDuplicateIpAddressReported trap to indicate whether the switch or an AP detected a duplicate IP Address on another machine.
1.3.6.1.4.1.14179.2.6.2.49
INTEGER0 = none1 = dot11b2 = dot11a3 = dot11bg · Integer32
This is the radio policy required by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.50
INTEGER0 = none1 = open2 = wep3 = wpa · Integer32
This is the encryption type used by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.51
INTEGER0 = none1 = open2 = wep3 = wpa · Integer32
This is the encryption type required by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.52
INTEGER0 = none1 = dot11b2 = dot11a3 = dot11bg · Integer32
This is the radio policy used by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.53
INTEGER1 = dot11b2 = dot11a · Integer32
1.3.6.1.4.1.14179.2.6.2.54
INTEGER0 = disable1 = enable · Integer32
1.3.6.1.4.1.14179.2.6.2.55
INTEGER0 = standard1 = custom · Integer32
Type of Signature whose attack is detected by the switch.
1.3.6.1.4.1.14179.2.6.2.56
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..20) · OCTET STRING · hint 255a
Name of the Signature whose attack is detected by the switch.
1.3.6.1.4.1.14179.2.6.2.57
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..100) · OCTET STRING · hint 255a
Description of the Signature whose attack is detected by the switch.
1.3.6.1.4.1.14179.2.6.2.58
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of the AP impersonated by another AP.
1.3.6.1.4.1.14179.2.6.2.59
INTEGER0 = none1 = short2 = long · Integer32
The Preamble on this detecting AP.
1.3.6.1.4.1.14179.2.6.2.60
INTEGER0 = none1 = short2 = long · Integer32
The Preamble on this detecting AP.
1.3.6.1.4.1.14179.2.6.2.61
INTEGER (0..65535) · Integer32
The preced in the standard/custom signature list.
1.3.6.1.4.1.14179.2.6.2.62
INTEGER (0..65535) · Integer32
The preced in the standard/custom signature list.
1.3.6.1.4.1.14179.2.6.2.63
INTEGER (0..65535) · Integer32
The preced in the standard/custom signature list.
1.3.6.1.4.1.14179.2.6.2.64
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of the Attacker's mac-interface.
1.3.6.1.4.1.14179.2.6.2.65
OCTET STRING SIZE (0..255)
This is the license key that has been found to be deleted, expired or is mismatched causing AP functionality to be disabled on the switch.
1.3.6.1.4.1.14179.2.6.2.66
INTEGER0 = unknown1 = licenseKeyExpired2 = licenseKeyDeleted3 = licenseKeyFeatureMismatch · Integer32
This is the reason why the AP functionality was disabled on the switch. It could be either expiry or deletion or mismatch found of the license key.
1.3.6.1.4.1.14179.2.6.2.67
INTEGER1 = wps2 = all · Integer32
This is the switch feature set whose license key has expired or is deleted or is mismatched. To enable the AP functionality again, the license key for this feature set should be re-configured.
1.3.6.1.4.1.14179.2.6.2.68
INTEGER0 = a1 = e6 = i9 = j16 = c21 = n32 = k33 = p34 = s35 = t48 = r65535 = notavailable · Integer32
The regulatory domain configured on an AP.
1.3.6.1.4.1.14179.2.6.2.69
INTEGER0 = unknown1 = keymismatch2 = entrydoesnotexist3 = invalidCertifcate4 = entryIsMIC5 = aaaEntryDoesNotExist · Integer32
This denotes the reason for AP authorization failure. [entrydoesnotexist]: The AP has not been added to Controller's AP Authorization List. [keymismatch]: The key entry in Controller's AP Authorization list does not match the SHA1 key received from the AP. [invalidCert]: Could not verify the self signed Certificate. [entryIsMIC]: AP has Self Signed Certificate where as in Controller AP Authorization list has Manufactured Installed Certificate [aaaEntryDoesNotExist]: RADIUS authorization for the AP failed. [unknown]: Default.
1.3.6.1.4.1.14179.2.6.2.70
INTEGER0 = unknown1 = radioFailure2 = radioLowPower3 = maxRetransmission4 = echoTimeout5 = configAP6 = configRadio7 = configNetwork8 = adminConfigured9 = missedRekey10 = detectingInLinePower11 = newDiscovery · Integer32
This denotes the reason for AP If up or down normal - radio Failure - radio failed radioLowPower - AP is not able draw enough power. maxRetransmission - max retransmission of AP Reached. echoTimeout - heartbeat timeout. configAP - admin enable/disable AP configRadio - admin enable/disable config radio configNetwork - admin enable/disable network adminConfigured - admin configuration missedRekey - Missed Rekey detectingInLinePower - Detecting in-line power newDiscovery - New Discovery
1.3.6.1.4.1.14179.2.6.2.71
INTEGER0 = unsupportedRadio · Integer32
Radio types which are not supported by controller.
1.3.6.1.4.1.14179.2.6.2.72
OCTET STRING SIZE (0..512)
This is the content of the notification.
1.3.6.1.4.1.14179.2.6.2.73
BsnTxtSignatureMacInfo0 = bsnSignatureMacAll1 = bsnSignatureMacIndividual2 = bsnSignatureMacBothThis textual convention defines the pattern followed by the LWAPP APs to perform signature analysis with the signature and report the results to the Controller. The semantics are described as follows. bsnSignatureMacAll - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported on a per-signature and per-channel basis. bsnSignatureMacIndividual - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported separately for individual MAC addresses, that are the sources of the received 802.11 data and/or management frames. bsnStandardSigMacBoth - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked on a per signature as well as per-MAC address basis. · Integer32
This object defines the pattern followed by the LWAPP APs to perform signature analysis with this signature and report the results to the Controller.
1.3.6.1.4.1.14179.2.6.2.74
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
This is the source mac address which is impersonating the AP.
1.3.6.1.4.1.14179.2.6.2.83
Integer32
1.3.6.1.4.1.14179.2.6.2.84
BITS
1.3.6.1.4.1.14179.2.6.2.85
Integer32
1.3.6.1.4.1.14179.2.6.2.86
Integer32
1.3.6.1.4.1.14179.2.6.2.87
Integer32
1.3.6.1.4.1.14179.2.6.2.88
Integer32
1.3.6.1.4.1.14179.2.7.1.1
INTEGER0 = no1 = yes · Integer32
1.3.6.1.4.1.14179.2.7.1.2
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
This would be the IP Address or host name
1.3.6.1.4.1.14179.2.8.1.1
Integer32
Port Number on which mobility Protocol runs
1.3.6.1.4.1.14179.2.8.1.3
INTEGER0 = disable1 = enable · Integer32
Statically Configured is always enabled if members are defined. To further enable rrm discovery, learned discovery, broadcast discovery, enable/disable this attribute.
1.3.6.1.4.1.14179.2.8.1.4
INTEGER0 = default1 = resetNow · Integer32
Reset mobility statistics by setting this atribute to resetNow. If you try to read this attribute value will always be 0.
1.3.6.1.4.1.14179.2.8.2.1
Counter32
Total handoff requests
1.3.6.1.4.1.14179.2.8.2.2
Counter32
Total handoffs
1.3.6.1.4.1.14179.2.8.2.3
Counter32
Current exported client count
1.3.6.1.4.1.14179.2.8.2.4
Counter32
Total exported client count
1.3.6.1.4.1.14179.2.8.2.5
Counter32
Current Imported client count
1.3.6.1.4.1.14179.2.8.2.6
Counter32
Total Imported client count
1.3.6.1.4.1.14179.2.8.2.7
Counter32
Total handoff errors
1.3.6.1.4.1.14179.2.8.2.8
Counter32
Total communication errors
1.3.6.1.4.1.14179.2.8.2.10
Counter32
Total receive errors
1.3.6.1.4.1.14179.2.8.2.11
Counter32
Total Transmit errors
1.3.6.1.4.1.14179.2.8.2.12
Counter32
Total Responses Retransmitted
1.3.6.1.4.1.14179.2.8.2.13
Counter32
Total Handoff End Requests Received
1.3.6.1.4.1.14179.2.8.2.14
Counter32
Total State Transitions Disallowed
1.3.6.1.4.1.14179.2.8.2.15
Counter32
Total Resource Errors
1.3.6.1.4.1.14179.2.8.2.16
Counter32
Total Handoff Requests Sent
1.3.6.1.4.1.14179.2.8.2.17
Counter32
Total Handoff Replies Received
1.3.6.1.4.1.14179.2.8.2.18
Counter32
Total Handoffs As Local Received
1.3.6.1.4.1.14179.2.8.2.19
Counter32
Total Handoffs As Foreign Received
1.3.6.1.4.1.14179.2.8.2.20
Counter32
Total Handoff Denies Received
1.3.6.1.4.1.14179.2.8.2.21
Counter32
Total Anchor Requests Sent
1.3.6.1.4.1.14179.2.8.2.22
Counter32
Total Anchor Deny Received
1.3.6.1.4.1.14179.2.8.2.23
Counter32
Total Anchor Grant Received
1.3.6.1.4.1.14179.2.8.2.24
Counter32
Total Anchor Transfer Received
1.3.6.1.4.1.14179.2.8.2.25
Counter32
Total Handoff Requests Ignored
1.3.6.1.4.1.14179.2.8.2.26
Counter32
Total Ping Pong Handoff Requests Dropped
1.3.6.1.4.1.14179.2.8.2.27
Counter32
Total Handoff Requests Dropped
1.3.6.1.4.1.14179.2.8.2.28
Counter32
Total Handoff Requests Denied
1.3.6.1.4.1.14179.2.8.2.29
Counter32
Total Client Handoffs As Local
1.3.6.1.4.1.14179.2.8.2.30
Counter32
Total Client Handoffs As Foreign
1.3.6.1.4.1.14179.2.8.2.31
Counter32
Total Anchor Requests Received
1.3.6.1.4.1.14179.2.8.2.32
Counter32
Total Anchor Requests Denied
1.3.6.1.4.1.14179.2.8.2.33
Counter32
Total Anchor Requests Granted
1.3.6.1.4.1.14179.2.8.2.34
Counter32
Total Anchor Transferred
1.3.6.1.4.1.14179.2.8.2.35
Counter32
Total Handoff Requests Received
1.3.6.1.4.1.14179.2.9.1
OCTET STRING SIZE (0..4096)
1.3.6.1.4.1.14179.2.9.2
OCTET STRING SIZE (0..4096)
Note this attribute is for updating the certificate If you try to read it, it will always be ***
1.3.6.1.4.1.14179.2.10.1
INTEGER0 = disable1 = enable · Integer32
When enabled, Site Specific WLAN feature is enforced.
1.3.6.1.4.1.14179.2.1.1
Index: bsnDot11EssIndex
Ess(WLAN) Configuration Table indexed by bsnDot11EssIndex. Maximum of 17 WLANs can be created on Airespace Switch. bsnDot11EssIndex of 17 is reserved for WLAN for Third Party APs(non-Airespace APs).
1.3.6.1.4.1.14179.2.1.1.1.1
Unsigned32 (1..517)
Index of the Ess(WLAN) within Airespace Switch. Airespace Switch supports 517 ESS(Wlans) so index will be from 1 to 517. 517 is to be used for ESS(WLAN) created for support of Third Party APs(non-Airespace APs)
1.3.6.1.4.1.14179.2.1.1.1.2
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (1..32) · OCTET STRING · hint 255a
SSID assigned to ESS(WLAN)
1.3.6.1.4.1.14179.2.1.1.1.4
Unsigned32 (0..86400)
Maximum time of a Mobile Station session. Value of 0 means infinite time(no timeout set).
1.3.6.1.4.1.14179.2.1.1.1.5
INTEGER0 = disable1 = enable · Integer32
A type of security policy for Mobile Stations (Clients). Select to filter clients by MAC address. By selecting this Security, you need to create MacFilters in bsnUsersTable or have MacFilters configured on Radius Servers specified in bsnRadiusAuthenticationTable
1.3.6.1.4.1.14179.2.1.1.1.6
INTEGER0 = disable1 = enable · Integer32
Administrative Status of ESS(WLAN). By disabling an ESS the corresponding SSID is no longer broadcasted in AP beacons.
1.3.6.1.4.1.14179.2.1.1.1.7
INTEGER0 = authOpen1 = authSharedKey128 = authCiscoLeap · Integer32
Type of 802.11 Authentication.
1.3.6.1.4.1.14179.2.1.1.1.8
INTEGER1 = enable0 = disable · Integer32
Status of Static WEP Security policy. If enabled, WEP Encryption WEP Default Key, Key Index and Key Format should also be specified.
1.3.6.1.4.1.14179.2.1.1.1.9
INTEGER0 = wep1042 = wep403 = wep1284 = notset · Integer32
Type of Static WEP Encryption. Length of key specified in Default Key depends on this attribute.
1.3.6.1.4.1.14179.2.1.1.1.10
WEPKeytypeThis object indicates the WEP Key type. SIZE (4..32) · OCTET STRING
Static WEP Default Key. For wep104 encryption either 26 bit hex key or 13 bit ascii key should be specified. For wep40 encryption 10 bit hex key or 5 bit ascii key should be specified. For wep128 encryption 32 bit hex key or 16 bit ascii key should be specified.
1.3.6.1.4.1.14179.2.1.1.1.11
INTEGER (0..4) · Integer32
According to 802.11 standard 4 keys are supported. So 802.11 Mobile Stations(Client) can have upto 4 keys from 1 to 4. The read-only value zero indicates that there is no WEP Authentication key information available.This index is for informing Mobile Station which key it should use for Static WEP Authentication
1.3.6.1.4.1.14179.2.1.1.1.12
INTEGER1 = hex2 = ascii0 = default · Integer32
This is not persistant.Reading this attribute will always return default. The format of the key specified in Airespace switch keeps record of the Index.
1.3.6.1.4.1.14179.2.1.1.1.13
INTEGER1 = enable0 = disable · Integer32
Status of 802.1X security policy.
1.3.6.1.4.1.14179.2.1.1.1.14
INTEGER0 = wep1042 = wep403 = wep1284 = none · Integer32
Type of 802.1X Encryption. This applies if bsnDot11Ess8021xSecurity is in enabled state.
1.3.6.1.4.1.14179.2.1.1.1.16
INTEGER1 = enable0 = disable · Integer32
Status of WPA security policy. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.17
INTEGER0 = wep1042 = wep403 = wep1285 = tkipmic · Integer32
Type of WPA Encryption. This applies when bsnDot11EssWPASecurity is in enable state. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.18
INTEGER1 = enable0 = disable · Integer32
Status of IpSec (VPN) security policy. Note that this cannot be applied with Web security policy.
1.3.6.1.4.1.14179.2.1.1.1.19
INTEGER0 = tripleDes1 = none2 = des3 = aesCbc · Integer32
The Encryption algorithm employed by this Vpn(IpSec) Encryption. This applies only when bsnDot11EssIpsecSecurity is in enable state.
1.3.6.1.4.1.14179.2.1.1.1.20
INTEGER1 = none2 = hmacMd50 = hmacSha1 · Integer32
The Hash algorithm employed by the Vpn Encrpytion. This applies only when bsnDot11EssIpsecSecurity is in enable state.
1.3.6.1.4.1.14179.2.1.1.1.21
INTEGER0 = xauthEnablePsk2 = certificate3 = presharedKey · Integer32
The authentication type of the SA. It could be a certificate or a pre-shared key or xauthEnablePsk. This applies only when bsnDot11EssIpsecSecurity is in enable state.
1.3.6.1.4.1.14179.2.1.1.1.22
OCTET STRING SIZE (1..128)
VPN Shared Key. This applies only when bsnDot11EssVpnSharedKey is in enable state and bsnDot11EssVpnIkeAuthMode is xauthEnablePsk or presharedKey.
1.3.6.1.4.1.14179.2.1.1.1.23
Unsigned32 (0..128)
VPN Shared Key size. This applies only when bsnDot11EssVpnSharedKey is in enable state and bsnDot11EssVpnIkeAuthMode is xauthEnablePsk or presharedKey.
1.3.6.1.4.1.14179.2.1.1.1.24
INTEGER0 = agressive1 = main · Integer32
VPN IKE Phase 1 Mode type as per the IpSec standards. This applies only when bsnDot11EssIpsecSecurity is in enable state.
1.3.6.1.4.1.14179.2.1.1.1.25
Integer32 (1800..345600)
Vpn IKE's Lifetime. This applies only when bsnDot11EssIpsecSecurity is in enable state.
1.3.6.1.4.1.14179.2.1.1.1.26
INTEGER0 = group21 = group14 = group5 · Integer32
IKE's Diffie-Hellman Group. This applies only when bsnDot11EssIpsecSecurity is in enable state.
1.3.6.1.4.1.14179.2.1.1.1.27
INTEGER1 = enable0 = disable · Integer32
Status of IpSec Passthru security policy.
1.3.6.1.4.1.14179.2.1.1.1.28
IpAddress SIZE (4)
Ip address of VpnPassthru Gateway. This applies only when bsnDot11EssIpsecPassthruSecurity is in enable state.
1.3.6.1.4.1.14179.2.1.1.1.29
INTEGER1 = enable0 = disable · Integer32
Status of Web security policy. Note this policy cannot be applied with IpSec security policy.
1.3.6.1.4.1.14179.2.1.1.1.30
INTEGER0 = all2 = dot11aOnly1 = dot11bOnly3 = dot11gOnly4 = dot11bgOnly5 = dot11agOnly6 = dot11abOnly · Integer32
Radio Policy for a WLAN. It can either be All where it will be applicable to ALL types of protocols or it can be set to apply to combinations of 802.11a, 802.11b, 802.11g.
1.3.6.1.4.1.14179.2.1.1.1.31
INTEGER0 = bronze1 = silver2 = gold3 = platinum · Integer32
Quality of Service for a WLAN.Services such as VoIP should be set to Gold while non-discriminating services such as messaging can be set to Bronze.
1.3.6.1.4.1.14179.2.1.1.1.32
INTEGER0 = disable1 = enable · Integer32
DHCP required for all clients on this WLAN
1.3.6.1.4.1.14179.2.1.1.1.33
IpAddress SIZE (4)
IP Address of the DHCP Server. Make it 0.0.0.0 to disable DHCP Relay. Any value other than 0.0.0.0, it will be assumed that DHCP Relay is turned on.
1.3.6.1.4.1.14179.2.1.1.1.34
INTEGER0 = disable1 = enable · Integer32
Specifies if contivity mode for the IpSec is enabled. If enabled, user needs to specify the Quote of the Day Server's IPAddress in bsnDot11EssVpnQotdServerAddress.
1.3.6.1.4.1.14179.2.1.1.1.35
IpAddress SIZE (4)
IP Address of the Quote of the Day Server.
1.3.6.1.4.1.14179.2.1.1.1.37
Integer32 (0..2147483647)
Set the timeout for blacklisted Mobile Stations after which the mobile station will be automatically de-authenticated. Mobile Station are blacklisted by MAC address and their status can be obtained from bsnMobileStationStatus. A timeout setting of 0 indicates no blacklist timeout is set and administrative control (bsnMobileStationDeleteAction ) is required to deauthenticate the station.
1.3.6.1.4.1.14179.2.1.1.1.38
Counter32
No of Mobile Stations currently associated with the WLAN.
1.3.6.1.4.1.14179.2.1.1.1.39
INTEGER1 = enable0 = disable · Integer32
For switches with version before 2.0: This is applicable only when the Web Security Type is enabled. When this attribute is enabled, it allows a client's NetBIOS packets to go through the switch before web auth is completed. (This is obsolete for Switch versions 2.0 to 2.2). For switch verions 3.0 and above: This is reintroduced as the web policy where the client is connected through the web without authentication that is there is no username/password input required. Moreover, if the bsnDot11EssWebPassthroughEmail is enabled, the user will be asked to enter an email address.
1.3.6.1.4.1.14179.2.1.1.1.40
INTEGER1 = enable0 = disable · Integer32
Status of Cranite Passthrough Security policy. If enabled, no other security can be enabled.
1.3.6.1.4.1.14179.2.1.1.1.41
INTEGER0 = disable1 = enable · Integer32
This is the flag that can enable or disable the client backlisting feature for a WLAN. If enabled, the clients can be blacklisted by the Switch in case of repetitive auth failure and other reasons like it. If disabled, the clients cannot be blacklisted by the switch. The blacklist timeout value will only be effective if this feature is turned on.
1.3.6.1.4.1.14179.2.1.1.1.42
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (1..32) · OCTET STRING · hint 255a
Name of the interface used by this WLAN. By default it is set to be the management interface.
1.3.6.1.4.1.14179.2.1.1.1.43
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..32) · OCTET STRING · hint 255a
Name of ACL for the WLAN. This is applicable only when Web Authentication is enabled as a security. An empty string value indicates that no ACL has been set (which is a valid option)
1.3.6.1.4.1.14179.2.1.1.1.44
INTEGER0 = disable1 = enable · Integer32
Enable or Disable AAA override for the global WLAN parameters.
1.3.6.1.4.1.14179.2.1.1.1.45
INTEGER0 = disable1 = enable · Integer32
Enable or Disable WPA Pre-shared Key Mode. If enabled, a preshared key should be set for WPA authentication. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.46
OCTET STRING SIZE (8..63)
WPA Authentication Preshared Key. This applies only when bsnDot11EssWPAAuthKeyMgmtMode is in enable state. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.47
INTEGER1 = enable0 = disable · Integer32
Status of Fortress Passthrough Security policy. If enabled, no other security can be enabled.
1.3.6.1.4.1.14179.2.1.1.1.48
INTEGER1 = enable0 = disable · Integer32
Enable this flag to allow Shared Key Authentication when Static WEP is enabled.
1.3.6.1.4.1.14179.2.1.1.1.49
INTEGER1 = enable0 = disable · Integer32
Status of L2TP security policy. Note that this cannot be applied with Web security policy, Cranite or Fortress policy.
1.3.6.1.4.1.14179.2.1.1.1.50
OCTET STRING SIZE (0..40)
WPA Authentication Preshared Key in the hex format. This applies only when bsnDot11EssWPAAuthKeyMgmtMode is in enable state. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.51
INTEGER1 = enable0 = disable · Integer32
This attribute when enabled allows the switch to broadcast this SSID.
1.3.6.1.4.1.14179.2.1.1.1.52
INTEGER1 = enabled0 = disabled · Integer32
This attribute specifies if external policy servers will be used for validation. If no servers are configured in bsnExternalPolicyServerTable then it cannot be enabled.
1.3.6.1.4.1.14179.2.1.1.1.53
INTEGER1 = enable0 = disable · Integer32
This attribute specifies status of RSN Security Policy. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.54
INTEGER1 = enable0 = disable · Integer32
This attribute specifies RSN security's compatibility mode with WPA. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.55
INTEGER1 = yes0 = no · Integer32
This attribute specifies whether TKIP clients are allowed by RSN Policy. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.56
INTEGER1 = enable0 = disable · Integer32
This attribute specifies whether Preshared key is used or not. If used user should specify a key between 8 and 63 characters in bsnDot11EssRSNAuthPresharedKey attribute. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.57
OCTET STRING SIZE (8..63)
RSN Authentication Preshared Key. This applies only when bsnDot11EssRSNAuthKeyMgmtMode is in enable state. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.58
OCTET STRING SIZE (0..40)
RSN Authentication Preshared Key in the hex format. This applies only when bsnDot11EssWPAAuthKeyMgmtMode is in enable state. This has been deprecated for cLWSecDot11EssCckmTable.
1.3.6.1.4.1.14179.2.1.1.1.59
INTEGER0 = disable1 = enable · Integer32
When enabled, IPv6 bridging is applied on the packets.
1.3.6.1.4.1.14179.2.1.1.1.60
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
A row status type for the bsnDot11EssEntry
1.3.6.1.4.1.14179.2.1.1.1.61
INTEGER0 = disable1 = allowed2 = required3 = invalid · Integer32
When enabled, WME Policy is applied on the packets.
1.3.6.1.4.1.14179.2.1.1.1.62
INTEGER0 = disable1 = allowed2 = required3 = invalid · Integer32
When enabled, 802.11e Policy is applied on the packets.
1.3.6.1.4.1.14179.2.1.1.1.63
INTEGER0 = disable1 = enable · Integer32
When enabled, along with the bsnDot11EssWebPassthru attribute, the client is allowed to connect by entering his/her email address on the web connection page. There is no further authentication required.
1.3.6.1.4.1.14179.2.1.1.1.64
INTEGER0 = disable1 = clientCacLimit2 = apCacLimit3 = both · Integer32
When client cac limit is enabled, the 7920 Phones with old software where the Call Admission Control (CAC) Limit is Specified on the client will be supported on the WLAN. The support for clientCacLimit (by setting to value 1 or 3) cannot be enabled when the bsnDot11EssWmePolicySetting is set to allowed or required. When ap cac limit is enabled, the 7920 Phones with new software where the Call Admission Control (CAC) Limit is advertised by the AP, will be supported on the WLAN.
1.3.6.1.4.1.14179.2.1.1.1.95
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..21) · OCTET STRING · hint 255a
Primary Radius Authentication Server for this wlan.
1.3.6.1.4.1.14179.2.1.1.1.96
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..21) · OCTET STRING · hint 255a
Secondary Radius Authentication Server for this wlan.
1.3.6.1.4.1.14179.2.1.1.1.97
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..21) · OCTET STRING · hint 255a
Tertiary Radius Authentication Server for this wlan.
1.3.6.1.4.1.14179.2.1.1.1.98
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..21) · OCTET STRING · hint 255a
Primary Radius Accounting Server for this wlan.
1.3.6.1.4.1.14179.2.1.1.1.99
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..21) · OCTET STRING · hint 255a
Secondary Radius Accounting Server for this wlan.
1.3.6.1.4.1.14179.2.1.1.1.100
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..21) · OCTET STRING · hint 255a
Tertiary Radius Accounting Server for this wlan.
1.3.6.1.4.1.14179.2.1.4
Index: bsnMobileStationMacAddress
Mobile Station Table indexed by bsnMobileStationMacAddress. (Mobile Station is better referred to as Client in the current releases.)
1.3.6.1.4.1.14179.2.1.4.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
802.11 MAC Address of the Mobile Station.
1.3.6.1.4.1.14179.2.1.4.1.2
IpAddress SIZE (4)
IP Address of the Mobile Station
1.3.6.1.4.1.14179.2.1.4.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
User Name,if any, of the Mobile Station. This would be non empty in case of Web Authentication and IPSec.
1.3.6.1.4.1.14179.2.1.4.1.4
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
802.11 Mac Address of the AP to which the Mobile Station is associated.
1.3.6.1.4.1.14179.2.1.4.1.5
INTEGER (0..15) · Integer32
Slot ID of AP Interface to which the mobile station is associated. The value 15 is used to indicate that the slot Id is invalid.
1.3.6.1.4.1.14179.2.1.4.1.6
INTEGER (0..16) · Integer32
Ess Index of the Wlan(SSID) that is being used by Mobile Station to connect to AP
1.3.6.1.4.1.14179.2.1.4.1.7
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The SSID Advertised by Mobile Station
1.3.6.1.4.1.14179.2.1.4.1.8
Unsigned32
AID for the mobile station
1.3.6.1.4.1.14179.2.1.4.1.9
INTEGER0 = idle1 = aaaPending2 = authenticated3 = associated4 = powersave5 = disassociated6 = tobedeleted7 = probing8 = blacklisted · Integer32
Status of the mobile station
1.3.6.1.4.1.14179.2.1.4.1.10
INTEGER1 = unspecified2 = previousAuthNotValid3 = deauthenticationLeaving4 = disassociationDueToInactivity5 = disassociationAPBusy6 = class2FrameFromNonAuthStation7 = class2FrameFromNonAssStation8 = disassociationStaHasLeft9 = staReqAssociationWithoutAuth40 = invalidInformationElement41 = groupCipherInvalid42 = unicastCipherInvalid43 = akmpInvalid44 = unsupportedRsnVersion45 = invalidRsnIeCapabilities46 = cipherSuiteRejected99 = missingReasonCode101 = maxAssociatedClientsReached200 = unSpecifieQosFailure201 = qosPolicyMismatch202 = inSufficientBandwidth203 = inValidQosParams · Integer32
Reason Code as defined by 802.11 standards
1.3.6.1.4.1.14179.2.1.4.1.11
INTEGER0 = unassociated1 = local2 = anchor3 = foreign4 = handoff5 = unknown6 = exportanchor7 = exportforeign · Integer32
Mobility Role of the Mobile Station.
1.3.6.1.4.1.14179.2.1.4.1.12
IpAddress SIZE (4)
If the Mobility Status of the Mobile Station is Anchor then it will have Peer Ip Address and will have Anchor IP if the Role is Foreign
1.3.6.1.4.1.14179.2.1.4.1.13
INTEGER0 = notimplemented1 = implemented · Integer32
When this attribute is true, it shall indicate that the Mobile Station is able to respond to a CF-Poll with a data frame within a SIFS time. This attribute shall be false if the Mobile Station is not able to respond to a CF-Poll with a data frame within a SIFS time.
1.3.6.1.4.1.14179.2.1.4.1.14
INTEGER0 = notimplemented1 = implemented · Integer32
Specifies whether CFP is requested by Mobile Station or not
1.3.6.1.4.1.14179.2.1.4.1.15
INTEGER0 = notimplemented1 = implemented · Integer32
This attribute indicates that the PHY channel agility functionality is enabled.
1.3.6.1.4.1.14179.2.1.4.1.16
INTEGER0 = notimplemented1 = implemented · Integer32
This attribute, when true, shall indicate that the PBCC modulation option as defined in subclause 18.4.6.6 is implemented. The default value of this attribute shall be false.
1.3.6.1.4.1.14179.2.1.4.1.17
INTEGER0 = notimplemented1 = implemented · Integer32
This attribute, when true, shall indicate that the short preamble option as defined in subclause 18.2.2.2 is implemented. The default value of this attribute shall be false.
1.3.6.1.4.1.14179.2.1.4.1.18
Unsigned32
Session Timeout of Mobile station
1.3.6.1.4.1.14179.2.1.4.1.19
INTEGER0 = openSystem1 = sharedKey2 = unknown128 = openAndEap · Integer32
Authentication Algorithm of Mobile Station
1.3.6.1.4.1.14179.2.1.4.1.20
INTEGER1 = enable2 = disable · Integer32
WEP State of Mobile Station
1.3.6.1.4.1.14179.2.1.4.1.21
Unsigned32
The Port Number of this Airespace Switch on which the traffic of the Mobile Station is coming through.
1.3.6.1.4.1.14179.2.1.4.1.22
INTEGER0 = default1 = delete · Integer32
Action to Deauthenticate the Mobile Station. Set the State to delete.
1.3.6.1.4.1.14179.2.1.4.1.23
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Policy Manager State of the mobile station.
1.3.6.1.4.1.14179.2.1.4.1.24
INTEGER0 = completed1 = notcompleted · Integer32
When this attribute has value completed, it shall indicate that the Mobile Station has completed the security policy checks. Otherwise the checks are yet to be completed.
1.3.6.1.4.1.14179.2.1.4.1.25
INTEGER1 = dot11a2 = dot11b3 = dot11g4 = unknown5 = mobile6 = dot11n247 = dot11n58 = ethernet9 = dot310 = dot11ac · Integer32
The 802.11 protocol type of the client. The protocol is mobile when this client detail is seen on the anchor i.e it's mobility status is anchor.
1.3.6.1.4.1.14179.2.1.4.1.26
INTEGER0 = disable1 = enable · Integer32
If enabled, then mirroring for this client will be statically configured irrespective of the AP and the port this client is on.
1.3.6.1.4.1.14179.2.1.4.1.27
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..32) · OCTET STRING · hint 255a
Name of the Interface of the mobile client to the switch.
1.3.6.1.4.1.14179.2.1.4.1.28
INTEGER0 = local1 = monitor2 = remote3 = roguedetector · Integer32
Mode of the AP to which the Mobile Station is associated.
1.3.6.1.4.1.14179.2.1.4.1.29
Integer32 (0..4096)
Vlan ID of the Interface to which the client is associated.
1.3.6.1.4.1.14179.2.1.4.1.30
INTEGER0 = dot1x1 = wpa12 = wpa23 = wpa2vff4 = notavailable5 = unknown · Integer32
Mode of the AP to which the Mobile Station is associated.
1.3.6.1.4.1.14179.2.1.4.1.31
INTEGER0 = ccmpAes1 = tkipMic2 = wep403 = wep1044 = wep1285 = none6 = notavailable7 = unknown · Integer32
Mode of the AP to which the Mobile Station is associated.
1.3.6.1.4.1.14179.2.1.4.1.32
INTEGER0 = eapTls1 = ttls2 = peap3 = leap4 = speke5 = eapFast6 = notavailable7 = unknown · Integer32
Mode of the AP to which the Mobile Station is associated.
1.3.6.1.4.1.14179.2.1.4.1.33
INTEGER0 = notSupported1 = ccxv12 = ccxv23 = ccxv34 = ccxv45 = ccxv56 = ccxv6 · Integer32
Represents the Cisco Compatible Extensions (CCX) Version the client is using for communication with the AP.
1.3.6.1.4.1.14179.2.1.4.1.34
INTEGER0 = notSupported1 = e2ev12 = e2ev2 · Integer32
Represents the End-2-End Version the client is using for communication with the AP.
1.3.6.1.4.1.14179.2.1.4.1.42
INTEGER (0..65535) · Integer32
Status Code of the Mobile Station
1.3.6.1.4.1.14179.2.1.5
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnDot11EssIndex · bsnMobileStationPerRadioPerVapIndex
Mobile Station Per Radio Per VAP(WLAN) Table. This table lists all Mobile Stations on a particular Airespace AP Interface for a particular ESS(Wlan). It only lists MAC Addresses. Further details for a Mobile Station can be found from bsnMobileStationTable once the MAC Address is knonwn. (Mobile Station is better referred to as Client in the current releases.)
1.3.6.1.4.1.14179.2.1.5.1.1
Integer32
The index of Mobile Station. The index starts from 1 and goes upto the total number of Mobile Stations on Airespace Radio Interface for a specific ESS (Wlan).
1.3.6.1.4.1.14179.2.1.5.1.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC Address of Mobile Station.
1.3.6.1.4.1.14179.2.1.6
Index: bsnMobileStationMacAddress
Mobile Station Statistics Table. (Mobile Station is better referred to as Client in the current releases.)
1.3.6.1.4.1.14179.2.1.6.1.1
Integer32
Average packet RSSI for the Mobile Station.
1.3.6.1.4.1.14179.2.1.6.1.2
Counter64 (0..18446744073709551615)
Bytes received from Mobile Station
1.3.6.1.4.1.14179.2.1.6.1.3
Counter64 (0..18446744073709551615)
Bytes sent to Mobile Station
1.3.6.1.4.1.14179.2.1.6.1.4
Counter64 (0..18446744073709551615)
Number of Policy Errors for Mobile Station
1.3.6.1.4.1.14179.2.1.6.1.5
Counter64 (0..18446744073709551615)
Packets received from Mobile Station
1.3.6.1.4.1.14179.2.1.6.1.6
Counter64 (0..18446744073709551615)
Packets sent to Mobile Station
1.3.6.1.4.1.14179.2.1.6.1.26
Integer32
Signal to noise Ratio of the Mobile Station.
1.3.6.1.4.1.14179.2.1.7
Index: bsnRogueAPDot11MacAddress
Rogue Table. This table lists all the Rogue APs detected by Airespace APs.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.1.7.1.2
Integer32
Total number of Airespace APs that detected this rogue.
1.3.6.1.4.1.14179.2.1.7.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Time Stamp when this Rogue was First Detected.
1.3.6.1.4.1.14179.2.1.7.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Time Stamp when this Rogue was Last Detected.
1.3.6.1.4.1.14179.2.1.7.1.5
INTEGER0 = unassigned1 = level12 = level23 = level34 = level4 · Integer32
If the state of the rogue is contained, this specifies the level of containment. Higher the level, more the number of detecting APs that are used to contain it. The value must be between 1 to 4 for 'contained' state.
1.3.6.1.4.1.14179.2.1.7.1.6
INTEGER0 = ap1 = adhoc · Integer32
This attribute specifies if the Rogue is of ad-hoc type or is an AP.
1.3.6.1.4.1.14179.2.1.7.1.7
INTEGER0 = no1 = yes · Integer32
This attribute specifies if the Rogue is on Wired Network or not.
1.3.6.1.4.1.14179.2.1.7.1.8
Integer32
Total number of Clients detected on this rogue.
1.3.6.1.4.1.14179.2.1.7.1.9
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.1.7.1.10
Integer32
This is the max RSSI value of all the detctecting APs, which have detected this rogue.
1.3.6.1.4.1.14179.2.1.7.1.11
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (1..32) · OCTET STRING · hint 255a
This is the SSID of the rogue detected by Access Point, which has max RSSI value of all the detectecting APs of this rogue.
1.3.6.1.4.1.14179.2.1.7.1.12
BITS
Radio type of detecting APs. If the radio type is detected by dot11bg radio or dot11a radio or both.
1.3.6.1.4.1.14179.2.1.7.1.13
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of of detecting AP which received max RSSI
1.3.6.1.4.1.14179.2.1.7.1.14
INTEGER1 = dot11b2 = dot11a4 = uwb5 = dot11g6 = dot11n247 = dot11n5 · Integer32
The radio type of detecting AP which received max RSSI value.
1.3.6.1.4.1.14179.2.1.7.1.24
INTEGER0 = initializing1 = pending2 = alert3 = detectedLrad4 = known5 = acknowledge6 = contained7 = threat8 = containedPending9 = knownContained10 = trustedMissing · Integer32
This attribute is use to specify the state in which the Rogue AP is user can set the Rogue AP in alert, known or acknowledge state. Alert state means Rogue AP can be a potential threat. Trap will be sent out to trap recipients. Known state means its just internal AP which is not on the same Switch. Acknowledge state means an external AP whose existence is acceptable and not a threat (probably some other company's AP). Contained means containement is initiated and ongoing. Threat is usually the state when the rogue is found on wired network. known(4), knownContained(9) and trustedMissing(10) will appear in known rogue list. known rogues can be pre provisioned and known rogues state can be changed to alert(2)
1.3.6.1.4.1.14179.2.1.7.1.25
INTEGER0 = pending1 = friendly2 = malicious3 = unclassified · Integer32
The AP class type of the client detected.
1.3.6.1.4.1.14179.2.1.7.1.26
Integer32
This is the channel number of the last detecting APs, which has detected this rogue.
1.3.6.1.4.1.14179.2.1.7.1.27
OCTET STRING SIZE (0..32)
AP name of the detecting AP which received max RSSI
1.3.6.1.4.1.14179.2.1.8
Index: bsnRogueAPDot11MacAddress · bsnRogueAPAirespaceAPMacAddress · bsnRogueAPAirespaceAPSlotId
Rogue Station Table. This table lists all the Airespace AP Interfaces that detected a particular Rogue.
1.3.6.1.4.1.14179.2.1.8.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Airespace AP Interface that Detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.2
Unsigned32 (0..2)
The slot ID of the Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.3
INTEGER1 = dot11b2 = dot11a3 = unknown4 = uwb5 = dot11g6 = dot11n247 = dot11n5 · Integer32
The Airespace AP Interface type that detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Name of Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.5
Integer32
The advertised Channel Number of the Airespace AP Interface picked up from the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.6
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The SSID Advertised by Rogue Station.
1.3.6.1.4.1.14179.2.1.8.1.7
Integer32
Rogue RSSI as seen by Airespace AP Interface.
1.3.6.1.4.1.14179.2.1.8.1.8
INTEGER0 = invalid1 = deauthBroadcast2 = cfp3 = max99 = unknown · Integer32
If the rogue is in 'contained' state, this attribute shows the containment mode used by the AP.
1.3.6.1.4.1.14179.2.1.8.1.9
Unsigned32
The number of channels used for rogue containment.
1.3.6.1.4.1.14179.2.1.8.1.10
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
This is the comma separated string of channels used for rogue containment.
1.3.6.1.4.1.14179.2.1.8.1.11
Counter32
No of seconds ago when this Rogue was last heard by this AP.
1.3.6.1.4.1.14179.2.1.8.1.12
INTEGER0 = disabled1 = enabled · Integer32
The WEP mode on this detecting AP.
1.3.6.1.4.1.14179.2.1.8.1.13
INTEGER0 = long1 = short2 = notSupported · Integer32
The Preamble on this detecting AP.
1.3.6.1.4.1.14179.2.1.8.1.14
INTEGER0 = disabled1 = enabled · Integer32
The WPA mode on this detecting AP.
1.3.6.1.4.1.14179.2.1.8.1.27
Integer32
SNR seen by Airespace AP Interface from Rogue
1.3.6.1.4.1.14179.2.1.8.1.28
INTEGER1 = five2 = ten3 = twenty4 = aboveforty5 = belowforty · Integer32
This object represents the channel width of the rogue.
1.3.6.1.4.1.14179.2.1.9
Index: bsnThirdPartyAPMacAddress
Third Party Access Point Table. An entry needs to be configured in this table for a third party access point that needs to be supported by the Switch. Note: A third party ESS (Wlan) with ID 17 should be created in bsnDot11EssTable before adding entries here. Please also note that ACS currently supports only Aironet 350, 1200 and Orinoco 2000 Access Points as third party APs.
1.3.6.1.4.1.14179.2.1.9.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Third Party Access Point which is connected directly to this Airespace Switch.
1.3.6.1.4.1.14179.2.1.9.1.2
Integer32
Interface(Port Number) to which the Third Party AP is connected.
1.3.6.1.4.1.14179.2.1.9.1.3
IpAddress SIZE (4)
Static IP address of the 3rd Party AP, 0.0.0.0 indicating x its using DHCP
1.3.6.1.4.1.14179.2.1.9.1.4
INTEGER0 = disable1 = enable · Integer32
If 802.1X is required for the 3rd Party AP
1.3.6.1.4.1.14179.2.1.9.1.5
INTEGER0 = disable1 = enable · Integer32
If enabled, then data from all the foreign AP users and all the foreign APs on this APs port will be mirrored. These clients are dynamically added to the switch's mirrored MAC list.
1.3.6.1.4.1.14179.2.1.9.1.24
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status in the ThirdPartyAPEntry.
1.3.6.1.4.1.14179.2.1.10
Index: bsnMobileStationByIpAddress
Mobile Station Table indexed by bsnMobileStationByIpAddress. NOTE: This is just to facilitate the search of mobile stations based on IP Address. Doing a get without the index doesn't return anything. (Mobile Station is better referred to as Client in the current releases.)
1.3.6.1.4.1.14179.2.1.10.1.1
IpAddress SIZE (4)
IP Address of the Mobile Station
1.3.6.1.4.1.14179.2.1.10.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
802.11 Mac Address of the Mobile Station.
1.3.6.1.4.1.14179.2.1.11
Index: bsnMobileStationMacAddress · bsnMobileStationRssiDataApMacAddress · bsnMobileStationRssiDataApIfSlotId · bsnAPIfPhyAntennaIndex
Mobile Station RSSI data Table indexed by bsnMobileStationMacAddress, bsnMobileStationRssiDataApMacAddress, bsnMobileStationRssiDataApIfSlotId. (Mobile Station is better referred to as Client in the current releases.)
1.3.6.1.4.1.14179.2.1.11.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
802.11 Mac Address of the AP on which Mobile Station is associated.
1.3.6.1.4.1.14179.2.1.11.1.2
Unsigned32 (0..15)
SlotId of APIf on which mobile station is associated
1.3.6.1.4.1.14179.2.1.11.1.3
INTEGER1 = dot11bg2 = dot11a3 = unknown · Integer32
The interface type of the radio that sensed the rssi data.
1.3.6.1.4.1.14179.2.1.11.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The Name of the AP that sensed the rssi data.
1.3.6.1.4.1.14179.2.1.11.1.5
Integer32
RSSI seen by Airespace AP Interface for the Mobile Station
1.3.6.1.4.1.14179.2.1.11.1.6
Unsigned32
Antenna which recived the probe request from client. The antenna which reported the RSSI value for the client. For now value will be 0 to 1, in future it may change.
1.3.6.1.4.1.14179.2.1.11.1.25
Counter32
No of seconds ago when this RSSI data was recorded.
1.3.6.1.4.1.14179.2.1.12
Index: bsnWatchListClientKey · bsnWatchListClientType
Table of watch listed clients. When clients are added to this table by username or MAC address, ACS collects data for them to show trend reports. The switch generates Client Association and Client Authentication traps for the watch listed clients.The watch list feature can be enbaled or diabled by the bsnWatchListFeatureEnable flag on the switch.
1.3.6.1.4.1.14179.2.1.12.1.1
OCTET STRING SIZE (1..64)
MAC Address or User Name of Client that is to be added to the watch list.
1.3.6.1.4.1.14179.2.1.12.1.2
INTEGER1 = byMac2 = byUserName · Integer32
The type of the watch list client entry. The entry can be created by Client MAC Address or by Username.
1.3.6.1.4.1.14179.2.1.12.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
A row status type for the bsnWatchListClientEntry
1.3.6.1.4.1.14179.2.1.13
Index: bsnMobileStationByUserName · bsnMobileStationByUserMacAddress
Mobile Station Table indexed by the Mobile Station Username and MAC Address. NOTE: This is just to facilitate the search of mobile stations based on User Name. Doing a get without the username doesn't return anything. (Mobile Station is better referred to as Client in the current releases.)
1.3.6.1.4.1.14179.2.1.13.1.1
OCTET STRING SIZE (1..64)
Username of the Mobile Station
1.3.6.1.4.1.14179.2.1.13.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
802.11 Mac Address of the Mobile Station.
1.3.6.1.4.1.14179.2.1.14
Index: bsnRogueClientDot11MacAddress
Rogue Client Table. This table lists all the Rogue Clients detected by Airespace APs.
1.3.6.1.4.1.14179.2.1.14.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
Mac Address of Rogue Station.
1.3.6.1.4.1.14179.2.1.14.1.2
Integer32
Total number of Airespace APs that detected this rogue.
1.3.6.1.4.1.14179.2.1.14.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Time Stamp when this Rogue was First Detected.
1.3.6.1.4.1.14179.2.1.14.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Time Stamp when this Rogue was Last Detected.
1.3.6.1.4.1.14179.2.1.14.1.5
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
This attribute specifies BSSID of the Rogue Client.
1.3.6.1.4.1.14179.2.1.14.1.6
INTEGER0 = unassigned1 = level12 = level23 = level34 = level4 · Integer32
If the state of the rogue is contained, this specifies the level of containment. Higher the level, more the number of detecting APs that are used to contain it. The value must be between 1 to 4 for 'contained' state.
1.3.6.1.4.1.14179.2.1.14.1.7
Integer32
Number of seconds ago this rogue client was detected.
1.3.6.1.4.1.14179.2.1.14.1.24
INTEGER0 = initializing1 = pending2 = alert6 = contained7 = threat8 = containedpending · Integer32
This attribute is use to specify the state in which the Rogue AP is. User can set the Rogue Client in alert,known or acknowledge state. Alert state means Rogue Client can be a potential i threat.Trap will be sent out to trap recipients. Known state means its just internal Client which is not on the same Switch. Acknowledge state means an external Client whose existence is acceptable and not a threat (probably some other company's AP). Contained means containement is initiated and ongoing
1.3.6.1.4.1.14179.2.1.15
Index: bsnRogueClientDot11MacAddress · bsnRogueClientAirespaceAPMacAddress · bsnRogueClientAirespaceAPSlotId
Rogue Station Table. This table lists all the Airespace AP Interface that detected a particular Rogue.
1.3.6.1.4.1.14179.2.1.15.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
Mac Address of Airespace AP Interface that Detected the Rogue.
1.3.6.1.4.1.14179.2.1.15.1.2
Unsigned32 (0..2)
The slotId of the Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.1.15.1.3
INTEGER1 = dot11b2 = dot11a3 = unknown · Integer32
The advertised SSID that the Airespace AP Interface picked up from the Rogue.
1.3.6.1.4.1.14179.2.1.15.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Name of Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.1.15.1.5
Integer32
The advertised Channel Number of that the Airespace AP Interface picked up from the Rogue.
1.3.6.1.4.1.14179.2.1.15.1.7
Integer32
RSSI seen by Airespace AP Interface from the Rogue
1.3.6.1.4.1.14179.2.1.15.1.11
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
No of seconds ago when this Rogue was last heard by this AP.
1.3.6.1.4.1.14179.2.1.15.1.27
Integer32
SNR seen by Airespace AP Interface from Rogue
1.3.6.1.4.1.14179.2.1.16
Index: bsnRogueAPDot11MacAddr · bsnRogueClientDot11MacAddr
Rogue Clients for each rogue. This table lists all Rogue Clients on a particular Rogue.
1.3.6.1.4.1.14179.2.1.16.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC Address of the Rogue AP.
1.3.6.1.4.1.14179.2.1.16.1.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of the Rogue Client.
1.3.6.1.4.1.14179.2.1.17
Index: bsnDot11QosProfileName
QOS Profiles specified in bsnDot11EssTable can be customized in this table. This is a lookup table for auto created profiles
1.3.6.1.4.1.14179.2.1.17.1.1
OCTET STRING SIZE (1..32)
QOS Profile Name. This will be one of bronze,gold, platinum,silver,uranium.
1.3.6.1.4.1.14179.2.1.17.1.2
OCTET STRING SIZE (1..64)
QOS Profile Description.
1.3.6.1.4.1.14179.2.1.17.1.3
INTEGER (0..60000) · Integer32
This is one of the per user bandwidth contracts(k). Specifies Average Data Rate per user. Value of 0 indicates the feature is disabled.
1.3.6.1.4.1.14179.2.1.17.1.4
INTEGER (0..60000) · Integer32
This is one of the per user bandwidth contracts(k). Specifies Average Burst Data Rate per user. Value of 0 indicates the feature is disabled.
1.3.6.1.4.1.14179.2.1.17.1.5
INTEGER (0..60000) · Integer32
This is one of the per user bandwidth contracts(k). Specifies Average Real Time Data Rate per user. Value of 0 indicates the feature is disabled.
1.3.6.1.4.1.14179.2.1.17.1.6
INTEGER (0..60000) · Integer32
This is one of the per user bandwidth contracts(k). Specifies Burst Real Time Data Rate per user. Value of 0 indicates the feature is disabled.
1.3.6.1.4.1.14179.2.1.17.1.7
INTEGER (1..100) · Integer32
This is one of the over the Air QOS parameter. Specifies maximum RF Usage per AP in percentage.
1.3.6.1.4.1.14179.2.1.17.1.8
INTEGER (10..255) · Integer32
This is one of the over the Air QOS parameter. Specifies Queue depth for the current profile.
1.3.6.1.4.1.14179.2.1.17.1.9
INTEGER0 = none1 = dot1p · Integer32
This is one of the over the Air QOS parameter. Specifies Queue depth for the current profile.
1.3.6.1.4.1.14179.2.1.17.1.10
INTEGER (0..7) · Integer32
Specifies the type of wired QOS protocol for the current profile. Value of 0 indicates the feature is disabled.
1.3.6.1.4.1.14179.2.1.17.1.40
INTEGER1 = reset0 = default · Integer32
Set this attribute to reset to restore the factory default value for the profile.
1.3.6.1.4.1.14179.2.1.18
Index: bsnTagDot11MacAddress
RF ID Tag Table indexed by bsnTagDot11MacAddress.
1.3.6.1.4.1.14179.2.1.18.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
802.11 MAC Address of the RF ID Tag.
1.3.6.1.4.1.14179.2.1.18.1.2
INTEGER0 = unknown2 = type1 · Integer32
Type of the RF ID Tag.
1.3.6.1.4.1.14179.2.1.18.1.3
Unsigned32
Time Interval after which the tag transmits data.
1.3.6.1.4.1.14179.2.1.18.1.4
INTEGER0 = unknown1 = low2 = normal3 = medium · Integer32
Battery Status of the RF ID Tag.
1.3.6.1.4.1.14179.2.1.18.1.23
Unsigned32
No of seconds ago when this tag was heard by any AP.
1.3.6.1.4.1.14179.2.1.19
Index: bsnTagDot11MacAddress · bsnTagRssiDataApMacAddress · bsnTagRssiDataApIfSlotId
RF ID Tag Detecting AP Table indexed by bsnTagDot11MacAddress, bsnTagRssiDataApMacAddress and bsnTagRssiDataApIfSlotId.
1.3.6.1.4.1.14179.2.1.19.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
802.11 MAC Address of the AP detecting the RF ID Tag.
1.3.6.1.4.1.14179.2.1.19.1.2
Unsigned32 (0..5)
Slot Id of the radio on AP detecting the RF ID Tag.
1.3.6.1.4.1.14179.2.1.19.1.3
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
Interface Type of the radio on AP detecting the RF ID Tag.
1.3.6.1.4.1.14179.2.1.19.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..32) · OCTET STRING · hint 255a
Name of the AP detecting the RF ID Tag.
1.3.6.1.4.1.14179.2.1.19.1.5
Counter32
No of seconds ago when this tag was heard by this detecting AP.
1.3.6.1.4.1.14179.2.1.19.1.6
Integer32
RSSI of the RF ID Tag as seen by the radio on this detecting AP.
1.3.6.1.4.1.14179.2.1.19.1.26
Integer32
SNR of the RF ID tag as seen by the radio on this detecting AP.
1.3.6.1.4.1.14179.2.1.20
Index: bsnTagDot11MacAddress
RF ID Tag Statistics Table.
1.3.6.1.4.1.14179.2.1.20.1.1
Unsigned32
Bytes received from an RF ID Tag
1.3.6.1.4.1.14179.2.1.20.1.20
Unsigned32
Packets received from an RF ID Tag
1.3.6.1.4.1.14179.2.1.21
Index: bsnMobileStationMacAddress
This table was supported only by indoor mesh AP -cisco 1000. As this AP is not supported after 4.2.x.x. This table has been marked obsolete. Mobile Station Extended Statistics Table. (Mobile Station is better referred to as Client in the current releases.)
1.3.6.1.4.1.14179.2.1.21.1.1
Integer32
Time stats were sampled as seconds since the epoch.
1.3.6.1.4.1.14179.2.1.21.1.2
Counter64 (0..18446744073709551615)
Tx packets dropped due to excessive retries.
1.3.6.1.4.1.14179.2.1.21.1.3
Counter64 (0..18446744073709551615)
Tx packets retransmitted.
1.3.6.1.4.1.14179.2.1.21.1.20
Counter64 (0..18446744073709551615)
Tx packets dropped by the built-in Tx filter
1.3.6.1.4.1.14179.2.2.1
Index: bsnAPDot3MacAddress
Table of Airespace APs managed by this Airespace Switch.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.1.1.2
INTEGER (0..24) · Integer32
Number of Radio Interfaces on the Airespace AP. Currently maximum two interfaces are supported. One would be of type 802.11a and other of type 802.11b/g.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.2.1.1.4
OCTET STRING SIZE (0..80)
User specified location of this AP. While configuring AP, user should specify a location for the AP so that its easy to figure out for some one where the AP is located.
1.3.6.1.4.1.14179.2.2.1.1.5
INTEGER0 = local1 = monitor2 = remote3 = roguedetector4 = sniffer5 = bridge6 = seConnect · Integer32
Monitor Only Mode Setting.
1.3.6.1.4.1.14179.2.2.1.1.6
INTEGER1 = associated2 = disassociating3 = downloading · Integer32
Operation State of the AP. When AP associates with the Airespace Switch its state will be associated. When Airespace AP is disassociated from the Switch, its state will be disassociating. The state is downloading when the AP is downloading its firmware.
1.3.6.1.4.1.14179.2.2.1.1.8
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Major Minor Software Version of AP
1.3.6.1.4.1.14179.2.2.1.1.9
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Major Minor Boot Version of AP
1.3.6.1.4.1.14179.2.2.1.1.10
OCTET STRING SIZE (0..31)
sysName of the Airespace Switch which is suppose to be the Primary MWAR(switch) of the AP with which AP should associate. This work when AP is not directly connected to Airespace Switch, it tries to find Primary Switch and associates with it. If this attribute is left empty or AP is not able to find the Airespace Switch with this name, then it will associate with Secondary Switch.
1.3.6.1.4.1.14179.2.2.1.1.11
INTEGER1 = reset0 = default · Integer32
Set this attribute to reset the AP. When it comes up it will try to associate with the Primary Switch if that is set, else it will associate with the Master Switch. Reading this attribute will always return 0
1.3.6.1.4.1.14179.2.2.1.1.12
INTEGER (0..65535) · Integer32
Configures the time interval in secs after which bsnAPDot11Counters Stats is sent from AP to Switch. If not configured this value is 0 which means never send the stats.
1.3.6.1.4.1.14179.2.2.1.1.13
INTEGER (0..65535) · Integer32
Port on the Switch on which this APs traffic is coming through.
1.3.6.1.4.1.14179.2.2.1.1.16
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
AP Model
1.3.6.1.4.1.14179.2.2.1.1.17
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
AP Serial Number.
1.3.6.1.4.1.14179.2.2.1.1.18
INTEGER1 = clear0 = default · Integer32
Set this attribute to clear AP configuration and reset it to factory defaults. Reading this attribute will always return 0
1.3.6.1.4.1.14179.2.2.1.1.19
IpAddress SIZE (4)
IP address of the AP. This will not be available when the switch is operating in the Layer2 mode. In this case, the attribute will return 0 as value.
1.3.6.1.4.1.14179.2.2.1.1.20
INTEGER0 = disable1 = enable · Integer32
If enabled, then this AP's Client's Data is mirrored and this AP's clients are dynamically added to the switch's mirrored MAC list.
1.3.6.1.4.1.14179.2.2.1.1.21
INTEGER0 = disable1 = enable · Integer32
This specifies if the the Remote Mode is supported on this AP or not. If supported user can set bsnAPMonitorOnlyMode to remote. Otherwise not.
1.3.6.1.4.1.14179.2.2.1.1.22
INTEGER1 = ap10002 = ap10303 = mimo4 = unknown5 = ap11006 = ap11307 = ap12408 = ap12009 = ap131010 = ap150011 = ap125012 = ap150513 = ap320114 = ap152015 = ap80016 = ap114017 = ap800agn18 = ap3500i19 = ap3500e20 = ap126021 = ap104022 = ap155023 = ap602i24 = ap3500p25 = ap802gn26 = ap802agn27 = ap3600i28 = ap3600e29 = ap2600i30 = ap2600e31 = ap802hagn32 = ap1600i33 = ap1600e34 = ap702e35 = ap702i36 = ap3600p37 = ap1530i38 = ap1530e39 = ap3700e40 = ap3700i41 = ap3700p42 = ap2700e43 = ap2700i44 = ap702w45 = wap2600i46 = wap2600e47 = wap1600i48 = wap1600e49 = wap702i50 = wap702e51 = ap1700i52 = ap1700e53 = ap1570e54 = ap1570i · Integer32
This is the model of the AP in enumeration.
1.3.6.1.4.1.14179.2.2.1.1.23
OCTET STRING SIZE (0..31)
sysName of the Airespace Switch which is suppose to be the Secondary MWAR(switch) of the AP with which AP should associate if Primary Switch(configured through bsnAPPrimaryMwarName) is not available. If primary and secondary switches are not available then AP will associate with the tertiary switch.
1.3.6.1.4.1.14179.2.2.1.1.24
OCTET STRING SIZE (0..31)
sysName of the Airespace Switch which is suppose to be the Tertiary MWAR(switch) of the AP with which AP should associate. If primary,secondary and tertiary switch are not available then it will associate with Master Switch.
1.3.6.1.4.1.14179.2.2.1.1.25
INTEGER0 = disable1 = enable · Integer32
This flag when disabled implies that AP will use DHCP to get the IP address. However, if it is enabled, then user should enter the IPAddress, Netmask and Gateway.
1.3.6.1.4.1.14179.2.2.1.1.26
IpAddress SIZE (4)
The Netmask of the IP address of the AP.
1.3.6.1.4.1.14179.2.2.1.1.27
IpAddress SIZE (4)
The Gateway for the AP.
1.3.6.1.4.1.14179.2.2.1.1.28
IpAddress SIZE (4)
The Static IP-Address configuration for the AP. This can only be changed when the LWAPP mode is in Layer-3.
1.3.6.1.4.1.14179.2.2.1.1.29
INTEGER0 = disable1 = enable · Integer32
This specifies if this AP is a Bridging AP. Bridging APs can be used in Bridging or Mesh network configurations.
1.3.6.1.4.1.14179.2.2.1.1.30
OCTET STRING SIZE (0..32)
The AP Group to which this AP has been associated with. If it is empty, then no AP Group overriding has been set.
1.3.6.1.4.1.14179.2.2.1.1.31
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
IOS Version of IOS Cisco AP. Zero length string will be returned for other APs
1.3.6.1.4.1.14179.2.2.1.1.32
INTEGER0 = unknown1 = manufactureinstalled2 = selfsigned3 = localsignificance · Integer32
Enum values denoting AP Certificate Type. 1 : manufactureinstalled : Manufacture Installed Certificate type (MIC). 2 : selfsigned : Self Signed Certificate type (SSC). 3 : localsignificance : Local Significance.
1.3.6.1.4.1.14179.2.2.1.1.33
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The Ethernet MAC address of the AP.
1.3.6.1.4.1.14179.2.2.1.1.37
INTEGER1 = enable2 = disable · Integer32
Admin State of the AP
1.3.6.1.4.1.14179.2.2.2
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Each entry represents an 802.11 interface in an Airespace AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.2.2.1.3
INTEGER1 = automatic2 = customized · Integer32
If this value is true, then bsnAPDot11CurrentChannel in bsnAPIfDot11PhyDSSSTable is assigned by dynamic algorithm and is read-only.
1.3.6.1.4.1.14179.2.2.2.1.4
INTEGER1 = ch12 = ch23 = ch34 = ch45 = ch56 = ch67 = ch78 = ch89 = ch910 = ch1011 = ch1112 = ch1213 = ch1314 = ch1420 = ch2021 = ch2122 = ch2223 = ch2324 = ch2425 = ch2526 = ch2634 = ch3436 = ch3638 = ch3840 = ch4042 = ch4244 = ch4446 = ch4648 = ch4852 = ch5256 = ch5660 = ch6064 = ch64100 = ch100104 = ch104108 = ch108112 = ch112116 = ch116120 = ch120124 = ch124128 = ch128132 = ch132136 = ch136140 = ch140149 = ch149153 = ch153157 = ch157161 = ch161165 = ch165169 = ch169 · Integer32
Current channel number of the AP Interface. Channel numbers will be from 1 to 14 for 802.11b interface type. Channel numbers will be from 34 to 169 for 802.11a interface type. Allowed channel numbers also depends on the current Country Code set in the Switch. This attribute cannot be set unless bsnAPIfPhyChannelAssignment is set to customized else this attribute gets assigned by dynamic algorithm.
1.3.6.1.4.1.14179.2.2.2.1.5
INTEGER1 = automatic2 = customized · Integer32
If this value is true, then bsnAPIfPhyTxPowerLevel is assigned by dynamic algorithm and is read-only.
1.3.6.1.4.1.14179.2.2.2.1.6
INTEGER (1..8) · Integer32
The TxPowerLevel currently being used to transmit data. Some PHYs also use this value to determine the receiver sensitivity requirements for CCA. Valid values are between 1 to 8,depnding on what radio, and this attribute can be set only if bsnAPIfPhyTxPowerControl is set to customized.
1.3.6.1.4.1.14179.2.2.2.1.7
INTEGER1 = sectorA2 = sectorB3 = omni99 = notapplicable · Integer32
Antenna Mode of the AP Interface. For 802.11a this attribute will always be omni for now. This attribute doesn't apply to interface of type 802.11b.
1.3.6.1.4.1.14179.2.2.2.1.8
INTEGER1 = internal2 = external · Integer32
This attribute specified if the Antenna currently used by AP Radio is internal or external. For 802.11a the antenna is always internal. For 802.11b you can set antenna type to be external or internal.
1.3.6.1.4.1.14179.2.2.2.1.9
INTEGER0 = connectorA1 = connectorB255 = enabled · Integer32
Diversity doesn't apply to AP Radio of type 802.11a. For 802.11b you can set it to connectorA, connectorB or enabled.
1.3.6.1.4.1.14179.2.2.2.1.10
Unsigned32
In a cell site configuration, this would be the cell Id of this AP Interface
1.3.6.1.4.1.14179.2.2.2.1.11
INTEGER (1..16) · Integer32
Number of WLANs currently active on this AP Interface.
1.3.6.1.4.1.14179.2.2.2.1.12
INTEGER1 = down2 = up · Integer32
Operational status of the interface.
1.3.6.1.4.1.14179.2.2.2.1.13
INTEGER (0..65535) · Integer32
Port number on Airespace Switch on which the traffic from this AP interface is received.
1.3.6.1.4.1.14179.2.2.2.1.14
INTEGER0 = internalAndExternal1 = internal2 = siacAp3 = external4 = ext11bInt11a · Integer32
This attribute specifies the Antenna types supported by the AP Radio whether it is internal or external or both. internalAndExternal(0)- internal and external antenna for both 11a and 11b internal(1) - only internal antenna is allowed. siacAp- 11b internal and 11a external external - only external antenna is allowed for 11a and 11b ext11bInt11a - external antenna for 11b and internal antenna for 11a.
1.3.6.1.4.1.14179.2.2.2.1.15
Counter32
No of Users associated with this radio.
1.3.6.1.4.1.14179.2.2.2.1.16
INTEGER0 = disable1 = enable · Integer32
This flag when disabled implies that all WLANs are available from this radio. However, if this is enabled, then only those WLANs that appear in the bsnApIfWlanOverrideTable will be available from this radio.
1.3.6.1.4.1.14179.2.2.2.1.17
INTEGER0 = disable1 = enable · Integer32
This flag when enabled implies that AP will sniff the 802.11a/bg packets. However, if it is enabled, then user should enter the server-ip-address on which Airopeek is running and the 802.11a/bg-channel-number to be sniffed. The above feature will work only when AP is in 'Sniffer' mode.
1.3.6.1.4.1.14179.2.2.2.1.18
INTEGER0 = ch01 = ch12 = ch23 = ch34 = ch45 = ch56 = ch67 = ch78 = ch89 = ch910 = ch1011 = ch1112 = ch1213 = ch1314 = ch1420 = ch2021 = ch2122 = ch2223 = ch2324 = ch2425 = ch2526 = ch2634 = ch3436 = ch3638 = ch3840 = ch4042 = ch4244 = ch4446 = ch4648 = ch4852 = ch5256 = ch5660 = ch6064 = ch64100 = ch100104 = ch104108 = ch108112 = ch112116 = ch116120 = ch120124 = ch124128 = ch128132 = ch132136 = ch136140 = ch140149 = ch149153 = ch153157 = ch157161 = ch161165 = ch165169 = ch169 · Integer32
This the 802.11a/bg-channel-number on which AP will sniff the packets.
1.3.6.1.4.1.14179.2.2.2.1.19
IpAddress SIZE (4)
The machine ip address on which Airopeek application is running.
1.3.6.1.4.1.14179.2.2.2.1.20
INTEGER (0..40) · Integer32
Represents antenna gain in multiple of 0.5 dBm. An integer value 4 means 4 x 0.5 = 2 dBm of gain
1.3.6.1.4.1.14179.2.2.2.1.21
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
List of comma separated channels supported by this radio.
1.3.6.1.4.1.14179.2.2.2.1.22
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
List of comma separated absolute power levels supported by this radio.
1.3.6.1.4.1.14179.2.2.2.1.23
INTEGER0 = notSupported1 = supported · Integer32
If the regulatory domain on radio is supported or notSupported on the controller
1.3.6.1.4.1.14179.2.2.2.1.34
INTEGER2 = disable1 = enable · Integer32
Admin status of the interface.
1.3.6.1.4.1.14179.2.2.3
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Each entry represents SMT parameters on an 802.11 interface of an Airespace AP.
1.3.6.1.4.1.14179.2.2.3.1.1
INTEGER (20..1000) · Integer32
This attribute shall specify the number of TU that a AP Interface shall use for scheduling Beacon tranmissions. This value is transmitted in Beacon and Probe Response frames.
1.3.6.1.4.1.14179.2.2.3.1.2
INTEGER (0..1000) · Integer32
This attribute shall indicate the maximum amount of time, in TU, that a point coordinator may control the usage of the wireless medium without relinquishing control for long enough to allow at least one instance of DCF access to the medium. The default value of this attribute shall be 100, and the maximum value shall be 1000.
1.3.6.1.4.1.14179.2.2.3.1.3
INTEGER (0..255) · Integer32
The attribute shall describe the number of DTIM intervals between the start of CFPs. It is modified by MLME-START.request primitive.
1.3.6.1.4.1.14179.2.2.3.1.4
INTEGER (0..65535) · Integer32
The attribute shall describe the maximum duration of the CFP in TU that may be generated by the PCF. It is modified by MLME-START.request primitive.
1.3.6.1.4.1.14179.2.2.3.1.5
OCTET STRING SIZE (1..126)
This attribute shall specify the set of data rates at which the AP Interface may transmit data. Each octet contains a value representing a rate. Each rate shall be within the range from 2 to 127, corresponding to data rates in increments of 500 kb/s from 1 Mb/s to 63.5 Mb/s, and shall be supported (as indicated in the supported rates table) for receiving data. This value is reported in transmitted Beacon, Probe Request, Probe Response, Association Request, Association Response, Reassociation Request, and Reassociation Response frames, and is used to determine whether a BSS with which the AP Interface desires to synchronize is suitable. It is also used when starting a BSS, as specified in 10.3.
1.3.6.1.4.1.14179.2.2.3.1.6
INTEGER (1..255) · Integer32
This attribute shall specify the number of beacon intervals that shall elapse between transmission of Beacons frames containing a TIM element whose DTIM Count field is 0. This value is transmitted in the DTIM Period field of Beacon frames.
1.3.6.1.4.1.14179.2.2.3.1.7
INTEGER0 = notimplemented1 = implemented · Integer32
This attribute, when TRUE, indicates that the AP Interface implementation is capable of supporting multiple regulatory domains. The capability is disabled, otherwise. The default value of this attribute is FALSE.
1.3.6.1.4.1.14179.2.2.3.1.8
INTEGER0 = no1 = yes · Integer32
This attribute, when TRUE, indicates that the capability of the AP Interface to operate in multiple regulatory domains is enabled. The capability is disabled, otherwise. The default value of this attribute is FALSE.
1.3.6.1.4.1.14179.2.2.3.1.9
OCTET STRING SIZE (3)
This attribute identifies the country in which the AP Interface is operating. The first two octets of this string is the two character country code as described in document ISO/IEC 3166-1. The third octet shall be one of the following: 1. an ASCII space character, if the regulations under which the AP Interface is operating encompass all environments in the country, 2. an ASCII 'O' character, if the regulations under which the AP Interface is operating are for an Outdoor environment only, or 3. an ASCII 'I' character, if the regulations under which the AP Interface is operating are for an Indoor environment only.
1.3.6.1.4.1.14179.2.2.3.1.10
INTEGER0 = automatic1 = customized · Integer32
This attribute suggests if the Station parameters for this radio are automatically set or have been customized.
1.3.6.1.4.1.14179.2.2.3.1.30
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
BSSID of this AP config which would be the MAC Address of AP
1.3.6.1.4.1.14179.2.2.4
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Each entry represents an 803.2 or an 802.11 interface in an Airespace AP.
1.3.6.1.4.1.14179.2.2.4.1.1
Integer32
This attribute shall indicate the maximum transmit power, in dBm, allowed in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.2.4.1.2
Integer32
This attribute shall indicate the value of the lowest channel number in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.2.4.1.20
Integer32
This attribute shall indicate the value of the total number of channels allowed in the subband for the associated domain country string. The default value of this attribute shall be zero.
1.3.6.1.4.1.14179.2.2.5
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Group contains MAC attributes pertaining to the operation of the MAC. These would be read only attributes as they would be updated by RRM Dynamic Algorithm. If user needs to configure them then they can only be configured globally
1.3.6.1.4.1.14179.2.2.5.1.1
INTEGER (0..2347) · Integer32
If bsnAPIfMacParamsAutomaticOn is true then this is read only parameter updated by RRM dynamic algorithm
1.3.6.1.4.1.14179.2.2.5.1.2
INTEGER (1..255) · Integer32
If bsnAPIfMacParamsAutomaticOn is true then this is read only parameter updated by RRM dynamic algorithm
1.3.6.1.4.1.14179.2.2.5.1.3
INTEGER (1..255) · Integer32
If bsnAPIfMacParamsAutomaticOn is true then this is read only parameter updated by RRM dynamic algorithm
1.3.6.1.4.1.14179.2.2.5.1.4
INTEGER (256..2346) · Integer32
If bsnAPIfMacParamsAutomaticOn is true then this is read only parameter updated by RRM dynamic algorithm
1.3.6.1.4.1.14179.2.2.5.1.5
Unsigned32 (1..4294967295)
If bsnAPIfMacParamsAutomaticOn is true then this is read only parameter updated by RRM dynamic algorithm
1.3.6.1.4.1.14179.2.2.5.1.6
INTEGER0 = automatic1 = customized · Integer32
This attribute suggests if the MAC parameters for this radio are automatically set or have been customized.
1.3.6.1.4.1.14179.2.2.5.1.25
Unsigned32 (1..4294967295)
If bsnAPIfMacParamsAutomaticOn is true then this is read only parameter updated by RRM dynamic algorithm
1.3.6.1.4.1.14179.2.2.6
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Group containing attributes that are MAC counters. Each instance represents counters on a AP dot11 interface
1.3.6.1.4.1.14179.2.2.6.1.1
Counter32
This counter shall be incremented for an acknowledged MPDU with an individual address in the address 1 field or an MPDU with a multicast address in the address 1 field of type Data or Management.
1.3.6.1.4.1.14179.2.2.6.1.2
Counter32
This counter shall increment only when the multicast bit is set in the destination MAC address of a successfully transmitted MSDU. When operating as a STA in an ESS, where these frames are directed to the AP, this implies having received an acknowledgment to all associated MPDUs.
1.3.6.1.4.1.14179.2.2.6.1.3
Counter32
This counter shall increment when an MSDU is successfully transmitted after one or more retransmissions.
1.3.6.1.4.1.14179.2.2.6.1.4
Counter32
This counter shall increment when an MSDU is successfully transmitted after more than one retransmission.
1.3.6.1.4.1.14179.2.2.6.1.5
Counter32
This counter shall increment when a frame is received that the Sequence Control field indicates is a duplicate.
1.3.6.1.4.1.14179.2.2.6.1.6
Counter32
This counter shall increment when a CTS is received in response to an RTS.
1.3.6.1.4.1.14179.2.2.6.1.7
Counter32
This counter shall increment when a CTS is not received in response to an RTS.
1.3.6.1.4.1.14179.2.2.6.1.8
Counter32
This counter shall increment when an ACK is not received when expected.
1.3.6.1.4.1.14179.2.2.6.1.9
Counter32
This counter shall be incremented for each successfully received MPDU of type Data or Management.
1.3.6.1.4.1.14179.2.2.6.1.10
Counter32
This counter shall increment when a MSDU is received with the multicast bit set in the destination MAC address.
1.3.6.1.4.1.14179.2.2.6.1.11
Counter32
This counter shall increment when an FCS error is detected in a received MPDU.
1.3.6.1.4.1.14179.2.2.6.1.12
Counter32
This counter shall increment for each successfully transmitted MSDU.
1.3.6.1.4.1.14179.2.2.6.1.13
Counter32
This counter shall increment when a frame is received with the WEP subfield of the Frame Control field set to one and the WEPOn value for the key mapped to the TA's MAC address indicates that the frame should not have been encrypted or that frame is discarded due to the receiving STA not implementing the privacy option.
1.3.6.1.4.1.14179.2.2.6.1.33
Counter32
This counter shall increment when an MSDU is not transmitted successfully due to the number of transmit attempts exceeding either the bsnAPIfDot11ShortRetryLimit or dot11LongRetryLimit.
1.3.6.1.4.1.14179.2.2.8
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Group of attributes for bsnAPIfDot11PhyTxPowerTable. Implemented as a table indexed on STA ID to allow for multiple instances on an Agent. This table has been deprecated. The level and power can be obtained from bsnAPIfTable(bsnAPIfAbsolutePowerList).
1.3.6.1.4.1.14179.2.2.8.1.1
INTEGER (1..8) · Integer32
The number of power levels supported by the PMD. This attribute can have a value of 1 to 8.
1.3.6.1.4.1.14179.2.2.8.1.2
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL1 in mW. This is also the default power level. It is same as the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.8.1.3
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL2 in mW. It is 1/2 of the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.8.1.4
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL3 in mW. It is 1/4th of the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.8.1.5
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL4 in mW. It is 1/8th of the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.8.1.6
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL5 in mW. It is 1/16th of the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.8.1.7
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL6 in mW. It is 1/32th of the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.8.1.8
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL7 in mW. It is 1/64th of the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.8.1.28
INTEGER (0..10000) · Integer32
The transmit output power for LEVEL8 in mW. It is 1/128th of the Maximum power level available on an AP interface.
1.3.6.1.4.1.14179.2.2.9
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Entry of attributes for bsnAPIfDot11PhyChannelEntry. Implemented as a table indexed on bsnAPDot3MacAddress, bsnAPIfSlotId allow for multiple instances on an Agent
1.3.6.1.4.1.14179.2.2.9.1.1
INTEGER1 = edonly2 = csonly4 = edandcs8 = cswithtimer16 = hrcsanded · Integer32
The current CCA method in operation.Valid values are: energy detect only (edonly) = 01, carrier sense only (csonly) = 02, carrier sense and energy detect (edandcs)= 04 carrier sense with timer (cswithtimer)= 08 high rate carrier sense and energy detect (hrcsanded)=16.
1.3.6.1.4.1.14179.2.2.9.1.2
Integer32
The current Energy Detect Threshold being used by the Channel PHY.
1.3.6.1.4.1.14179.2.2.9.1.23
Integer32
The Threshold being used to detect a busy medium (frequency). CCA shall report a busy medium upon detecting the RSSI above this threshold.
1.3.6.1.4.1.14179.2.2.12
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
Table of attributes for various thresholds to be set on each Airespace AP Interface for Load performance profile , interference performance profile and Noise performance profile.
1.3.6.1.4.1.14179.2.2.12.1.1
INTEGER1 = automatic2 = customized · Integer32
If this value is automatic then Profile Parameters in bsnRrmDot11aAPProfile at the global level will be used. If this value is customized then Profile Parameters in bsnAPIfProfileThresholdConfig Table will be used and user can customize them per AP.
1.3.6.1.4.1.14179.2.2.12.1.2
INTEGER (0..100) · Integer32
foreign interference threshold between 0 and 100 percent.
1.3.6.1.4.1.14179.2.2.12.1.3
INTEGER (-127..0) · Integer32
foreign noise threshold between -100 and -50 dBm.
1.3.6.1.4.1.14179.2.2.12.1.4
INTEGER (0..100) · Integer32
RF utlization threshold between 0 and 100 percent.
1.3.6.1.4.1.14179.2.2.12.1.5
Unsigned32 (1000..1000000)
Airespace AP data-rate threshold between 1000 and 100000
1.3.6.1.4.1.14179.2.2.12.1.6
INTEGER (1..75) · Integer32
Airespace AP mobiles threshold between 1 and 75
1.3.6.1.4.1.14179.2.2.12.1.7
INTEGER (3..50) · Integer32
Airespace AP coverage threshold between 3 and 50
1.3.6.1.4.1.14179.2.2.12.1.8
INTEGER (1..75) · Integer32
Airespace AP mobile minimum exception level between 1 and 1000
1.3.6.1.4.1.14179.2.2.12.1.28
INTEGER (0..100) · Integer32
Airespace AP coverage exception level between 0 and 100 percent.
1.3.6.1.4.1.14179.2.2.13
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
These are RRM performance related read only parameters per Airespace AP
1.3.6.1.4.1.14179.2.2.13.1.1
INTEGER (0..100) · Integer32
This is the percentage of time the Airespace AP receiver is busy operating on packets. It is a number from 0-100 representing a load from 0 to 1.
1.3.6.1.4.1.14179.2.2.13.1.2
INTEGER (0..100) · Integer32
This is the percentage of time the Airespace AP transmitter is busy operating on packets. It is a number from 0-100 representing a load from 0 to 1.
1.3.6.1.4.1.14179.2.2.13.1.3
INTEGER (0..100) · Integer32
Channel Utilization
1.3.6.1.4.1.14179.2.2.13.1.4
Integer32
This is the number of clients attached to this Airespace AP at the last measurement interval(This comes from APF)
1.3.6.1.4.1.14179.2.2.13.1.24
Integer32
This is the number of clients with poor SNR attached to this Airespace AP at the last measurement interval ( This comes from APF ).
1.3.6.1.4.1.14179.2.2.14
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnAPIfInterferenceChannelNo
This is a table of channel information like interference and noise from other 802.11 networks on each channel.
1.3.6.1.4.1.14179.2.2.14.1.1
Integer32
Channel Number on AP
1.3.6.1.4.1.14179.2.2.14.1.2
Integer32
Power of Interference from other 802.11 networks on this channel
1.3.6.1.4.1.14179.2.2.14.1.22
INTEGER (0..100) · Integer32
Interference from other 802.11 networks on this channel
1.3.6.1.4.1.14179.2.2.15
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnAPIfNoiseChannelNo
This is a table of channel information like interference and noise from other 802.11 networks on each channel.
1.3.6.1.4.1.14179.2.2.15.1.1
Integer32
Channel Number on AP
1.3.6.1.4.1.14179.2.2.15.1.21
Integer32
This is the average noise power in dBm on each channel that is available to Airespace AP
1.3.6.1.4.1.14179.2.2.16
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
This is a table of state of interference monitor on each Airespace AP
1.3.6.1.4.1.14179.2.2.16.1.1
ProfileState0 = fail1 = passThis object indicates the profile state. · Integer32
This field represents the current state of the LOAD monitor. This is a total measurement of the business of this Airespace AP. PASS indicates that this Airespace AP is performing adequately compared to the Airespace AP profile. FAIL indicates the Airespace AP is not performing adequately against the LOAD profile.
1.3.6.1.4.1.14179.2.2.16.1.2
ProfileState0 = fail1 = passThis object indicates the profile state. · Integer32
This field represents the current state of Interference monitor. This is a total measurement of the interference present at this Airespace AP. PASS indicates that this Airespace AP is performing adequately compared to the Interference profile. FAIL indicates the Airespace AP is not performing adequately against the Interference profile.
1.3.6.1.4.1.14179.2.2.16.1.3
ProfileState0 = fail1 = passThis object indicates the profile state. · Integer32
This field represents the current state of Noise monitor. This is a total measurement of the noise present at this Airespace AP. PASS indicates that this Airespace AP is performing adequately compared to the noise profile. FAIL indicates the Airespace AP is not performing adequately against the noise profile.
1.3.6.1.4.1.14179.2.2.16.1.24
ProfileState0 = fail1 = passThis object indicates the profile state. · Integer32
This field represents the current state of coverage monitor. This is a total measurement of the client coverage at this Airespace AP. PASS indicates that this Airespace AP is performing adequately compared to the coverage profile. FAIL indicates the Airespace AP is not performing adequately against the coverage profile.
1.3.6.1.4.1.14179.2.2.17
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnAPIfRxNeighborMacAddress
This is a table of Rx Neighbors for each Airespace AP with their RSSI value.
1.3.6.1.4.1.14179.2.2.17.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rx Neighbor of the Airespace AP
1.3.6.1.4.1.14179.2.2.17.1.2
IpAddress SIZE (4)
IP Address of Rx Neighbor of the Airespace AP
1.3.6.1.4.1.14179.2.2.17.1.3
Integer32
RSSI value of the Rx Neighbor
1.3.6.1.4.1.14179.2.2.17.1.24
Integer32
Slot value of the Rx Neighbor
1.3.6.1.4.1.14179.2.2.17.1.26
Integer32
This object represents Channel information which neighboring Access point is using.
1.3.6.1.4.1.14179.2.2.17.1.27
INTEGER1 = five2 = ten3 = twenty4 = aboveforty5 = belowforty · Integer32
This object represents Channel bandwidth information which neighboring Access point is using.
1.3.6.1.4.1.14179.2.2.18
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnAPIfStationRSSICoverageIndex
This is a table of channel information like interference and noise from other 802.11 networks on each channel.
1.3.6.1.4.1.14179.2.2.18.1.1
Integer32
RSSI Coverage Index on AP
1.3.6.1.4.1.14179.2.2.18.1.2
Integer32
RSSI Level
1.3.6.1.4.1.14179.2.2.18.1.23
Integer32
Number of stations on this RSSI Level
1.3.6.1.4.1.14179.2.2.19
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnAPIfStationSNRCoverageIndex
This is a table of Signal to Noise ratio Coverage information on an AP Interface.
1.3.6.1.4.1.14179.2.2.19.1.1
Integer32
SNR Coverage Index on AP
1.3.6.1.4.1.14179.2.2.19.1.2
Integer32
SNR Level
1.3.6.1.4.1.14179.2.2.19.1.23
Integer32
Number of stations on this SNR Level
1.3.6.1.4.1.14179.2.2.20
Index: bsnAPDot3MacAddress · bsnAPIfSlotId
This table list Best Channel,Best TxPowerLevel, Best RTSThreshold,Best FragmentationThreshold etc for this AP Interface as determined by RRM.
1.3.6.1.4.1.14179.2.2.20.1.1
Integer32
Recommended ChannelNumber by RRM for this APIf
1.3.6.1.4.1.14179.2.2.20.1.2
Integer32
Recommended TxPowerLevel by RRM for this APIf
1.3.6.1.4.1.14179.2.2.20.1.3
Integer32
Recommended RTSThreshold by RRM for this APIf
1.3.6.1.4.1.14179.2.2.20.1.24
Integer32
Recommended Fragmentation Threshold by RRM for this APIf
1.3.6.1.4.1.14179.2.2.21
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnAPIfWlanOverrideId
Each entry represents an SSID added to the AP when the attribute bsnAPIfWlanOverride on the radio is enabled. This means only those WLANs on the switch that are added to this table will be available on such a radio.
1.3.6.1.4.1.14179.2.2.21.1.1
Unsigned32 (1..16)
Index of the WLAN (bsnDot11EssIndex) added to the radio. Airespace Switch supports 16 Airespace WLANs so index will be from 1 to 16.
1.3.6.1.4.1.14179.2.2.21.1.2
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (1..32) · OCTET STRING · hint 255a
SSID assigned to the override WLAN.
1.3.6.1.4.1.14179.2.2.21.1.15
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
A row status type for the bsnAPIfWlanOverrideEntry
1.3.6.1.4.1.14179.2.2.22
Index: bsnAPDot3MacAddress
This is a table of mesh nodes.
1.3.6.1.4.1.14179.2.2.22.1.1
INTEGER0 = pap1 = rap · Integer32
the role of this AP
1.3.6.1.4.1.14179.2.2.22.1.2
OCTET STRING SIZE (0..10)
the bridge group name of this AP
1.3.6.1.4.1.14179.2.2.22.1.3
INTEGER0 = dot11a1 = dot11b2 = dot11g · Integer32
the backhaul radio device for this AP
1.3.6.1.4.1.14179.2.2.22.1.4
INTEGER0 = auto1 = dot11a2 = dot11b3 = dot11g · Integer32
the backhaul
1.3.6.1.4.1.14179.2.2.22.1.5
INTEGER0 = dot11a1 = dot11b2 = dot11g · Integer32
the backhaul radio device for this AP
1.3.6.1.4.1.14179.2.2.22.1.6
Integer32
this nodes backhaul data rate
1.3.6.1.4.1.14179.2.2.22.1.7
Integer32
this nodes backhaul channel
1.3.6.1.4.1.14179.2.2.22.1.8
INTEGER1 = start2 = seek3 = sync4 = auth5 = maint · Integer32
routing state
1.3.6.1.4.1.14179.2.2.22.1.9
Counter32
the number of malformed neighbor packets.
1.3.6.1.4.1.14179.2.2.22.1.10
Counter32
poor neighbor snr
1.3.6.1.4.1.14179.2.2.22.1.11
Counter32
the number of blacklist packets received
1.3.6.1.4.1.14179.2.2.22.1.12
Counter32
occurences of insufficient memory conditions
1.3.6.1.4.1.14179.2.2.22.1.13
Counter32
Rx neighbor requests
1.3.6.1.4.1.14179.2.2.22.1.14
Counter32
Rx neighbor responses
1.3.6.1.4.1.14179.2.2.22.1.15
Counter32
Tx neighbor requests
1.3.6.1.4.1.14179.2.2.22.1.16
Counter32
Tx neighbor responses
1.3.6.1.4.1.14179.2.2.22.1.17
Counter32
number of parent changes
1.3.6.1.4.1.14179.2.2.22.1.18
Counter32
number of neighbor timeouts
1.3.6.1.4.1.14179.2.2.22.1.19
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
parents mac addressed
1.3.6.1.4.1.14179.2.2.22.1.20
INTEGER5 = indoorBridge6 = outdoorBridge · Integer32
the type of AP
1.3.6.1.4.1.14179.2.2.22.1.21
INTEGER0 = disable1 = enable · Integer32
enable : Enables ethernet bridging on the AP. disable : Disables ethernet bridging on the AP. Changes are only applicable when AP is in 'Bridge' mode.
1.3.6.1.4.1.14179.2.2.22.1.30
Integer32
number of hops to rap
1.3.6.1.4.1.14179.2.2.23
Index: bsnAPDot3MacAddress · bsnMeshNeighMacAddress
This is a table of mesh neighbors.
1.3.6.1.4.1.14179.2.2.23.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of neighbor
1.3.6.1.4.1.14179.2.2.23.1.2
INTEGER0 = parent1 = tentparent2 = neigh3 = blacklisted4 = child · Integer32
neighbor type
1.3.6.1.4.1.14179.2.2.23.1.3
INTEGER0 = updated1 = needupdate · Integer32
neighbor state
1.3.6.1.4.1.14179.2.2.23.1.4
Integer32
explicitly set SNR
1.3.6.1.4.1.14179.2.2.23.1.5
Integer32
snr up
1.3.6.1.4.1.14179.2.2.23.1.6
Integer32
snr down
1.3.6.1.4.1.14179.2.2.23.1.7
Integer32
link snr
1.3.6.1.4.1.14179.2.2.23.1.8
Integer32
hops adjusted ease
1.3.6.1.4.1.14179.2.2.23.1.9
Integer32
ease to root AP from this AP
1.3.6.1.4.1.14179.2.2.23.1.10
Integer32
unadjusted ease received in last hello
1.3.6.1.4.1.14179.2.2.23.1.11
Counter32
tx packets to this node while a parent
1.3.6.1.4.1.14179.2.2.23.1.12
Counter32
rx packets from this node while a parent
1.3.6.1.4.1.14179.2.2.23.1.13
Counter32
packets with poor snr received from this node
1.3.6.1.4.1.14179.2.2.23.1.14
Integer32
last received hello from this neighbor
1.3.6.1.4.1.14179.2.2.23.1.20
Integer32
when this node last became parent
1.3.6.1.4.1.14179.2.2.24
Index: bsnAPDot3MacAddress · bsnAPIfSlotId · bsnAPIfRadarDetectedChannelNumber
This is a table of channel information on which radar signal were detected. This will give the list of channels and last heard timestamp. Radar signals are detected only on 5Ghz range. So this will be detected for 802.11a interface.
1.3.6.1.4.1.14179.2.2.24.1.1
Integer32
Channel Number on which radar signals were detected.
1.3.6.1.4.1.14179.2.2.24.1.2
Integer32 · seconds
This tells how many seconds ago radar signal was heard on the channel.
1.3.6.1.4.1.14179.2.3.1.42.1
Index: bsnStandardSignaturePrecedence
The table listing Standard Signatures configured on the switch. The standard signatures are provided with the released product. The standard signatures can be updated via file download to the switch. The table is indexed by the precedence of the signatures.
1.3.6.1.4.1.14179.2.3.1.42.1.1.1
Unsigned32 (1..100)
Precedence of the signature. This specifies the order in which the signature is applied to a packet.
1.3.6.1.4.1.14179.2.3.1.42.1.1.2
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..20) · OCTET STRING · hint 255a
This attribute is used to configure the name on a signature.
1.3.6.1.4.1.14179.2.3.1.42.1.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..100) · OCTET STRING · hint 255a
This attribute is used to configure the description of a signature.
1.3.6.1.4.1.14179.2.3.1.42.1.1.4
INTEGER0 = management1 = data · Integer32
This attribute specifies the type of frame that needs to match a signature.
1.3.6.1.4.1.14179.2.3.1.42.1.1.5
INTEGER0 = none1 = report2 = contain3 = exclude · Integer32
This attribute specifies the action to be taken once a packet is found to match a signature.
1.3.6.1.4.1.14179.2.3.1.42.1.1.6
INTEGER0 = disabled1 = enabled · Integer32
This attribute specifies the state of a signature. It is used to match packets only if the state is enabled.
1.3.6.1.4.1.14179.2.3.1.42.1.1.7
Unsigned32 (0..65535)
This specifies the frequency of the matching packets after which the specified action is taken.
1.3.6.1.4.1.14179.2.3.1.42.1.1.8
Unsigned32 (0..65535)
This specifies the quiet time in seconds during which no matching packets are found after which the attack is considered stopped.
1.3.6.1.4.1.14179.2.3.1.42.1.1.9
Unsigned32 (0..128)
This specifies the signature version.
1.3.6.1.4.1.14179.2.3.1.42.1.1.10
INTEGER0 = pattern1 = protocol · Integer32
This attribute specifies the type of Signature configuration. It's protocol when the protocol format is used in the UI to configure this. Pattern is the config type for all signatures in the released signature file and when signatures are configured using pattern format. Note: the signatures will be allowed to be i configured in later releases.
1.3.6.1.4.1.14179.2.3.1.42.1.1.11
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
This object configures the status of a particular standard signature on LWAPP APs, for use in performing signature analysis on the received 802.11 data and/or management frames. A value of 'true' makes the Controller send the 'Signature Add LWAPP Message' to all the joined APs with the status field set to 'enable'. This makes the joined APs perform signature analysis on the received 802.11 data and/or management frames and report the discrepancies observed, if any, to the Controller. A value of 'false' makes the Controller send the 'Signature Add LWAPP Message' to all the joined APs with the status field set to 'disable'. The joined APs doesn't perform the signature analysis on the received 802.11 data and/or management frames for this particular signature, till the signature is enabled.
1.3.6.1.4.1.14179.2.3.1.42.1.1.12
BsnTxtSignatureMacInfo0 = bsnSignatureMacAll1 = bsnSignatureMacIndividual2 = bsnSignatureMacBothThis textual convention defines the pattern followed by the LWAPP APs to perform signature analysis with the signature and report the results to the Controller. The semantics are described as follows. bsnSignatureMacAll - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported on a per-signature and per-channel basis. bsnSignatureMacIndividual - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported separately for individual MAC addresses, that are the sources of the received 802.11 data and/or management frames. bsnStandardSigMacBoth - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked on a per signature as well as per-MAC address basis. · Integer32
This object defines the pattern followed by the LWAPP APs to perform signature analysis with this Standard signature and report the results to the Controller.
1.3.6.1.4.1.14179.2.3.1.42.1.1.13
Unsigned32 (0..65535)
This object specifies the frequency of matching packets from a particular source after which the specified action is taken.
1.3.6.1.4.1.14179.2.3.1.42.1.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion. Signature will allowed to be created, deleted and edited in later releases.
1.3.6.1.4.1.14179.2.3.1.42.1.1.21
Unsigned32 (1..3600)
Interval of the signature. This specifies the interval when the signature is applied to a packet.
1.3.6.1.4.1.14179.2.3.1.42.2
Index: bsnStandardSignaturePrecedence · bsnStandardSignaturePatternIndex
The table listing the matching patterns specified for a i Standard Signature. These are instrumental in matching the signature with a packet. A maximum of 5 i patterns may be specifed for a signature. These are used for matching in the order of their index.
1.3.6.1.4.1.14179.2.3.1.42.2.1.1
Unsigned32 (1..5)
Index of the pattern. This specifies the order in which the pattern is checked against the packet contents.
1.3.6.1.4.1.14179.2.3.1.42.2.1.2
Unsigned32 (0..128)
Offset from the start of the packet where the AP looks for a match to the pattern.
1.3.6.1.4.1.14179.2.3.1.42.2.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..62) · OCTET STRING · hint 255a
This is the pattern string that the AP uses to match at the offset. Example: 0x616c7068615f3178
1.3.6.1.4.1.14179.2.3.1.42.2.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..62) · OCTET STRING · hint 255a
This is the pattern mask. This is the bit mask that the AP uses to mask out the bits in the packet at the given offset. Example: 0xffffffffffffffff
1.3.6.1.4.1.14179.2.3.1.42.2.1.5
BsnSignaturePatternOffSetStart0 = sigPattStartFrm1 = sigPattStartFrmBodyThis object indicates how an offset should be applied while doing signature analysis for QOS and non-QOS data frames. This is introduced since 802.11e QOS frames have an additional 2-byte QOS header which results in the current implementation not being able to find the start of the date frames for signature analysis. The semantics of the values are as follows. sigPattStartFrm - This indicates that the required offset should be applied to the start of the data frame, before performing pattern matching of the signature on the data frame. sigPattStartFrmBody - This value indicates that the required offset should be applied to the start of the frame body, after the header, before performing pattern matching of the signature on the data frame. · Integer32
This object indicates how an offset should be applied while doing signature analysis for QOS and non-QOS data frames with this standard signature.
1.3.6.1.4.1.14179.2.3.1.42.2.1.15
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion. Signature Pattern will allowed to be created, deleted and edited in later releases.
1.3.6.1.4.1.14179.2.3.1.42.3
Index: bsnCustomSignaturePrecedence
The table listing Standard Signatures configured on the switch. The standard signatures are provided with the released product. The standard signatures can be updated via file download to the switch. The table is indexed by the precedence of the signatures.
1.3.6.1.4.1.14179.2.3.1.42.3.1.1
Unsigned32 (1..100)
Precedence of the signature. This specifies the order in which the signature is applied to a packet.
1.3.6.1.4.1.14179.2.3.1.42.3.1.2
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..20) · OCTET STRING · hint 255a
This attribute is used to configure the name on a signature.
1.3.6.1.4.1.14179.2.3.1.42.3.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..100) · OCTET STRING · hint 255a
This attribute is used to configure the description of a signature.
1.3.6.1.4.1.14179.2.3.1.42.3.1.4
INTEGER0 = management1 = data · Integer32
This attribute specifies the type of frame that needs to match a signature.
1.3.6.1.4.1.14179.2.3.1.42.3.1.5
INTEGER0 = none1 = report2 = contain3 = exclude · Integer32
This attribute specifies the action to be taken once a packet is found to match a signature.
1.3.6.1.4.1.14179.2.3.1.42.3.1.6
INTEGER0 = disabled1 = enabled · Integer32
This attribute specifies the state of a signature. It is used to match packets only if the state is enabled.
1.3.6.1.4.1.14179.2.3.1.42.3.1.7
Unsigned32 (0..65535)
This specifies the frequency of the matching packets after which the specified action is taken.
1.3.6.1.4.1.14179.2.3.1.42.3.1.8
Unsigned32 (0..65535)
This specifies the quiet time in seconds during which no matching packets are found after which the attack is considered stopped.
1.3.6.1.4.1.14179.2.3.1.42.3.1.9
Unsigned32 (0..128)
This specifies the signature version.
1.3.6.1.4.1.14179.2.3.1.42.3.1.10
INTEGER0 = pattern1 = protocol · Integer32
This attribute specifies the type of Signature configuration. It's protocol when the protocol format is used in the UI to configure this. Pattern is the config type for all signatures in the released signature file and when signatures are configured using pattern format. Note: the signatures will be allowed to be configured in later releases.
1.3.6.1.4.1.14179.2.3.1.42.3.1.11
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
This object configures the status of a particular Custom signature on LWAPP APs, for use in performing signature analysis on the received 802.11 data and/or management frames. A value of 'true' makes the Controller send the 'Signature Add LWAPP Message' to all the joined APs with the status field set to 'enable'. This makes the joined APs perform signature analysis on the received 802.11 data and/or management frames and report the discrepancies observed, if any, to the Controller. A value of 'false' makes the Controller send the 'Signature Add LWAPP Message' to all the joined APs with the status field set to 'disable'. The joined APs doesn't perform the signature analysis on the received 802.11 data and/or management frames for this particular signature, till the signature is enabled.
1.3.6.1.4.1.14179.2.3.1.42.3.1.12
BsnTxtSignatureMacInfo0 = bsnSignatureMacAll1 = bsnSignatureMacIndividual2 = bsnSignatureMacBothThis textual convention defines the pattern followed by the LWAPP APs to perform signature analysis with the signature and report the results to the Controller. The semantics are described as follows. bsnSignatureMacAll - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported on a per-signature and per-channel basis. bsnSignatureMacIndividual - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported separately for individual MAC addresses, that are the sources of the received 802.11 data and/or management frames. bsnStandardSigMacBoth - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked on a per signature as well as per-MAC address basis. · Integer32
This object defines the pattern followed by the LWAPP APs to perform signature analysis with this Custom signature and report the results to the Controller.
1.3.6.1.4.1.14179.2.3.1.42.3.1.13
Unsigned32 (0..65535)
This object specifies the frequency of matching packets from a particular source after which the specified action is taken.
1.3.6.1.4.1.14179.2.3.1.42.3.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion. Signature will allowed to be created, deleted and edited in later releases.
1.3.6.1.4.1.14179.2.3.1.42.3.1.21
Unsigned32 (1..3600)
Interval of the signature. This specifies the interval when the signature is applied to a packet.
1.3.6.1.4.1.14179.2.3.1.42.4
Index: bsnCustomSignaturePrecedence · bsnCustomSignaturePatternIndex
The table listing the matching patterns specified for a Standard Signature. These are instrumental in matching the signature with a packet. A maximum of 5 patterns may be specifed for a signature. These are used for matching in the order of their index.
1.3.6.1.4.1.14179.2.3.1.42.4.1.1
Unsigned32 (1..5)
Index of the pattern. This specifies the order in which the pattern is checked against the packet contents.
1.3.6.1.4.1.14179.2.3.1.42.4.1.2
Unsigned32 (0..128)
Offset from the start of the packet where the AP looks for a match to the pattern.
1.3.6.1.4.1.14179.2.3.1.42.4.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..62) · OCTET STRING · hint 255a
This is the pattern string that the AP uses to match at the offset. Example: 0x616c7068615f3178
1.3.6.1.4.1.14179.2.3.1.42.4.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..62) · OCTET STRING · hint 255a
This is the pattern mask. This is the bit mask that the AP uses to mask out the bits in the packet at the given offset. Example: 0xffffffffffffffff
1.3.6.1.4.1.14179.2.3.1.42.4.1.5
BsnSignaturePatternOffSetStart0 = sigPattStartFrm1 = sigPattStartFrmBodyThis object indicates how an offset should be applied while doing signature analysis for QOS and non-QOS data frames. This is introduced since 802.11e QOS frames have an additional 2-byte QOS header which results in the current implementation not being able to find the start of the date frames for signature analysis. The semantics of the values are as follows. sigPattStartFrm - This indicates that the required offset should be applied to the start of the data frame, before performing pattern matching of the signature on the data frame. sigPattStartFrmBody - This value indicates that the required offset should be applied to the start of the frame body, after the header, before performing pattern matching of the signature on the data frame. · Integer32
This object indicates how an offset should be applied while doing signature analysis for QOS and non-QOS data frames with this custom signature.
1.3.6.1.4.1.14179.2.3.1.42.4.1.15
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion. Signature Pattern will allowed to be created, deleted and edited in later releases.
1.3.6.1.4.1.14179.2.4.1.1.9
Index: bsnWrasDot11aPeerMacAddress
This is a table of Airespace Switch addresses that identifies the members of the Dot11a RF group containing this Airespace Switch. Max size is 20 entries. This has been deprecated for clrRrmDot11BandGrpMemberTable.
1.3.6.1.4.1.14179.2.4.1.1.9.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of the member Switch.
1.3.6.1.4.1.14179.2.4.1.1.9.1.21
IpAddress SIZE (4)
The IP address of the Airespace Switch.
1.3.6.1.4.1.14179.2.4.2.1.9
Index: bsnWrasDot11bPeerMacAddress
This is a table of Airespace Switch addresses that identifies the members of the Dot11b RF group containing this Airespace Switch. Max size is 20 entries. This has been deprecated for clrRrmDot11BandGrpMemberTable.
1.3.6.1.4.1.14179.2.4.2.1.9.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of the GIGE interface.
1.3.6.1.4.1.14179.2.4.2.1.9.1.21
IpAddress SIZE (4)
The IP address of the Airespace Switch.
1.3.6.1.4.1.14179.2.5.1
Index: bsnRadiusAuthServerIndex
The (conceptual) table listing the RADIUS authentication servers with which the client shares a secret.
1.3.6.1.4.1.14179.2.5.1.1.1
Integer32 (1..17)
A number uniquely identifying each RADIUS Authentication server with which this client communicates.
1.3.6.1.4.1.14179.2.5.1.1.2
IpAddress SIZE (4)
The IP address of the RADIUS authentication server referred to in this table entry.
1.3.6.1.4.1.14179.2.5.1.1.3
Integer32 (0..65535)
The UDP port the client is using to send requests to this server.
1.3.6.1.4.1.14179.2.5.1.1.4
OCTET STRING SIZE (0..128)
The authentication and encryption key shared between the Radius client and this Radius Server. When the bsnRadiusAuthServerKeyFormat is hex it can have max length of 128 bytes. If the bsnRadiusAuthServerKeyFormat is Ascii it can have max length of 64 bytes.
1.3.6.1.4.1.14179.2.5.1.1.5
INTEGER0 = disable1 = enable · Integer32
Server enable or disable status.
1.3.6.1.4.1.14179.2.5.1.1.6
INTEGER1 = hex2 = ascii · Integer32
Format of the server key. When hex, the number of characters in the key should be even.
1.3.6.1.4.1.14179.2.5.1.1.7
INTEGER0 = disable1 = enable · Integer32
Support for Dynamic Authorization Extensions to RADIUS.
1.3.6.1.4.1.14179.2.5.1.1.8
INTEGER0 = disable1 = enable · Integer32
IPSec over RADIUS
1.3.6.1.4.1.14179.2.5.1.1.9
INTEGER0 = none1 = hmacMd52 = hmacSha1 · Integer32
The Hash algorithm employed by the IPSec Encrpytion. This applies only when bsnRadiusAuthServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.1.1.10
INTEGER0 = none1 = des2 = tripleDes3 = aesCbc · Integer32
The Encryption algorithm employed by this IpSec Encryption. This applies only when bsnRadiusAuthServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.1.1.11
INTEGER1 = main2 = agressive · Integer32
VPN IKE Phase 1 Mode type as per the IpSec standards. This applies only when bsnRadiusAuthServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.1.1.12
Integer32 (1800..345600)
IPSec IKE's Lifetime. This applies only when bsnRadiusAuthServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.1.1.13
INTEGER1 = group12 = group25 = group5 · Integer32
IKE's Diffie-Hellman Group. This applies only when bsnRadiusAuthServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.1.1.14
INTEGER0 = disable1 = enable · Integer32
When enabled, this entry is considered as network user radius authenticating server entry.
1.3.6.1.4.1.14179.2.5.1.1.15
INTEGER0 = disable1 = enable · Integer32
When enabled, this entry is considered as management user radius authenticating server entry.
1.3.6.1.4.1.14179.2.5.1.1.17
INTEGER (2..30) · Integer32
Time in seconds after which a radius authentication request will timeout and a retransmission will be taken up by the switch.
1.3.6.1.4.1.14179.2.5.1.1.18
OCTET STRING
Key-encryption-key (KEK) used as the key for the 128 bit AES Key Wrap algorithm to encrypt the PMK in the key attribute. If the key is present in request, it should be taken as a hint by the server that the sender prefers this method of encryption over others. To maintain security actual keys after configuration are never returned in get request. If keys are configured then '***' is returned. If keys are not configured then empty string is retunred. bsnRadiusAuthServerKeyFormat is used this key. if the format chosen is ascii then it should be 16 bytes in length. if the format chosen is hex then it should be 32 bytes in length.
1.3.6.1.4.1.14179.2.5.1.1.19
OCTET STRING
Message-authenticator-code-key ( MACK) - used as the key for the HMAC-SHA-1 algorithm to sign the RADIUS message to prevent spoofing. MACK must be configured when KEK is configured. To maintain security actual keys after configuration are never returned in get request. If keys are configured then '***' is returned. If keys are not configured then empty string is returned. bsnRadiusAuthServerKeyFormat is used this key. if the format chosen is ascii then it should be 20 bytes in length. If the format chosen is hex then it should be 40 bytes in length.
1.3.6.1.4.1.14179.2.5.1.1.20
INTEGER1 = hex2 = ascii · Integer32
Format for the Key Wrap keys. This object is mandatory for manager to send if the key Wrap keys are being configured. Get on this object will always return hex(1)
1.3.6.1.4.1.14179.2.5.1.1.26
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion
1.3.6.1.4.1.14179.2.5.2
Index: bsnRadiusAccServerIndex
The (conceptual) table listing the RADIUS accounting servers with which the client shares a secret.
1.3.6.1.4.1.14179.2.5.2.1.1
Integer32 (1..17)
A number uniquely identifying each RADIUS Accounting server with which this client communicates.
1.3.6.1.4.1.14179.2.5.2.1.2
IpAddress SIZE (4)
The IP address of the RADIUS accounting server referred to in this table entry.
1.3.6.1.4.1.14179.2.5.2.1.3
Integer32 (0..65535)
The UDP port the client is using to send requests to this server.
1.3.6.1.4.1.14179.2.5.2.1.4
OCTET STRING SIZE (0..128)
The authentication and encryption key shared between the Radius client and this Radius Server. When the bsnRadiusAccServerKeyFormat is hex it can have max length of 128 bytes. If the bsnRadiusAccServerKeyFormat is Ascii it can have max length of 64 bytes.
1.3.6.1.4.1.14179.2.5.2.1.5
INTEGER0 = disable1 = enable · Integer32
Server enable or disable status.
1.3.6.1.4.1.14179.2.5.2.1.6
INTEGER1 = hex2 = ascii · Integer32
Format of the server key. When hex, the number of characters in the key should be even.
1.3.6.1.4.1.14179.2.5.2.1.7
INTEGER0 = disable1 = enable · Integer32
IPSec over RADIUS
1.3.6.1.4.1.14179.2.5.2.1.8
INTEGER0 = none1 = hmacMd52 = hmacSha1 · Integer32
The Hash algorithm employed by the IPSec Encrpytion. This applies only when bsnRadiusAccServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.2.1.9
INTEGER0 = none1 = des2 = tripleDes3 = aesCbc · Integer32
The Encryption algorithm employed by this IpSec Encryption. This applies only when bsnRadiusAccServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.2.1.10
INTEGER1 = main2 = agressive · Integer32
VPN IKE Phase 1 Mode type as per the IpSec standards. This applies only when bsnRadiusAccServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.2.1.11
Integer32 (1800..345600)
IPSec IKE's Lifetime. This applies only when bsnRadiusAccServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.2.1.12
INTEGER1 = group12 = group25 = group5 · Integer32
IKE's Diffie-Hellman Group. This applies only when bsnRadiusAccServerIPSec is in enable state.
1.3.6.1.4.1.14179.2.5.2.1.13
INTEGER0 = disable1 = enable · Integer32
When enabled, this entry is considered as network user radius accounting server entry.
1.3.6.1.4.1.14179.2.5.2.1.14
INTEGER (2..30) · Integer32
Time in seconds after which a radius accounting request will timeout and a retransmission will be taken up by the switch.
1.3.6.1.4.1.14179.2.5.2.1.26
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion
1.3.6.1.4.1.14179.2.5.3
Index: bsnRadiusAuthServerIndex
The listing the Statistics of RADIUS authentication servers.
1.3.6.1.4.1.14179.2.5.3.1.6
TimeTicks
The time interval (in hundredths of a second) between the most recent Access-Reply/Access-Challenge and the Access-Request that matched it from this RADIUS authentication server.
1.3.6.1.4.1.14179.2.5.3.1.7
Counter32
The number of RADIUS Access-Request packets sent to this server. This does not include retransmissions.
1.3.6.1.4.1.14179.2.5.3.1.8
Counter32
The number of RADIUS Access-Request packets retransmitted to this RADIUS authentication server.
1.3.6.1.4.1.14179.2.5.3.1.9
Counter32
The number of RADIUS Access-Accept packets (valid or invalid) received from this server.
1.3.6.1.4.1.14179.2.5.3.1.10
Counter32
The number of RADIUS Access-Reject packets (valid or invalid) received from this server.
1.3.6.1.4.1.14179.2.5.3.1.11
Counter32
The number of RADIUS Access-Challenge packets (valid or invalid) received from this server.
1.3.6.1.4.1.14179.2.5.3.1.12
Counter32
The number of malformed RADIUS Access-Response packets received from this server. Malformed packets include packets with an invalid length. Bad authenticators or Signature attributes or unknown types are not included as malformed access responses.
1.3.6.1.4.1.14179.2.5.3.1.13
Counter32
The number of RADIUS Access-Response packets containing invalid authenticators or Signature attributes received from this server.
1.3.6.1.4.1.14179.2.5.3.1.14
Gauge32
The number of RADIUS Access-Request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an Access-Request is sent and decremented due to receipt of an Acess-Accept, Access-Reject or Access-Challenge, a timeout or retransmission.
1.3.6.1.4.1.14179.2.5.3.1.15
Counter32
The number of authentication timeouts to this server. After a timeout the client may retry to the same server, send to a different server, or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as a Request as well as a timeout.
1.3.6.1.4.1.14179.2.5.3.1.16
Counter32
The number of RADIUS packets of unknown type which were received from this server on the authentication port.
1.3.6.1.4.1.14179.2.5.3.1.36
Counter32
The number of RADIUS packets of which were received from this server on the authentication port and dropped for some other reason.
1.3.6.1.4.1.14179.2.5.4
Index: bsnRadiusAccServerIndex
The (conceptual) table listing the RADIUS accounting servers with which the client shares a secret.
1.3.6.1.4.1.14179.2.5.4.1.6
TimeTicks
The time interval between the most recent Accounting-Response and the Accounting-Request that matched it from this RADIUS accounting server.
1.3.6.1.4.1.14179.2.5.4.1.7
Counter32
The number of RADIUS Accounting-Request packets sent. This does not include retransmissions.
1.3.6.1.4.1.14179.2.5.4.1.8
Counter32
The number of RADIUS Accounting-Request packets retransmitted to this RADIUS accounting server. Retransmissions include retries where the Identifier and Acct-Delay have been updated, as well as those in which they remain the same.
1.3.6.1.4.1.14179.2.5.4.1.9
Counter32
The number of RADIUS packets received on the accounting port from this server.
1.3.6.1.4.1.14179.2.5.4.1.10
Counter32
The number of malformed RADIUS Accounting-Response packets received from this server. Malformed packets include packets with an invalid length. Bad authenticators and unknown types are not included as malformed accounting responses.
1.3.6.1.4.1.14179.2.5.4.1.11
Counter32
The number of RADIUS Accounting-Response packets which contained invalid authenticators received from this server.
1.3.6.1.4.1.14179.2.5.4.1.12
Gauge32
The number of RADIUS Accounting-Request packets sent to this server that have not yet timed out or received a response. This variable is incremented when an Accounting-Request is sent and decremented due to receipt of an Accounting-Response, a timeout or a retransmission.
1.3.6.1.4.1.14179.2.5.4.1.13
Counter32
The number of accounting timeouts to this server. After a timeout the client may retry to the same server, send to a different server, or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as an Accounting-Request as well as a timeout.
1.3.6.1.4.1.14179.2.5.4.1.14
Counter32
The number of RADIUS packets of unknown type which were received from this server on the accounting port.
1.3.6.1.4.1.14179.2.5.4.1.34
Counter32
The number of RADIUS packets which were received from this server on the accounting port and dropped for some other reason.
1.3.6.1.4.1.14179.2.5.5
Index: bsnUserName
The (conceptual) table listing Wlan Users
1.3.6.1.4.1.14179.2.5.5.1.2
OCTET STRING SIZE (1..24)
User Name
1.3.6.1.4.1.14179.2.5.5.1.3
OCTET STRING SIZE (1..24)
User Password
1.3.6.1.4.1.14179.2.5.5.1.4
INTEGER (0..517) · Integer32
User WLAN ID. Value 0 implies that this applies to any WLAN ID.
1.3.6.1.4.1.14179.2.5.5.1.5
INTEGER1 = readOnly2 = readWrite · Integer32
User Access Mode.
1.3.6.1.4.1.14179.2.5.5.1.6
INTEGER1 = management2 = wlan3 = macFilter · Integer32
User Type.
1.3.6.1.4.1.14179.2.5.5.1.7
OCTET STRING SIZE (0..32)
Interface Name.
1.3.6.1.4.1.14179.2.5.5.1.26
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.5.6
Index: bsnBlackListClientMacAddress
The table listing Wlan Black Listed Clients
1.3.6.1.4.1.14179.2.5.6.1.1
OCTET STRING SIZE (1..12)
Black Listed Client MAC Address
1.3.6.1.4.1.14179.2.5.6.1.2
OCTET STRING SIZE (0..32)
Black Listed Client Description
1.3.6.1.4.1.14179.2.5.6.1.22
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.5.7
Index: bsnAclName
The table listing ACLs (Access Control Lists) on the Switch.
1.3.6.1.4.1.14179.2.5.7.1.1
OCTET STRING SIZE (1..32)
Name of the Access Control List.
1.3.6.1.4.1.14179.2.5.7.1.2
INTEGER0 = notapplied1 = applied · Integer32
The apply mode of the ACL on the switch. Mode value 'applied' means the ACL has been applied on the switch.
1.3.6.1.4.1.14179.2.5.7.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status of the ACL.
1.3.6.1.4.1.14179.2.5.8
Index: bsnAclName · bsnAclRuleIndex
The table listing Acl Rules(Access Control List Entries) on the ACL with name bsnAclName.
1.3.6.1.4.1.14179.2.5.8.1.2
Unsigned32 (1..64)
Index of the ACL rule. This can be updated to reset the sequence of the rules of an ACL.
1.3.6.1.4.1.14179.2.5.8.1.3
INTEGER0 = deny1 = permit · Integer32
The permission mode of a rule.
1.3.6.1.4.1.14179.2.5.8.1.4
INTEGER0 = inbound1 = outbound2 = any · Integer32
The direction of the packet to which the rule may be applied.
1.3.6.1.4.1.14179.2.5.8.1.5
IpAddress SIZE (4)
Source IP Address of the ACL rule. A value 0 implies any source address.
1.3.6.1.4.1.14179.2.5.8.1.6
IpAddress SIZE (4)
Source IP Netmask of the ACL rule. A value 0 implies any source mask.
1.3.6.1.4.1.14179.2.5.8.1.7
IpAddress SIZE (4)
Destination IP Address of the ACL rule. A value 0 implies any destination address.
1.3.6.1.4.1.14179.2.5.8.1.8
IpAddress SIZE (4)
Destination Netmask of the ACL rule. A value 0 implies any destination mask.
1.3.6.1.4.1.14179.2.5.8.1.9
Unsigned32 (0..256)
Protocol of the packet. It can be either of the pre specified protocols like TCP, UDP, ICMP, ESP, AH, GRE, IP, Ethernet Over IP, OSPF or any number between 0 and 255. A value 256 implies that this rule applies to 'Any' protocol.
1.3.6.1.4.1.14179.2.5.8.1.10
Unsigned32 (0..65535)
Source Port of the packet. It can be either of the pre specified ports like HTTP, HTTPS, Telnet, RADIUS etc or any number between 0 and 65535. A value 65536 implies that this rule applies to 'Any' source port. This value can be set only if the protocol is set to TCP or UDP. Otherwise the value is set to Any(65536)
1.3.6.1.4.1.14179.2.5.8.1.11
Unsigned32 (0..65535)
Source Port of the packet. It can be either of the pre specified ports like HTTP, HTTPS, Telnet, RADIUS etc or any number between 0 and 65535. A value 65536 implies that this rule applies to 'Any' source port. This value can be set only if the protocol is set to TCP or UDP. Otherwise the value is set to Any(65536)
1.3.6.1.4.1.14179.2.5.8.1.12
Unsigned32 (0..65535)
Destination Port of the packet. It can be either of the pre specified ports like HTTP, HTTPS, Telnet, RADIUS etc or any number between 0 and 65535. A value 65536 implies that this rule aplpies to 'Any' Destination port. This value can be set only if the protocol is set to TCP or UDP. Otherwise the value is set to Any(65536)
1.3.6.1.4.1.14179.2.5.8.1.13
Unsigned32 (0..65535)
Destination Port of the packet. It can be either of the pre specified ports like HTTP, HTTPS, Telnet, RADIUS etc or any number between 0 and 65535. A value 65536 implies that this rule aplpies to 'Any' Destination port. This value can be set only if the protocol is set to TCP or UDP. Otherwise the value is set to Any(65536)
1.3.6.1.4.1.14179.2.5.8.1.14
Unsigned32 (0..256)
DSCP value of the rule. A value 256 implies Any
1.3.6.1.4.1.14179.2.5.8.1.15
Unsigned32 (1..64)
New Index of the ACL rule. This attribute should be updated if the requirement is to reset the sequence of the rules of an ACL. A read on this will not yield anything.
1.3.6.1.4.1.14179.2.5.8.1.40
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status of the ACL Rule.
1.3.6.1.4.1.14179.2.5.9
Index: bsnMacFilterAddress
The table listing MAC Filter entries
1.3.6.1.4.1.14179.2.5.9.1.1
OCTET STRING SIZE (1..24)
MAC Address of the entry
1.3.6.1.4.1.14179.2.5.9.1.2
INTEGER (0..517) · Integer32
WLAN ID of the WLAN that the user can connect to. 0 means any WLAN ID.
1.3.6.1.4.1.14179.2.5.9.1.3
OCTET STRING SIZE (0..32)
Interface Name.
1.3.6.1.4.1.14179.2.5.9.1.4
OCTET STRING SIZE (0..32)
Description of the MAC Filter entry.
1.3.6.1.4.1.14179.2.5.9.1.24
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.5.10
Index: bsnLocalNetUserName
The table listing Local Net User entries.
1.3.6.1.4.1.14179.2.5.10.1.1
OCTET STRING SIZE (1..24)
Name of the net user.
1.3.6.1.4.1.14179.2.5.10.1.2
INTEGER (0..517) · Integer32
WLAN ID of the WLAN that the user can connect to. 0 means any WLAN ID.
1.3.6.1.4.1.14179.2.5.10.1.3
OCTET STRING SIZE (0..24)
User Password.
1.3.6.1.4.1.14179.2.5.10.1.4
OCTET STRING SIZE (0..32)
Description of the Net User entry.
1.3.6.1.4.1.14179.2.5.10.1.5
TimeIntervalA period of time, measured in units of 0.01 seconds. (0 | 6000..259200000) · Integer32
This object indicates the lifetime of an user account expressed in hundredths of a second. Lifetime period other than 0 will make it a guest-user. Minimum value for guest user is 60 seconds (6000). Once configured as non-guest user can not be change to guest user and vice-versa. Default value is for a day and max lifetime is 259200000(30 days). WLANIds, which have webauth policy are valid for guest access user.
1.3.6.1.4.1.14179.2.5.10.1.6
TimeTicks
This object indicates the time when the guest user account was created and expressed as the number of seconds elapsed since 1st Jan, 1970.
1.3.6.1.4.1.14179.2.5.10.1.7
TimeIntervalA period of time, measured in units of 0.01 seconds. (0..2147483647) · Integer32
This object indicates the remaining session time for the guest user in hundredths of a second.
1.3.6.1.4.1.14179.2.5.10.1.24
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.5.11
Index: bsnLocalManagementUserName
The (conceptual) table listing Local Management Users
1.3.6.1.4.1.14179.2.5.11.1.1
OCTET STRING SIZE (1..24)
User Name
1.3.6.1.4.1.14179.2.5.11.1.2
OCTET STRING SIZE (1..24)
User Password
1.3.6.1.4.1.14179.2.5.11.1.3
INTEGER1 = readOnly2 = readWrite · Integer32
User Access Mode.
1.3.6.1.4.1.14179.2.5.11.1.23
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.5.19
Index: bsnExternalPolicyServerIndex
The (conceptual) table listing the External Policy servers with which client share a secret.
1.3.6.1.4.1.14179.2.5.19.1.1
Integer32 (0..2)
A number uniquely identifying each External Policy server with which this client communicates.
1.3.6.1.4.1.14179.2.5.19.1.2
IpAddress SIZE (4)
The IP address of the External Policy server referred to in this table entry.
1.3.6.1.4.1.14179.2.5.19.1.3
Integer32 (0..65535)
The UDP port the client is using to send requests to this server.
1.3.6.1.4.1.14179.2.5.19.1.4
OCTET STRING SIZE (0..16)
The authentication and encryption key shared between the client and this External Policy Server.
1.3.6.1.4.1.14179.2.5.19.1.5
INTEGER0 = disable1 = enable · Integer32
Server enable or disable status.
1.3.6.1.4.1.14179.2.5.19.1.6
INTEGER0 = disconnected1 = connected · Integer32
Server enable or disable status.
1.3.6.1.4.1.14179.2.5.19.1.26
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion
1.3.6.1.4.1.14179.2.5.22
Index: bsnAPAuthMacAddress
The table listing AP Authorization entries
1.3.6.1.4.1.14179.2.5.22.1.1
OCTET STRING SIZE (1..24)
MAC Address of the AP entry
1.3.6.1.4.1.14179.2.5.22.1.2
INTEGER0 = unknown1 = mic2 = ssc3 = locMic4 = locSsc5 = none · Integer32
Supported certificate types are MIC, SSC (Self-Signed-Certificate) or no certificate.
1.3.6.1.4.1.14179.2.5.22.1.3
OCTET STRING SIZE (0..40)
SHA1 hash key for SSC certificate validation. It has to be 40 hexa-decimal characters. This is considered when certificate type is SSC.
1.3.6.1.4.1.14179.2.5.22.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.7.2.1
Index: bsnPingTestId
PingTest Table
1.3.6.1.4.1.14179.2.7.2.1.1.1
Integer32 (0..24)
Test ID
1.3.6.1.4.1.14179.2.7.2.1.1.2
IpAddress SIZE (4)
Ip Address to ping
1.3.6.1.4.1.14179.2.7.2.1.1.3
Integer32 (1..20)
Number of bytes sent
1.3.6.1.4.1.14179.2.7.2.1.1.4
Integer32 (1..20)
Number of bytes received.
1.3.6.1.4.1.14179.2.7.2.1.1.5
INTEGER1 = inprogress2 = complete · Integer32
Status of the ping test
1.3.6.1.4.1.14179.2.7.2.1.1.6
Unsigned32 · mSec
Maximum time interval in msec.
1.3.6.1.4.1.14179.2.7.2.1.1.7
Unsigned32 · mSec
Minimum time interval in msec.
1.3.6.1.4.1.14179.2.7.2.1.1.8
Unsigned32 · mSec
Average time interval in msec.
1.3.6.1.4.1.14179.2.7.2.1.1.25
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.7.3.1
Index: bsnLinkTestId
LinkTest Table
1.3.6.1.4.1.14179.2.7.3.1.1.1
Integer32 (0..24)
Link Test ID
1.3.6.1.4.1.14179.2.7.3.1.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of link to test
1.3.6.1.4.1.14179.2.7.3.1.1.3
Integer32 (1..20)
Number of packets sent.
1.3.6.1.4.1.14179.2.7.3.1.1.4
Integer32 (1..2000)
Length of sent packet
1.3.6.1.4.1.14179.2.7.3.1.1.5
Integer32
Number of received packets.
1.3.6.1.4.1.14179.2.7.3.1.1.6
Integer32
Client RSSI value of link.
1.3.6.1.4.1.14179.2.7.3.1.1.7
Integer32
Local SNR of the link
1.3.6.1.4.1.14179.2.7.3.1.1.8
Integer32
Local RSSI of the link.
1.3.6.1.4.1.14179.2.7.3.1.1.9
INTEGER1 = inprogress2 = complete · Integer32
Status of the link test.
1.3.6.1.4.1.14179.2.7.3.1.1.30
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.8.1.10
Index: bsnMobilityGroupMemberMacAddress
MWAR List (statically configured members of the mobility group)
1.3.6.1.4.1.14179.2.8.1.10.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
Member switch MAC Address
1.3.6.1.4.1.14179.2.8.1.10.1.2
IpAddress SIZE (4)
Member switch IP Address
1.3.6.1.4.1.14179.2.8.1.10.1.3
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..31) · OCTET STRING · hint 255a
Member's group name. If left empty while adding a new group member, this assumes the default mobility group name of the switch.
1.3.6.1.4.1.14179.2.8.1.10.1.22
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.8.1.11
Index: bsnMobilityAnchorWlanSsid · bsnMobilityAnchorSwitchIPAddress
Statically configured mobility anchors
1.3.6.1.4.1.14179.2.8.1.11.1.1
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (1..32) · OCTET STRING · hint 255a
Local wlan-ssid to connect to Guest/Anchor switch
1.3.6.1.4.1.14179.2.8.1.11.1.2
IpAddress SIZE (4)
Guest/Anchor switch IP Address
1.3.6.1.4.1.14179.2.8.1.11.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status
1.3.6.1.4.1.14179.2.8.2.9
Index: bsnGroupDirectoryMemberMacAddress
MWAR List (statically configured members of the mobility group)
1.3.6.1.4.1.14179.2.8.2.9.1.1
IpAddress SIZE (4)
Mwar Ip Address
1.3.6.1.4.1.14179.2.8.2.9.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
Mwar Mac Address
1.3.6.1.4.1.14179.2.8.2.9.1.3
INTEGER1 = static2 = rrm3 = broadcast4 = learned · Integer32
Discovery type of the Group Directory.
1.3.6.1.4.1.14179.2.8.2.9.1.4
Counter32
Current anchored client count
1.3.6.1.4.1.14179.2.8.2.9.1.5
Counter32
Total anchored client count
1.3.6.1.4.1.14179.2.8.2.9.1.6
Counter32
Current exported client count
1.3.6.1.4.1.14179.2.8.2.9.1.7
Counter32
Total exported client count
1.3.6.1.4.1.14179.2.8.2.9.1.8
Counter32
Current Imported client count
1.3.6.1.4.1.14179.2.8.2.9.1.9
Counter32
Total Imported client count
1.3.6.1.4.1.14179.2.8.2.9.1.10
Counter32
Total handoff errors
1.3.6.1.4.1.14179.2.8.2.9.1.30
Counter32
Total Communication errors
1.3.6.1.4.1.14179.2.9.3
Index: bsnWrasIpsecCertName
A table of Certificates.
1.3.6.1.4.1.14179.2.9.3.1.1
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..80) · OCTET STRING · hint 255a
The name assigned to this set of IKE Certificates.
1.3.6.1.4.1.14179.2.9.3.1.2
OCTET STRING SIZE (0..4096)
If you try to read this it will always be ***
1.3.6.1.4.1.14179.2.9.3.1.3
OCTET STRING SIZE (0..4096)
1.3.6.1.4.1.14179.2.9.3.1.4
OCTET STRING SIZE (0..1500)
1.3.6.1.4.1.14179.2.9.3.1.24
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
A row status type for the IKE Cert Entry.
1.3.6.1.4.1.14179.2.10.2
Index: bsnAPGroupsVlanName
Wireless Sites Table.
1.3.6.1.4.1.14179.2.10.2.1.1
OCTET STRING SIZE (1..32)
The string is an unique identifier/name assigned to a site.
1.3.6.1.4.1.14179.2.10.2.1.2
OCTET STRING SIZE (0..32)
Description about the site.
1.3.6.1.4.1.14179.2.10.2.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion of entries in bsnAPGroupsVlanTable
1.3.6.1.4.1.14179.2.10.3
Index: bsnAPGroupsVlanName · bsnAPGroupsVlanMappingSsid
A table for the WLAN-interace-mappings allowed for each configured site. Each site can have a set of WLANs associated with it.
1.3.6.1.4.1.14179.2.10.3.1.1
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (1..32) · OCTET STRING · hint 255a
When an AP is associated with a site, and the site has an associated set of WLANs, then only those WLANs are beamed by the AP. Here 'bsnAPGroupsVlanMappingSsid' is the wlan to be used when a client connects on this AP.
1.3.6.1.4.1.14179.2.10.3.1.2
OCTET STRING SIZE (1..32)
When an AP is associated with a site, and the site has an associated set of WLANs, then only those WLANs are beamed by the AP. Here 'bsnAPGroupsVlanMappingInterfaceName' is the interface to be used when a client connects to the 'bsnAPGroupsVlanMappingSsid' WLAN on this AP.
1.3.6.1.4.1.14179.2.10.3.1.20
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe 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); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device; - `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 (i.e., one or more required columns in the conceptual row have not been instanciated); - `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 attempt 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|see 8 ->D| ->D --------------+--------------+-----------+-------------+------------- set status |inconsistent- |inconsist- |noError |noError ->C column to | Value| entValue| | notInService | | | | | | or | | or | | | | | |see 3 ->C| ->C|see 6 --------------+--------------+-----------+-------------+------------- set status |noError |noError |noError |noError ->A column to | | | | or destroy | ->A| ->A| ->A|see 7 --------------+--------------+-----------+-------------+------------- 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, and all columns have acceptable values, then return noError and goto D. (3) if other variable bindings included in the same PDU, provide legal 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. (6) the return value can indicate one of the following errors: wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated. (7) the return value can indicate the following error: inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated. (8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue. NOTE: Other processing of (this and other varbinds 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 (attempt 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 absence 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' or `inconsistentValue'. 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. · Integer32
Row Status for creation/deletion of WLAN-interface-mappings asscoiated with sites.
1.3.6.1.4.1.14179.2.6.3.1
The disassociate notification shall be sent when the Station sends a Disassociation frame. The value of the notification shall include the MAC address of the MAC to which the Disassociation frame was sent and the reason for the disassociation
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.37
INTEGER1 = unspecified2 = previousAuthNotValid3 = deauthenticationLeaving4 = disassociationDueToInactivity5 = disassociationAPBusy6 = class2FrameFromNonAuthStation7 = class2FrameFromNonAssStation8 = disassociationStaHasLeft9 = staReqAssociationWithoutAuth40 = invalidInformationElement41 = groupCipherInvalid42 = unicastCipherInvalid43 = akmpInvalid44 = unsupportedRsnVersion45 = invalidRsnIeCapabilities46 = cipherSuiteRejected99 = missingReasonCode101 = maxAssociatedClientsReached200 = unSpecifiedQosFailure201 = qosPolicyMismatch202 = inSufficientBandwidth203 = inValidQosParams · Integer32
unspecified - Unspecified. previousAuthNotValid - Previous Authentication was not valid. deauthenticationLeaving - Leaving due to deauthentication. disassociationDueToInactivity - Disassociation due to Inactivity. disassociationAPBusy - Disassociation since AP was busy. class2FrameFromNonAuthStation - Class 2 frame from non authenticated station. class2FrameFromNonAssStation - Class 2 frame from non associated station. disassociationStaHasLeft - Station has left due to disassociation. staReqAssociationWithoutAuth - Station send association request without authentication. invalidInformationElement - Invalid information element. groupCipherInvalid - Invalid group Cipher. unicastCipherInvalid - Invalid unicast cipher. akmpInvalid - Invalid AKMP. unsupportedRsnVersion - Unsupported RSN version. invalidRsnIeCapabilities - Invalid RSN IE capabilities. cipherSuiteRejected - Cipher suite rejected. missingReasonCode - Reason code is missing. maxAssociatedClientsReached - Maximum allowed associated client number has reached. unSpecifiedQosFailure - Unsupported QOS failure. qosPolicyMismatch - Mismatch on QOS policy. inSufficientBandwidth - Insufficient bandwidth. inValidQosParams - Invalid QOS parameters.
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.2
The deauthenticate notification shall be sent when the Station sends a Deauthentication frame. The value of the notification shall include the MAC address of the MAC to which the Deauthentication frame was sent and the reason for the deauthentication.
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.37
INTEGER1 = unspecified2 = previousAuthNotValid3 = deauthenticationLeaving4 = disassociationDueToInactivity5 = disassociationAPBusy6 = class2FrameFromNonAuthStation7 = class2FrameFromNonAssStation8 = disassociationStaHasLeft9 = staReqAssociationWithoutAuth40 = invalidInformationElement41 = groupCipherInvalid42 = unicastCipherInvalid43 = akmpInvalid44 = unsupportedRsnVersion45 = invalidRsnIeCapabilities46 = cipherSuiteRejected99 = missingReasonCode101 = maxAssociatedClientsReached200 = unSpecifiedQosFailure201 = qosPolicyMismatch202 = inSufficientBandwidth203 = inValidQosParams · Integer32
unspecified - Unspecified. previousAuthNotValid - Previous Authentication was not valid. deauthenticationLeaving - Leaving due to deauthentication. disassociationDueToInactivity - Disassociation due to Inactivity. disassociationAPBusy - Disassociation since AP was busy. class2FrameFromNonAuthStation - Class 2 frame from non authenticated station. class2FrameFromNonAssStation - Class 2 frame from non associated station. disassociationStaHasLeft - Station has left due to disassociation. staReqAssociationWithoutAuth - Station send association request without authentication. invalidInformationElement - Invalid information element. groupCipherInvalid - Invalid group Cipher. unicastCipherInvalid - Invalid unicast cipher. akmpInvalid - Invalid AKMP. unsupportedRsnVersion - Unsupported RSN version. invalidRsnIeCapabilities - Invalid RSN IE capabilities. cipherSuiteRejected - Cipher suite rejected. missingReasonCode - Reason code is missing. maxAssociatedClientsReached - Maximum allowed associated client number has reached. unSpecifiedQosFailure - Unsupported QOS failure. qosPolicyMismatch - Mismatch on QOS policy. inSufficientBandwidth - Insufficient bandwidth. inValidQosParams - Invalid QOS parameters.
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.3
The authenticate failure notification shall be sent when the Station sends an Authentication frame with a status code other than 'successful'. The value of the notification shall include the MAC address of the MAC to which the Authentication frame was sent and the reason for the authentication failure.
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.37
INTEGER1 = unspecified2 = previousAuthNotValid3 = deauthenticationLeaving4 = disassociationDueToInactivity5 = disassociationAPBusy6 = class2FrameFromNonAuthStation7 = class2FrameFromNonAssStation8 = disassociationStaHasLeft9 = staReqAssociationWithoutAuth40 = invalidInformationElement41 = groupCipherInvalid42 = unicastCipherInvalid43 = akmpInvalid44 = unsupportedRsnVersion45 = invalidRsnIeCapabilities46 = cipherSuiteRejected99 = missingReasonCode101 = maxAssociatedClientsReached200 = unSpecifiedQosFailure201 = qosPolicyMismatch202 = inSufficientBandwidth203 = inValidQosParams · Integer32
unspecified - Unspecified. previousAuthNotValid - Previous Authentication was not valid. deauthenticationLeaving - Leaving due to deauthentication. disassociationDueToInactivity - Disassociation due to Inactivity. disassociationAPBusy - Disassociation since AP was busy. class2FrameFromNonAuthStation - Class 2 frame from non authenticated station. class2FrameFromNonAssStation - Class 2 frame from non associated station. disassociationStaHasLeft - Station has left due to disassociation. staReqAssociationWithoutAuth - Station send association request without authentication. invalidInformationElement - Invalid information element. groupCipherInvalid - Invalid group Cipher. unicastCipherInvalid - Invalid unicast cipher. akmpInvalid - Invalid AKMP. unsupportedRsnVersion - Unsupported RSN version. invalidRsnIeCapabilities - Invalid RSN IE capabilities. cipherSuiteRejected - Cipher suite rejected. missingReasonCode - Reason code is missing. maxAssociatedClientsReached - Maximum allowed associated client number has reached. unSpecifiedQosFailure - Unsupported QOS failure. qosPolicyMismatch - Mismatch on QOS policy. inSufficientBandwidth - Insufficient bandwidth. inValidQosParams - Invalid QOS parameters.
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.4
The associate failure notification shall be sent when the Station sends an Association frame with a status code other than 'successful'. The value of the notification shall include the MAC address of the MAC to which the Authentication frame was sent and the reason for the authentication failure.
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.37
INTEGER1 = unspecified2 = previousAuthNotValid3 = deauthenticationLeaving4 = disassociationDueToInactivity5 = disassociationAPBusy6 = class2FrameFromNonAuthStation7 = class2FrameFromNonAssStation8 = disassociationStaHasLeft9 = staReqAssociationWithoutAuth40 = invalidInformationElement41 = groupCipherInvalid42 = unicastCipherInvalid43 = akmpInvalid44 = unsupportedRsnVersion45 = invalidRsnIeCapabilities46 = cipherSuiteRejected99 = missingReasonCode101 = maxAssociatedClientsReached200 = unSpecifiedQosFailure201 = qosPolicyMismatch202 = inSufficientBandwidth203 = inValidQosParams · Integer32
unspecified - Unspecified. previousAuthNotValid - Previous Authentication was not valid. deauthenticationLeaving - Leaving due to deauthentication. disassociationDueToInactivity - Disassociation due to Inactivity. disassociationAPBusy - Disassociation since AP was busy. class2FrameFromNonAuthStation - Class 2 frame from non authenticated station. class2FrameFromNonAssStation - Class 2 frame from non associated station. disassociationStaHasLeft - Station has left due to disassociation. staReqAssociationWithoutAuth - Station send association request without authentication. invalidInformationElement - Invalid information element. groupCipherInvalid - Invalid group Cipher. unicastCipherInvalid - Invalid unicast cipher. akmpInvalid - Invalid AKMP. unsupportedRsnVersion - Unsupported RSN version. invalidRsnIeCapabilities - Invalid RSN IE capabilities. cipherSuiteRejected - Cipher suite rejected. missingReasonCode - Reason code is missing. maxAssociatedClientsReached - Maximum allowed associated client number has reached. unSpecifiedQosFailure - Unsupported QOS failure. qosPolicyMismatch - Mismatch on QOS policy. inSufficientBandwidth - Insufficient bandwidth. inValidQosParams - Invalid QOS parameters.
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.5
When Airespace AP operation status goes up this trap will be sent
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.6.3.6
When Airespace AP operation status goes down this trap will be sent
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.6.3.7
When Airespace AP Associates to a Airespace Switch, AP associated notification will be sent with dot3 MAC address of Airespace AP.This will help management system to discover Airespace AP and add to system.
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.32
Integer32
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.8
When Airespace AP disassociates from Airespace Switch, AP disassociated notification will be sent with dot3 MAC address of Airespace AP management system to remove Airespace AP from this Airespace Switch
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.9
When Airespace AP's interface's operation status goes up this trap will be sent
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.13
INTEGER (0..65535) · Integer32
Port on the Switch on which this APs traffic is coming through.
1.3.6.1.4.1.14179.2.6.2.70
INTEGER0 = unknown1 = radioFailure2 = radioLowPower3 = maxRetransmission4 = echoTimeout5 = configAP6 = configRadio7 = configNetwork8 = adminConfigured9 = missedRekey10 = detectingInLinePower11 = newDiscovery · Integer32
This denotes the reason for AP If up or down normal - radio Failure - radio failed radioLowPower - AP is not able draw enough power. maxRetransmission - max retransmission of AP Reached. echoTimeout - heartbeat timeout. configAP - admin enable/disable AP configRadio - admin enable/disable config radio configNetwork - admin enable/disable network adminConfigured - admin configuration missedRekey - Missed Rekey detectingInLinePower - Detecting in-line power newDiscovery - New Discovery
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.10
When Airespace AP's interface's operation status goes down this trap will be sent.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.37
INTEGER1 = enable2 = disable · Integer32
Admin State of the AP
1.3.6.1.4.1.14179.2.2.2.1.34
INTEGER2 = disable1 = enable · Integer32
Admin status of the interface.
1.3.6.1.4.1.14179.2.6.2.70
INTEGER0 = unknown1 = radioFailure2 = radioLowPower3 = maxRetransmission4 = echoTimeout5 = configAP6 = configRadio7 = configNetwork8 = adminConfigured9 = missedRekey10 = detectingInLinePower11 = newDiscovery · Integer32
This denotes the reason for AP If up or down normal - radio Failure - radio failed radioLowPower - AP is not able draw enough power. maxRetransmission - max retransmission of AP Reached. echoTimeout - heartbeat timeout. configAP - admin enable/disable AP configRadio - admin enable/disable config radio configNetwork - admin enable/disable network adminConfigured - admin configuration missedRekey - Missed Rekey detectingInLinePower - Detecting in-line power newDiscovery - New Discovery
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.11
When LOAD Profile state changes from PASS to FAIL, notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable/disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.12
When Noise Profile state changes from PASS to FAIL, notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable/disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.13
When Interference Profile state changes from PASS to FAIL, notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable/disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.14
When Coverage Profile state changes from PASS to FAIL, notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable/disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.21
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
1.3.6.1.4.1.14179.2.6.2.22
Integer32
Number of Radio Interfaces on the Airespace AP.
1.3.6.1.4.1.14179.2.6.2.24
Integer32
1.3.6.1.4.1.14179.2.6.2.25
Integer32
1.3.6.1.4.1.14179.2.6.2.26
Integer32
1.3.6.1.4.1.14179.2.6.2.27
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.28
Integer32
1.3.6.1.4.1.14179.2.6.2.29
Integer32
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.15
Whenever dynamic algorithms are running and bsnAPIfPhyPowerAutomaticOn is true, Airespace AP Interface's CurrentTxPower might get updated by algorithm. When this occurs notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF along with the currentTxPower for this Airespace AP IF
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.6
INTEGER (1..8) · Integer32
The TxPowerLevel currently being used to transmit data. Some PHYs also use this value to determine the receiver sensitivity requirements for CCA. Valid values are between 1 to 8,depnding on what radio, and this attribute can be set only if bsnAPIfPhyTxPowerControl is set to customized.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.16
Whenever dynamic algorithms are running and bsnAPIfPhyChannelAutomaticOn is true, Airespace AP Interface's CurrentChannel might get updated by algorithm. When this occurs notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF along with the currentChannel for this Airespace AP IF
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.22
Integer32
Number of Radio Interfaces on the Airespace AP.
1.3.6.1.4.1.14179.2.6.2.23
Integer32
1.3.6.1.4.1.14179.2.6.2.30
Integer32
1.3.6.1.4.1.14179.2.6.2.31
Integer32
1.3.6.1.4.1.14179.2.6.2.83
Integer32
1.3.6.1.4.1.14179.2.6.2.84
BITS
1.3.6.1.4.1.14179.2.6.2.85
Integer32
1.3.6.1.4.1.14179.2.6.2.86
Integer32
1.3.6.1.4.1.14179.2.6.2.87
Integer32
1.3.6.1.4.1.14179.2.6.2.88
Integer32
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.21
When Grouping is done, this notification will be sent from the previous Group Leader where grouping algorithm was run. It has MAC address of the new Group Leader.
1.3.6.1.4.1.14179.2.4.1.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
This is the MAC address of the group leader for the dot11a group containing this Airespace Switch.
1.3.6.1.4.1.14179.2.6.3.22
When Grouping is done, this notification will be sent from the previous Group Leader where grouping algorithm was run. It has MAC address of the new Group Leader.
1.3.6.1.4.1.14179.2.4.2.1.2
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
This is the MAC address of the group leader for the dot11b group containing this Airespace Switch. This has been deprecated for clrRrmDot11BandGrpTable.
1.3.6.1.4.1.14179.2.6.3.23
When configuration is save either from CLI or web interface This trap will be sent to inform NMS to do refresh
1.3.6.1.4.1.14179.2.6.3.24
Whenever a new Ess (WLAN) is created, this notification will be sent along with EssIndex
1.3.6.1.4.1.14179.2.1.1.1.1
Unsigned32 (1..517)
Index of the Ess(WLAN) within Airespace Switch. Airespace Switch supports 517 ESS(Wlans) so index will be from 1 to 517. 517 is to be used for ESS(WLAN) created for support of Third Party APs(non-Airespace APs)
1.3.6.1.4.1.14179.2.6.3.25
Whenever a Ess (WLAN)is deleted, this notification will be sent along with EssIndex
1.3.6.1.4.1.14179.2.1.1.1.1
Unsigned32 (1..517)
Index of the Ess(WLAN) within Airespace Switch. Airespace Switch supports 517 ESS(Wlans) so index will be from 1 to 517. 517 is to be used for ESS(WLAN) created for support of Third Party APs(non-Airespace APs)
1.3.6.1.4.1.14179.2.6.3.26
This trap is to indicate that no RADIUS server(s) are responding to authentication requests sent by the RADIUS client within the MWAR device(Switch).
1.3.6.1.4.1.14179.2.6.3.27
This trap is to inform that client authentication failure has occured at MWAR(Switch). This could be cli/web user, wlan user, or Mac Authorized user. ServiceType will indicate which type of user it is and userName will be cli/web/wlan userName or MacAddress of Mac Authorized User
1.3.6.1.4.1.14179.2.6.2.2
INTEGER1 = mgmtUser2 = wlanUser3 = macFilter · Integer32
1.3.6.1.4.1.14179.2.6.2.1
OCTET STRING SIZE (0..32)
1.3.6.1.4.1.14179.2.6.3.28
IPsec packets with invalid hashes were found in an inbound ESP SA. The total number of authentication errors accumulated is sent for the specific row of the ipsecSaEspInTable table for the SA; this provides the identity of the SA in which the error occurred. Implementations SHOULD send one trap per SA (within a reasonable time period), rather than sending one trap per packet.
1.3.6.1.4.1.14179.2.6.2.3
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.4
Integer32
1.3.6.1.4.1.14179.2.6.3.29
IPsec packets with invalid sequence numbers were found in an inbound ESP SA. The total number of replay errors accumulated is sent for the specific row of the ipsecSaEspInTable table for the SA; this provides the identity of the SA in which the error occurred. Implementations SHOULD send one trap per SA (within a reasonable time period), rather than sending one trap per packet.
1.3.6.1.4.1.14179.2.6.2.3
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.4
Integer32
1.3.6.1.4.1.14179.2.6.3.31
A packet with an unknown SPI was detected from the specified peer with the specified SPI using the specified protocol. The destination address of the received packet is specified by ipsecLocalAddress. The value ifIndex may be 0 if this optional linkage is unsupported. If the object ipsecSecurityProtocol has the value for IPcomp, then the ipsecSPI object is the CPI of the packet. Implementations SHOULD send one trap per peer (within a reasonable time period), rather than sending one trap per packet.
1.3.6.1.4.1.14179.2.6.2.3
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.5
Integer32
1.3.6.1.4.1.14179.2.6.3.33
An attempt to negotiate a phase 1 IKE SA failed. The notification counts are also sent as part of the trap, along with the current value of the total negotiation error counters for ISAKMP.
1.3.6.1.4.1.14179.2.6.2.3
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.6
Integer32 (0..65535)
1.3.6.1.4.1.14179.2.6.2.7
Integer32
1.3.6.1.4.1.14179.2.6.2.8
Integer32
1.3.6.1.4.1.14179.2.6.2.9
Integer32
1.3.6.1.4.1.14179.2.6.2.10
Integer32
1.3.6.1.4.1.14179.2.6.2.11
Integer32
1.3.6.1.4.1.14179.2.6.2.12
Integer32
1.3.6.1.4.1.14179.2.6.3.34
An attempt to negotiate a phase 2 SA suite for the specified selector failed. The current total failure counts are passed as well as the notification type counts for the notify involved in the failure.
1.3.6.1.4.1.14179.2.6.2.3
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.13
Integer32
1.3.6.1.4.1.14179.2.6.2.14
Integer32
1.3.6.1.4.1.14179.2.6.2.11
Integer32
1.3.6.1.4.1.14179.2.6.2.12
Integer32
1.3.6.1.4.1.14179.2.6.3.35
ISAKMP packets with invalid cookies were detected from the specified source, intended for the specified destination. The initiator and responder cookies are also sent with the trap. The current count is sent to allow the trap to accurately relfect dropped and throttled traps. Implementations SHOULD send one trap per peer (within a reasonable time period, rather than sending one trap per packet.
1.3.6.1.4.1.14179.2.6.2.3
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.6
Integer32 (0..65535)
1.3.6.1.4.1.14179.2.6.2.15
OCTET STRING SIZE (8)
The initiator cookie used in an ISAKMP message, to be associated with a trap.
1.3.6.1.4.1.14179.2.6.2.16
OCTET STRING SIZE (8)
The responder cookie used in an ISAKMP message, to be associated with a trap.
1.3.6.1.4.1.14179.2.6.2.17
Integer32
1.3.6.1.4.1.14179.2.6.3.36
When a Rogue AP is detected this Trap will be sent out along with APMacAddress on which its detected
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.1.8.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Airespace AP Interface that Detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.2
Unsigned32 (0..2)
The slot ID of the Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.6
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The SSID Advertised by Rogue Station.
1.3.6.1.4.1.14179.2.1.8.1.5
Integer32
The advertised Channel Number of the Airespace AP Interface picked up from the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.7
Integer32
Rogue RSSI as seen by Airespace AP Interface.
1.3.6.1.4.1.14179.2.1.8.1.27
Integer32
SNR seen by Airespace AP Interface from Rogue
1.3.6.1.4.1.14179.2.6.2.40
INTEGER0 = no1 = yes · Integer32
This is the flag used on the bsnRogueAPDetected trap to state if the rogue is found on the wired network. Typically, after a rogue is found, there may be another bsnRogueAPDetected trap that will have the value of this flag 1 if the rogue is detected on the wired network.
1.3.6.1.4.1.14179.2.6.2.44
INTEGER0 = no1 = yes · Integer32
This is the flag used on the bsnRogueAPDetected trap to state if the rogue found is an Adhoc rogue or it is an AP.
1.3.6.1.4.1.14179.2.1.8.1.3
INTEGER1 = dot11b2 = dot11a3 = unknown4 = uwb5 = dot11g6 = dot11n247 = dot11n5 · Integer32
The Airespace AP Interface type that detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Name of Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.1.7.1.25
INTEGER0 = pending1 = friendly2 = malicious3 = unclassified · Integer32
The AP class type of the client detected.
1.3.6.1.4.1.14179.2.6.3.37
When LOAD Profile state changes from FAIL to PASSt this notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable/disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.38
When Noise Profile state changes from FAIL tp PASS, notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable/disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.39
When Interference Profile state changes from FAIL tp PASS, notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable /disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.40
When Coverage Profile state changes from FAIL tp PASS, notification will be sent with Dot3 MAC address of Airespace AP and slot ID of Airespace AP IF. This trap sending can be enable/disable using bsnRrmProfileTrapControlFlag
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.41
When a Rogue AP that was detected earlier no longer exists this Trap will be sent out along with APMacAddress on which its detected
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.1.8.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Airespace AP Interface that Detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.2
Unsigned32 (0..2)
The slot ID of the Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.3
INTEGER1 = dot11b2 = dot11a3 = unknown4 = uwb5 = dot11g6 = dot11n247 = dot11n5 · Integer32
The Airespace AP Interface type that detected the Rogue.
1.3.6.1.4.1.14179.2.1.8.1.4
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
Name of Airespace AP Interface that detected the Rogue.
1.3.6.1.4.1.14179.2.6.3.42
Whenever the currently associated Radios exceed the License Count This trap will be sent to annoy the Customer
1.3.6.1.4.1.14179.2.6.2.18
Integer32
1.3.6.1.4.1.14179.2.6.2.19
Integer32
1.3.6.1.4.1.14179.2.6.3.43
Temperature sensor temp too High - temp is too high on the unit. Immediate action should be taken
1.3.6.1.4.1.14179.2.3.1.13
Integer32
Current Internal Temperature of the unit in Centigrade
1.3.6.1.4.1.14179.2.6.3.44
Temperature sensor temp too Low - temp is too high on the unit. Immediate action should be taken
1.3.6.1.4.1.14179.2.3.1.13
Integer32
Current Internal Temperature of the unit in Centigrade
1.3.6.1.4.1.14179.2.6.3.45
Temperature sensor hw failure - temp sensor has failed. Temperature is unknown
1.3.6.1.4.1.14179.2.6.3.46
Temperature sensor clear -- temp sensor alarm condition is over. sensor is operating within proper temp range
1.3.6.1.4.1.14179.2.3.1.13
Integer32
Current Internal Temperature of the unit in Centigrade
1.3.6.1.4.1.14179.2.6.3.47
POE Controller has failed. Its a very critical trap. User intervention is required.
1.3.6.1.4.1.14179.2.6.3.48
The number of rogues has exceeded the maximum Rogues allowed
1.3.6.1.4.1.14179.2.6.2.33
Integer32
1.3.6.1.4.1.14179.2.6.3.49
The number of rogues is within the maximum Rogues allowed
1.3.6.1.4.1.14179.2.6.2.33
Integer32
1.3.6.1.4.1.14179.2.6.3.50
The number of rogues has exceeded the maximum Rogues allowed on the AP
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.33
Integer32
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.51
The number of rogues is within the maximum Rogues allowed on the AP
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.33
Integer32
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.52
The station blacklisted notification shall be sent when the client is blacklisted. The reason could be repeated auth or association failures or IP Address theft. The value of the notification shall include the MAC address of the MAC to which the Authentication frame was sent, the MAC and Slot Id of AP that client was associated to and the reason for black listing.
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.38
INTEGER1 = failed80211Auth2 = failedAssociation3 = ipTheft4 = failed8021xAuth5 = failedWebAuth · Integer32
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.53
The associate notification shall be sent when any of the watchlisted clients(present on at least one watch list) associates with an AP. The value of the notification shall include the MAC address and the Slot ID of the radio to which the station Associated.
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.55
The AP sent a string of messages with large NAV field. This is most likely a malicious denial of service attack.
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.22
Integer32
Number of Radio Interfaces on the Airespace AP.
1.3.6.1.4.1.14179.2.6.2.41
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC address generating the attack.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.56
The Management User made too many unsuccessful login attempts.
1.3.6.1.4.1.14179.2.6.2.43
IpAddress SIZE (4)
1.3.6.1.4.1.14179.2.6.2.39
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..255) · OCTET STRING · hint 255a
The user name of a client. This is used for the Client Associated trap. It may be null when not known.
1.3.6.1.4.1.14179.2.6.3.57
Issued when a decrypt error occurrs. The WEP Key configured at the station may be wrong.
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.3.58
Issued when a WPA MIC error occurs and a counter measure is activated at the AP.
1.3.6.1.4.1.14179.2.6.2.34
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.35
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.36
INTEGER (0..15) · Integer32
1.3.6.1.4.1.14179.2.6.2.42
INTEGER (1..517) · Integer32
WLAN ID used by the client when the WPA MIC error counter measure was activated.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.59
When a Rogue is detected on the wired network this trap will be sent out. The same trap with bsnRogueAPOnWiredNetwork set to no will clear the previous trap.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.40
INTEGER0 = no1 = yes · Integer32
This is the flag used on the bsnRogueAPDetected trap to state if the rogue is found on the wired network. Typically, after a rogue is found, there may be another bsnRogueAPDetected trap that will have the value of this flag 1 if the rogue is detected on the wired network.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.60
When an AP has no radio cards present on it, the switch sends this trap.
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.61
This trap is issued when the switch or an AP detects another machine using its IP Address. The first variable has value yes if the duplicate IP is reported by an AP. In that case, the second attribute will carry the AP MAC Address. The third variable is the duplicate IP address in question and the last attribute is the MAC Address of the machine that is found to be using the duplicate IP.
1.3.6.1.4.1.14179.2.6.2.48
INTEGER0 = no1 = yes · Integer32
This is the flag used on the bsnDuplicateIpAddressReported trap to indicate whether the switch or an AP detected a duplicate IP Address on another machine.
1.3.6.1.4.1.14179.2.6.2.20
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
1.3.6.1.4.1.14179.2.6.2.46
IpAddress SIZE (4)
This field is used on the bsnDuplicateIpAddressReported trap to contain the IP Address in question when switch or an AP detected a duplicate IP Address on another machine.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.47
INTEGER0 = false1 = true · Integer32
This is the flag used to indicate clear state for the bsnDuplicateIpAddressReported trap.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.62
When our AP detects that it is being contained by another AP, this trap is issued. The clear flag is true if the AP is no longer being contained.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.63
Issued when a Trusted Rogue AP is auto contained for advertising invalid SSID. If the clear variable has value true, then the trap clears the earlier alert.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.3.64
Issued when a Trusted Rogue AP is missing or has failed. If the clear variable has value true, then the trap clears the earlier alert.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.3.65
Issued when an Adhoc Rogue is auto contained. If the clear variable has value true, then the trap clears the earlier alert.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.3.66
Issued when a Rogue AP is auto contained for advertising our SSID. If the clear variable has value true, then the trap clears the earlier alert.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.3.67
Issued when a Trusted Rogue AP is auto contained for using invalid encryption. The second param is for the encryption used and the third param is for encryption required. If the clear variable has value true, then the trap clears the earlier alert.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.50
INTEGER0 = none1 = open2 = wep3 = wpa · Integer32
This is the encryption type used by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.51
INTEGER0 = none1 = open2 = wep3 = wpa · Integer32
This is the encryption type required by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.3.68
Issued when a Trusted Rogue AP is auto contained for using invalid radio policy. The second param is for the radio policy used and the third param is for radio policy required. If the clear variable has value true, then the trap clears the earlier alert.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.52
INTEGER0 = none1 = dot11b2 = dot11a3 = dot11bg · Integer32
This is the radio policy used by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.49
INTEGER0 = none1 = dot11b2 = dot11a3 = dot11bg · Integer32
This is the radio policy required by a trusted Rogue.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.3.69
When the 802.11a or b/g network state is changed this trap is issued.
1.3.6.1.4.1.14179.2.6.2.53
INTEGER1 = dot11b2 = dot11a · Integer32
1.3.6.1.4.1.14179.2.6.2.54
INTEGER0 = disable1 = enable · Integer32
1.3.6.1.4.1.14179.2.6.3.70
This trap is sent out when a signature attack is detected by the switch. The standard and custom signatures are predefined on the switch (see bsnSignatureConfig group). The signatures also defines if its detection should be reported. The trap variables bsnSignatureName and bsnSignatureDescription are retrieved from the detected signature definition. Clear Trap Variable is turned on when the signature attack stops. The signature's quiet time configuration speicifes the time after which the clear trap would be sent. bsnSignatureMacInfo indicates whether the signature is used to track pattern matches for all source MAC addresses together or seperately for individual source MAC addresses. bsnSignatureAttackFrequency will carry the value for a specific MAC address or for all MAC addresses depending on bsnSignatureMacInfo.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.6.2.55
INTEGER0 = standard1 = custom · Integer32
Type of Signature whose attack is detected by the switch.
1.3.6.1.4.1.14179.2.6.2.56
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..20) · OCTET STRING · hint 255a
Name of the Signature whose attack is detected by the switch.
1.3.6.1.4.1.14179.2.6.2.57
DisplayStringRepresents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire specifies: - the use of character codes 0-127 (decimal) - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 - the other 25 codes have no standard interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal. (Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length. SIZE (0..100) · OCTET STRING · hint 255a
Description of the Signature whose attack is detected by the switch.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.2.61
INTEGER (0..65535) · Integer32
The preced in the standard/custom signature list.
1.3.6.1.4.1.14179.2.6.2.62
INTEGER (0..65535) · Integer32
The preced in the standard/custom signature list.
1.3.6.1.4.1.14179.2.6.2.63
INTEGER (0..65535) · Integer32
The preced in the standard/custom signature list.
1.3.6.1.4.1.14179.2.6.2.64
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of the Attacker's mac-interface.
1.3.6.1.4.1.14179.2.6.2.73
BsnTxtSignatureMacInfo0 = bsnSignatureMacAll1 = bsnSignatureMacIndividual2 = bsnSignatureMacBothThis textual convention defines the pattern followed by the LWAPP APs to perform signature analysis with the signature and report the results to the Controller. The semantics are described as follows. bsnSignatureMacAll - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported on a per-signature and per-channel basis. bsnSignatureMacIndividual - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked and reported separately for individual MAC addresses, that are the sources of the received 802.11 data and/or management frames. bsnStandardSigMacBoth - The Controller would set the 'Mac Info' parameter of the 'Signature Add LWAPP Message' to this value to indicate the LWAPP AP that the signature analysis and pattern matching should be tracked on a per signature as well as per-MAC address basis. · Integer32
This object defines the pattern followed by the LWAPP APs to perform signature analysis with this signature and report the results to the Controller.
1.3.6.1.4.1.14179.2.6.3.71
This trap is sent by the switch when a radio card on an AP stops transmitting.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.72
This trap is sent by the switch when a radio card on an AP starts transmitting again after a prior failure.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.73
This trap is sent by the switch when a radio card on an AP stops receiving.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.74
This trap is sent by the switch when a radio card on an AP starts receiving again after a prior failure.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.75
This trap is sent by the switch when a radio of an authenticated AP hears from another AP whose MAC Address neither matches that of a rogue's and nor is it an authenticated neighbor of the detecting AP.
1.3.6.1.4.1.14179.2.6.2.58
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of the AP impersonated by another AP.
1.3.6.1.4.1.14179.2.6.2.74
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
This is the source mac address which is impersonating the AP.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.2
INTEGER1 = dot11b2 = dot11a4 = uwb · Integer32
The type of this interface. dot11b also implies 802.11b/g.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.76
Issued when a Trusted Rogue AP is auto contained for using invalid preamble. The second param is for the preamble used and the third param is for preamble required. If the clear variable has value true, then the trap clears the earlier alert.
1.3.6.1.4.1.14179.2.1.7.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
MAC Address of Rogue Station.
1.3.6.1.4.1.14179.2.6.2.59
INTEGER0 = none1 = short2 = long · Integer32
The Preamble on this detecting AP.
1.3.6.1.4.1.14179.2.6.2.60
INTEGER0 = none1 = short2 = long · Integer32
The Preamble on this detecting AP.
1.3.6.1.4.1.14179.2.6.2.45
INTEGER0 = false1 = true · Integer32
This is the flag is used to indicate if this is a clear trap for the original alert or not.
1.3.6.1.4.1.14179.2.6.3.77
This trap is sent out when an AP, with the configured static ip-address, fails to establish connection with outside world and starts using DHCP as a fallback option.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.1.1.19
IpAddress SIZE (4)
IP address of the AP. This will not be available when the switch is operating in the Layer2 mode. In this case, the attribute will return 0 as value.
1.3.6.1.4.1.14179.2.2.1.1.28
IpAddress SIZE (4)
The Static IP-Address configuration for the AP. This can only be changed when the LWAPP mode is in Layer-3.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.78
This trap is sent out when AP functionality on the switch is disabled because the License key has expired or has been deleted or doesn't match the switch image.
1.3.6.1.4.1.14179.2.6.2.66
INTEGER0 = unknown1 = licenseKeyExpired2 = licenseKeyDeleted3 = licenseKeyFeatureMismatch · Integer32
This is the reason why the AP functionality was disabled on the switch. It could be either expiry or deletion or mismatch found of the license key.
1.3.6.1.4.1.14179.2.6.2.65
OCTET STRING SIZE (0..255)
This is the license key that has been found to be deleted, expired or is mismatched causing AP functionality to be disabled on the switch.
1.3.6.1.4.1.14179.2.6.2.67
INTEGER1 = wps2 = all · Integer32
This is the switch feature set whose license key has expired or is deleted or is mismatched. To enable the AP functionality again, the license key for this feature set should be re-configured.
1.3.6.1.4.1.14179.2.6.3.79
This trap is generated if an AP's regulatory domain doesn't match the country the switch is configured for. Due to the mismatch, the AP will fail to associate with the Switch.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.2.68
INTEGER0 = a1 = e6 = i9 = j16 = c21 = n32 = k33 = p34 = s35 = t48 = r65535 = notavailable · Integer32
The regulatory domain configured on an AP.
1.3.6.1.4.1.14179.2.3.1.5
INTEGER1 = usa2 = canada3 = france4 = japan5 = mexico6 = spain7 = usalegacy8 = korearepublic9 = australia10 = austria11 = belgium12 = denmark13 = finland14 = germany15 = greece16 = ireland17 = italy18 = luxembourg19 = netherlands20 = portugal21 = sweden22 = unitedkingdom23 = none24 = india25 = hongkong26 = switzerland27 = iceland28 = norway29 = singapore30 = thailand31 = taiwan33 = cyprus34 = czechrepublic35 = estonia36 = hungary37 = lithuania38 = latvia39 = malaysia40 = newzealand41 = poland42 = slovenia43 = slovakrepublic44 = southafrica45 = usachan16546 = israel47 = israelOutdoor48 = argentina49 = brazil51 = saudiArabia52 = turkey53 = indonesia54 = china55 = koreaExtended56 = japan257 = gibraltar58 = liechtenstein59 = malta60 = monaco61 = romania62 = russianfederation63 = chile64 = colombia65 = panama66 = peru67 = venezuela68 = philippines · Integer32
This attribute identifies the country in which the station is operating.
1.3.6.1.4.1.14179.2.6.3.80
This trap indicates that the CPU's Receive Multicast Queue is Full.
1.3.6.1.4.1.14179.2.6.3.81
This trap is sent when radar signals are detected on the current channel
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.4
INTEGER1 = ch12 = ch23 = ch34 = ch45 = ch56 = ch67 = ch78 = ch89 = ch910 = ch1011 = ch1112 = ch1213 = ch1314 = ch1420 = ch2021 = ch2122 = ch2223 = ch2324 = ch2425 = ch2526 = ch2634 = ch3436 = ch3638 = ch3840 = ch4042 = ch4244 = ch4446 = ch4648 = ch4852 = ch5256 = ch5660 = ch6064 = ch64100 = ch100104 = ch104108 = ch108112 = ch112116 = ch116120 = ch120124 = ch124128 = ch128132 = ch132136 = ch136140 = ch140149 = ch149153 = ch153157 = ch157161 = ch161165 = ch165169 = ch169 · Integer32
Current channel number of the AP Interface. Channel numbers will be from 1 to 14 for 802.11b interface type. Channel numbers will be from 34 to 169 for 802.11a interface type. Allowed channel numbers also depends on the current Country Code set in the Switch. This attribute cannot be set unless bsnAPIfPhyChannelAssignment is set to customized else this attribute gets assigned by dynamic algorithm.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.82
This trap will be generated, if a radar trap has been generated earlier, after the expiry of Non-Occupancy Period.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.2.1.4
INTEGER1 = ch12 = ch23 = ch34 = ch45 = ch56 = ch67 = ch78 = ch89 = ch910 = ch1011 = ch1112 = ch1213 = ch1314 = ch1420 = ch2021 = ch2122 = ch2223 = ch2324 = ch2425 = ch2526 = ch2634 = ch3436 = ch3638 = ch3840 = ch4042 = ch4244 = ch4446 = ch4648 = ch4852 = ch5256 = ch5660 = ch6064 = ch64100 = ch100104 = ch104108 = ch108112 = ch112116 = ch116120 = ch120124 = ch124128 = ch128132 = ch132136 = ch136140 = ch140149 = ch149153 = ch153157 = ch157161 = ch161165 = ch165169 = ch169 · Integer32
Current channel number of the AP Interface. Channel numbers will be from 1 to 14 for 802.11b interface type. Channel numbers will be from 34 to 169 for 802.11a interface type. Allowed channel numbers also depends on the current Country Code set in the Switch. This attribute cannot be set unless bsnAPIfPhyChannelAssignment is set to customized else this attribute gets assigned by dynamic algorithm.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.83
This trap is sent out in case of authorization failure while attempting to associate the AP to the controller. bsnAPDot3MacAddress represents the mac-address of that AP. bsnAPName is name of AP
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.5.22.1.2
INTEGER0 = unknown1 = mic2 = ssc3 = locMic4 = locSsc5 = none · Integer32
Supported certificate types are MIC, SSC (Self-Signed-Certificate) or no certificate.
1.3.6.1.4.1.14179.2.6.2.69
INTEGER0 = unknown1 = keymismatch2 = entrydoesnotexist3 = invalidCertifcate4 = entryIsMIC5 = aaaEntryDoesNotExist · Integer32
This denotes the reason for AP authorization failure. [entrydoesnotexist]: The AP has not been added to Controller's AP Authorization List. [keymismatch]: The key entry in Controller's AP Authorization list does not match the SHA1 key received from the AP. [invalidCert]: Could not verify the self signed Certificate. [entryIsMIC]: AP has Self Signed Certificate where as in Controller AP Authorization list has Manufactured Installed Certificate [aaaEntryDoesNotExist]: RADIUS authorization for the AP failed. [unknown]: Default.
1.3.6.1.4.1.14179.2.6.3.84
When radio module in AP dumps core, it informs controller and controller generates this trap. The core file can be retrieved on demand.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.85
This trap will be generated when an AP has joined is using unsupported radio or a radio slot not currently not being used.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.2.1.1
Unsigned32 (0..2)
The slotId of this interface.
1.3.6.1.4.1.14179.2.6.2.71
INTEGER0 = unsupportedRadio · Integer32
Radio types which are not supported by controller.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.86
This trap will be generated when an operator changes the country of operation. New country code will be sent in trap.
1.3.6.1.4.1.14179.2.3.1.5
INTEGER1 = usa2 = canada3 = france4 = japan5 = mexico6 = spain7 = usalegacy8 = korearepublic9 = australia10 = austria11 = belgium12 = denmark13 = finland14 = germany15 = greece16 = ireland17 = italy18 = luxembourg19 = netherlands20 = portugal21 = sweden22 = unitedkingdom23 = none24 = india25 = hongkong26 = switzerland27 = iceland28 = norway29 = singapore30 = thailand31 = taiwan33 = cyprus34 = czechrepublic35 = estonia36 = hungary37 = lithuania38 = latvia39 = malaysia40 = newzealand41 = poland42 = slovenia43 = slovakrepublic44 = southafrica45 = usachan16546 = israel47 = israelOutdoor48 = argentina49 = brazil51 = saudiArabia52 = turkey53 = indonesia54 = china55 = koreaExtended56 = japan257 = gibraltar58 = liechtenstein59 = malta60 = monaco61 = romania62 = russianfederation63 = chile64 = colombia65 = panama66 = peru67 = venezuela68 = philippines · Integer32
This attribute identifies the country in which the station is operating.
1.3.6.1.4.1.14179.2.6.3.87
This trap will be generated when unsupported AP try to join 40xx/410x or 3500 with 64MB flash.
1.3.6.1.4.1.14179.2.2.1.1.1
MacAddressRepresents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. SIZE (6) · OCTET STRING · hint 1x:
The MAC address of an AP.
1.3.6.1.4.1.14179.2.2.1.1.3
OCTET STRING SIZE (0..32)
Name assigned to this AP. If an AP is not configured its factory default name will be ap:<last three byte of MACAddress> eg. ap:af:12:be
1.3.6.1.4.1.14179.2.6.3.88
This trap will be generated when controller loses connection with the Supervisor Switch in which it is physically embedded and doesn't hear the heartbeat keepalives from the Supervisor.
1.3.6.1.4.1.14179.2.6.3.89
This trap will be generated by the location server for notifications of location events.
1.3.6.1.4.1.14179.2.6.2.72
OCTET STRING SIZE (0..512)
This is the content of the notification.