tobez
Documentation for GETTABLE error responses
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.
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
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)
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