Reputation: 10064
Is there a response to indicate that there is no value for that OID, or should it just return nothing?
Upvotes: 2
Views: 5464
Reputation:
It depends.
For example, the snmpget
tool that is installed from the SNMP package on Debian both complains about a missing OID and doesn't, in a way.
Take for example, some basic SNMP OIDs:
root@debian:~# snmpwalk -v2c -cpublic localhost
...
iso.3.6.1.2.1.1.5.0 = STRING: "debian"
iso.3.6.1.2.1.1.6.0 = STRING: "Sitting on the Dock of the Bay"
Using snmpget
will complain when you feed it a missing OID:
root@debian:~# snmpget -v2c -cpublic localhost iso.3.6.1.2.1.1.6.1
iso.3.6.1.2.1.1.6.1 = No Such Instance currently exists at this OID
However, it will return a zero code, signalling that it's "okay" that it doesn't exist:
root@debian:~# echo $?
0
If you're writing your own tool or script that reads from SNMP, it really comes down to how important it is for you to know that the OID is missing/invalid. I'd recommend checking out the net-snmp documentation/coding tutorials if you're looking for authoritative examples.
edit: And here are some RFCs if that's your sort of thing (links stolen from Lex Li's answer)
RFC 3416, 4.2.1 for SNMP v2c and above GET request processing
4.2.1. The GetRequest-PDU
A GetRequest-PDU is generated and transmitted at the request of an application.
Upon receipt of a GetRequest-PDU, the receiving SNMP entity processes each variable binding in the variable-binding list to produce a Response-PDU. All fields of the Response-PDU have the same values as the corresponding fields of the received request except as indicated below. Each variable binding is processed as follows:
(1) If the variable binding's name exactly matches the name of a variable accessible by this request, then the variable binding's value field is set to the value of the named variable. (2) Otherwise, if the variable binding's name does not have an OBJECT IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER prefix of any (potential) variable accessible by this request, then its value field is set to "noSuchObject".
(3) Otherwise, the variable binding's value field is set to "noSuchInstance".
If the processing of any variable binding fails for a reason other than listed above, then the Response-PDU is re-formatted with the same values in its request-id and variable-bindings fields as the received GetRequest-PDU, with the value of its error-status field set to "genErr", and the value of its error-index field is set to the index of the failed variable binding.
Otherwise, the value of the Response-PDU's error-status field is set to "noError", and the value of its error-index field is zero.
The generated Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetRequest-PDU.
Otherwise, an alternate Response-PDU is generated. This alternate Response-PDU is formatted with the same value in its request-id field as the received GetRequest-PDU, with the value of its error-status field set to "tooBig", the value of its error-index field set to zero, and an empty variable-bindings field. This alternate Response-PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded.
RFC 1157, 4.1.2 for SNMP v1 GET request processing
4.1.2. The GetRequest-PDU
The form of the GetRequest-PDU is:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
The GetRequest-PDU is generated by a protocol entity only at the request of its SNMP application entity.
Upon receipt of the GetRequest-PDU, the receiving protocol entity responds according to any applicable rule in the list below:
(1) If, for any object named in the variable-bindings field,
the object's name does not exactly match the name of some
object available for get operations in the relevant MIB
view, then the receiving entity sends to the originator
of the received message the GetResponse-PDU of identical
form, except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
message.
(2) If, for any object named in the variable-bindings field,
the object is an aggregate type (as defined in the SMI),
then the receiving entity sends to the originator of the
received message the GetResponse-PDU of identical form,
except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
message.
(3) If the size of the GetResponse-PDU generated as described
below would exceed a local limitation, then the receiving
entity sends to the originator of the received message
the GetResponse-PDU of identical form, except that the
value of the error-status field is tooBig, and the value
of the error-index field is zero.
(4) If, for any object named in the variable-bindings field,
the value of the object cannot be retrieved for reasons
not covered by any of the foregoing rules, then the
receiving entity sends to the originator of the received
message the GetResponse-PDU of identical form, except
that the value of the error-status field is genErr and
the value of the error-index field is the index of said
object name component in the received message.
If none of the foregoing rules apply, then the receiving protocol entity sends to the originator of the received message the GetResponse-PDU such that, for each object named in the variable- bindings field of the received message, the corresponding component of the GetResponse-PDU represents the name and value of that variable. The value of the error- status field of the GetResponse- PDU is noError and the value of the error-index field is zero. The value of the request-id field of the GetResponse-PDU is that of the received message.
Upvotes: 3
Reputation: 63264
The behavior follows the standard RFC documents, like
Upvotes: 2