NoSuchObject values need to be handled better by zino.snmp

[lunkwill42]

Learning the ins and outs of SNMP all over again. Case in point:

juniperalarmtask keeps logging for many devices the following:

ERROR - zino.tasks.juniperalarmtask (MainThread) - Device example-gw returns alarm count not of type int. Yellow alarm count: <class 'str'>. Red alarm count: <class 'str'>.

The value returned from the call to SNMP.get() here is an empty string, ''. This is because the device does not actually have the object that was asked for. This "error" it not signalled as a protocol error or other kind of error indicator in the SNMP PDU, but rather as the special value NoSuchObject in the varbinds list. This value is passed to the _mib_value_to_python() function to be converted to a Python object, which basically converts the special NoSuchObject value into an empty string.

We need to decide what to do with NoSuchObject values. Since SNMP.get() only takes a single object as its argument, it should probably raise an exception when this happens. However, any method that can send queries for multiple objects doesn't have it as easy, since it can happen that only a single of the queried objects returns a NoSuchObject value, while the others are fine.

[lunkwill42]

NAV's synchronous SNMP library features this kind of error reporting - i.e., like Zino, it has a separate function to inspect a response for errors and raise exceptions - but it doesn't just look at the response's error indicators, but also at the returned varbinds:

https://github.com/Uninett/nav/blob/e2977725293f2687d62a5b8cfe657fcb21bfeb46/python/nav/Snmp/pynetsnmp.py#L461-L484

[lunkwill42]

Selected quotes from RFC 2576 (Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework):

Note that SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors.

and

SNMPv2 provides a feature called exceptions, which allow an SNMPv2 Response PDU to return as much management information as possible, even when an error occurs. However, SNMPv1 does not support exceptions, and so an SNMPv1 Response PDU cannot return any management information, and can only return an error-status and error-index value.

Also from RFC 3416 (Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP):

The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI [RFC2578] or the textual conventions based on the SMI [RFC2579]. The term "variable binding" normally refers to the pairing of the name of a variable and its associated value. However, if certain kinds of exceptional conditions occur during processing of a retrieval request, a variable binding will pair a name and an indication of that exception.

In other words, this way of signalling errors by having special values in the varbinds of a response is called "exceptions", and was introduced first in SNMP v2.