2

Is there a response to indicate that there is no value for that OID, or should it just return nothing?

QuestionC
  • 10,006
  • 4
  • 26
  • 44

2 Answers2

3

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.

Community
  • 1
  • 1
  • 1
    Note that the question said "how is an SNMP Agent supposed to respond", but you seem to have answered "how is an SNMP command line tool supposed to respond". Lex Li's answer is the correct one. – Jolta Nov 17 '14 at 10:33
  • I used the command line utilities because they're defacto standard and it gave an immediately usable response. Edited post to add RFCs. –  Nov 20 '14 at 15:36
  • It should be clearly stated that the command line utilities referred in this answer are from the NET-SNMP project, one of the earliest implementations of the RFC documents and shipped with many Linux distributions as well as macOS. That makes it the de facto standard on behaviors not specified by the RFC documents themselves. Other open source projects also offer similar command line utilities but their behaviors vary. – Lex Li Jan 12 '23 at 21:11
2

The behavior follows the standard RFC documents, like

Community
  • 1
  • 1
Lex Li
  • 60,503
  • 9
  • 116
  • 147
  • As is typical of everything surrounding this spec, nothing is consistent. RFC1157, 4.1.2 as well as RFC 1905, 3 imply that a GetRequest-PDU is a value zero (if I interpret this poorly documented SMI, because [ ] is not the same as { }, and is not the same as ( ), as isn't defined anyplace easily locatable ). However, everything I sniff and find *outside* of these specs indicate that a SNMPv1 GetRequest-PDU seems to be an "xA0". I can find no explanation of where the high order bits 7 and 5 come into play. – SpacemanScott Jan 12 '23 at 17:50
  • I planned to delete this answer soon, but before that just comment further on your observation. Unfortunately the knowledge around how `xA0` was calculated was lost in younger generations including myself, so don't push yourself too hard on that as it never matters much. Many classic books in this field did not even mention those details. – Lex Li Jan 12 '23 at 21:21
  • Something like **::= { system 5 }** makes sense. As does **INTEGER { noError(0), ... }**. But **GetRequest-PDU ::= [0] IMPLICIT PDU** is inconsistent in it's numeric decoration, which makes it unclear. Especially since all the specs are assigning GetRequest as 0, and doesn't match what's in practice. What I get from this is "don't follow the spec, no one else did". Not very reassuring. – SpacemanScott Jan 13 '23 at 03:47
  • @SpacemanScott But `[0] IMPLICIT` belongs to the syntax of ASN.1, you can either refer to its own RFC documents or discussions like https://stackoverflow.com/questions/3296761/i-need-an-example-to-understand-implicit-tagging-in-asn-1 Too many to explore. – Lex Li Jan 13 '23 at 07:38
  • I found information deep in a source explaining GetRequest-PDU as 0 vs xA0... In the TLV, the 'type' msb two bits define 'class', and bit 5 defines a 'simple (0)' or 'constructed (1)' type. So the GetRequest-PDU is 0, with the class set to "Context-Specific', and 'constructed' bit set (b101). It's deceptive when everyone says 0x30 a SEQUENCE. Actually a SEQEUNCE is 0x10 with the 'constructed' bit set. Just more things that generate confusion. I'd post this as an "answer", but doesn't apply to the two posts we've been commenting on. – SpacemanScott Jan 13 '23 at 14:39
  • @SpacemanScott Actually you can post a new question to match your investigation and then post/accept your own answer to capture all the research you've done. That's a common way people contribute important knowledge to Stack Overflow. Good luck. – Lex Li Jan 13 '23 at 16:05