Bug in snmp-ups.c causes bogus “unhandled ASN0x80” messages to be logged #1358
Description
There is a bug in snmp-ups.c that causes the following message to be written to syslog repeatedly (when using the ietf SNMP driver):
unhandled ASN 0x80 received from .1.3.6.1.2.1.33.1.7.7.1`
The problem is in nut_snmp_get_int: When this function processes a response of type ASN_OBJECT_ID, it tries to resolve this object ID. In case of the upsTestId (a.k.a. 1.3.6.1.2.1.33.1.7.1.0 as defined in ietf-mib.c), this does not work because the returned OID should be interpreted as a constant instead of a pointer to another value.
From the IETF UPS MIB:
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The test is named by an OBJECT IDENTIFIER which
allows a standard mechanism for the initiation of
tests, including the well known tests identified in
this document as well as those introduced by a
particular implementation, i.e., as documented in the
private enterprise MIB definition for the device.
Setting this variable initiates the named test. Sets
to this variable require the presence of
upsTestSpinLock in the same SNMP message.
The set request will be rejected with an appropriate
error message if the requested test cannot be
performed, including attempts to start a test when
another test is already in progress. The status of
the current or last test is maintained in
upsTestResultsSummary. Tests in progress may be
aborted by setting the upsTestId variable to
upsTestAbortTestInProgress.
Read operations return the value of the name of the
test in progress if a test is in progress or the name
of the last test performed if no test is in progress,
unless no test has been run, in which case the well
known value upsTestNoTestsInitiated is returned."
::= { upsTest 1 }
and
upsWellKnownTests OBJECT IDENTIFIER ::= { upsTest 7 }
upsTestNoTestsInitiated OBJECT-IDENTITY
STATUS current
DESCRIPTION
"No tests have been initiated and no test is in
progress."
::= { upsWellKnownTests 1 }
So, the OID 1.3.6.1.2.1.33.1.7.7.1 represents a constant, that should not really be resolved.
The code still works, because nut_snmp_get_int falls back to using the last part of the OID as the integer value, when the recursive call to nut_snmp_get_int fails, but it leads to the annoying
unhandled ASN 0x80 received from .1.3.6.1.2.1.33.1.7.7.1`
message being logged each time this function is called for the upsTestId.
I would be happy to submit a PR that fixes this issue, but I think it might make sense to first discuss in which way it should be fixed. I see three possible solutions:
-
Remove the call to
upslogxinnut_snmp_get_intand replace it with a call toupsdebugx. This will have the effect that the message is not going to be logged when the driver is running normally (without debugging enabled). The downside is that the message will not be logged either whennut_snmp_get_intfails for a valid reason, so it isn’t my first choice. -
Add a new parameter
supress_error_messagetonut_snmp_get_intand do not log the message when this parameter is set. We can then set this parameter when making the recursive call tonut_snmp_get_int, thus supressing the message when we don’t want it. This is my preferred solution. -
Use
nut_snmp_get_oidinstead ofnut_snmp_get_intwhen retrievingupsTestId. However, I don’t think that this could easily be done within the constraints of the current code architecture, so it probably is much more difficult to do it this way then using solution number two.