Documentation for GETTABLE error responses

[candlerb]

According to the manual entry for GETTABLE:

Possible errors are the same as in GET request, plus the following ...

However:

(1) When trying to retrieve a non-existent OID it just returns an empty list. Example: query IP-MIB::ipNetToPhysicalTable on a switch which doesn't implement it.

GET returns:
[20, 456, [['1.3.6.1.2.1.4.35', ['no-such-object']]]]

GETTABLE returns:
[21, 456, []]

Looking on the wire: the first case receives a response object which tcpdump decodes as noSuchObject; the second case just gives MIB values starting from the next available entry (in my test 1.3.6.1.2.1.5.1.0)

This suggests that getbulk can't distinguish "empty table" from "non-existent table", in which case the current SQE behaviour is reasonable, but I think this could be clarified in the documentation as the behaviour is different to GET.

(2) Forcing an error by issuing a GETTABLE request for OID "2", I get the following:

[37, 456, 'bad oid']

So the result code is there but not wrapped in an array, as it would be for GET. This conflicts with the manual which says:

The second element will either be a value, or an array with a single element. If it is an array, its only element will be an error description.

[tobez]

On Mon, Jul 07, 2014 at 01:15:30AM -0700, Brian Candler wrote:

(2) Forcing an error by issuing a GETTABLE request for OID "2", I get the
following:

[37, 456, 'bad oid']

So the result code is there but not wrapped in an array, as it would be for
GET. This conflicts with the manual which says:

The second element will either be a value, or an array with a single
element. If it is an array, its only element will be an error description.

Er. I don't see a contradiction. The doc says:

   All responses will be an array of at least  two  elements.   The first
   element  will  be  the request type ORed with either 0x10 to indicate a
   successfull reply, or with 0x20 to indicate an error.  The second ele-
   ment will be the request id.  In case of an error, the third, and last,
   element will be a textual description of the error.  In case of a suc-
   cessfull  reply,  the  rest  of  response  array  elements  are request
   type-specific, and are described below.

Since you are getting the error bit set in this particular instance, the
general rule above applies.

Only if GETTABLE did not produce a fatal error which invalidates the whole
query, will you see the behavior you quoted. Let me quote that again in
context:

   GETTABLE reply consists of an array, each element of which corresponds
   to  a single oid from the requested table.  Each such element is itself
   a two-element array.  The first element will be oid itself.  The second
   element  will either be a value, or an array with a single element.  If
   it is an array, its only element will be an error description.

\Anton.

Our society can survive even a large amount of irrational regulation.
-- John McCarthy

[candlerb]

OK, I see now that "bad oid" is an error from SQE not from the SNMP device, and the error flag is set. If I pass "2.0" as the OID then it's happy and gives me an empty table.

What I'm trying to say is this: when reading a non-existent table I was expecting to see errors of the form

[21, 101, [["1.2.3.4", ["something-went-wrong"]]]]

because the documentation says that GETTABLE can return the same errors as GET, and GET would return ["no-such-instance"]. Instead I see:

[21, 101, []]

To avoid confusion, you could just add that if no data exists under the given OID this is not considered an error and an empty array will be returned.

Example 2 sort-of covers it, except this is a special case - asking to walk a single OID. Here the OID does exist, it's just that SQE won't return the top-level OID unless there's an error. (For comparison, in net-snmp, snmpbulkwalk is happy to walk a single OID)

[tobez]

On Mon, Jul 07, 2014 at 03:49:01AM -0700, Brian Candler wrote:

What I'm trying to say is this: when reading a non-existent table I was
expecting to see errors of the form

[21, 101, [["1.2.3.4", ["something-went-wrong"]]]]

because the documentation says that GETTABLE can return the same errors as GET,
and GET would return ["no-such-instance"]. Instead I see:

[21, 101, []]

Yup, I got your point. I was simply replying to the second part of your
mail. :)

To avoid confusion, you could just add that if no data exists under the given
OID this is not considered an error and an empty array will be returned.

Example 2 sort-of covers it, except this is a special case - asking to walk a
single OID. Here the OID does exist, it's just that SQE won't return the
top-level OID unless there's an error. (For comparison, in net-snmp,
snmpbulkwalk is happy to walk a single OID)

I'll try to clarify the docs on this point.

\Anton.

Our society can survive even a large amount of irrational regulation.
-- John McCarthy