Home
You are not currently signed in.

MIB Smithy

  1. Up to Table of Contents

Variable Bindings

The varBindList parameter, which need not be present, is used by the SNMP Request subcommands (get, set, next, and set) to specify each object identifier, type, and value to be included in the transmitted PDU. The value of the parameter is a list of varBind parameters as follows:

?varBind ?varBind? ...?

Each varBind is itself a list that can have 1, 2 or 3 parameters indicating the object identifier (required), the value (optional) and, if necessary, the data type to use when encoding the value. Accepted forms for varBind are:

  • oid
  • oid value
  • oid type value

The oid parameter can be specified using any of the values accepted by the SMI Database's get subcommand specifying a query search string. That is, it could be an identifier such as system, an absolute OID such as 1.3.6.1.2.1.1.1.0, a relative OID such as sysDescr.0 or a multi-envelope search string such as @File1!SNMPv2-MIB!sysDescr.0. The configured (or specified) SMI Database will be queried, as necessary, to convert the specified oid parameter to a fully-qualified OID value.

The type parameter, if present, can also be specified using either one of the fundamental SNMP data types (such as INTEGER or OCTET STRING) or as a defined datatype as with the SMI Database's get subcommand query search string, such as RowStatus or SNMPv2-TC!RowStatus. If the type parameter is not present, or if it is not one of the fundamental SNMP data types, then the configured (or specified) SMI Database will be queried to determine the appropriate data type as necessary.

The valid values for the value depend on the data type. Typically this must be the raw (unformatted) value, such as an integer or a character or binary string. For OBJECT IDENTIFIER values, the value specified may take the same forms as those for the oid parameter: the SDK will automatically convert the search specification into an absolute OID to send in the message. For enumerated INTEGER values, versions 3.4 and later of the SDK accept integer values, a label (such as 'destroy' for RowStatus), or both a label and the integer value (such as 'destroy(6)').

The value may be specified for "read" operations (GET, GET-NEXT, GET-BULK) and, if specified, will be included in the PDU; however, properly implemented agents will ignore them in handling such requests.

In result list returned during a synchronous request call, or passed to the args parameter of the callback function, the -varbinds field indicates the variable bindings in the response. The format for this field is the same as that for requests, however all three parameters are present for each variable binding.

Three special keywords may be present for the value field when the type field is NULL and the PDU is encapsulated in an SNMPv2c or SNMPv3 message. These keywords correspond to the three "exceptions" defined by the SNMPv2 PDUs (which are also used by SNMPv3), and they are: endOfMibView, noSuchObject and noSuchInstance.

Example 1 - GET/GET-NEXT/GET-BULK Request Forms:

% snmplib get 1.3.6.1.2.1.1.1.0
% snmplib get { { 1.3.6.1.2.1.1.1.0 } }
% snmplib get [list [list 1.3.6.1.2.1.1.1.0]]
% snmplib get [list sysContact.0 sysLocation.0]
% snmplib get [list SNMPv2-MIB!sysContact.0 SNMPv2-MIB!sysLocation.0]
% snmplib get [list [list 1.3.6.1.2.1.1.1.0 NULL NULL]]

Example 2 - SET Request Forms:

% snmplib set { { 1.3.6.1.2.1.1.4.0 "New Contact" } }
% snmplib set [list [list 1.3.6.1.2.1.1.4.0 "New Contact"]]
% snmplib set [list [list sysContact.0 DisplayString "New Contact"]]
% snmplib set [list [list sysContact.0 DisplayString "New Contact"] \
    [list sysLocation.0 DisplayString "New Location"]]

Example 3 - endOfMibView Exception:

% array set result [snmplib next -version SNMPv2c 2.0]
% array get result -status
noError
% array get result -varbinds
-varbinds {{2.0 NULL endOfMibView}}
  1. Up to Table of Contents