Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-6202

net-snmp extend output not properly interpreted if numbers are exactly 8 characters long

    Details

      Description

      If the output of an net-snmp extend command value is exactly 8 bytes it is interpreted as a 64bit number instead of a string containing a base 10 digits.
      I have located the problem and made a patch, but this patch will fail if the value is really a 64 bit number that happens to consist of 8 bytes that happen to be in the ascii range representing digits. It would probably be better to check if the value is really of a 64 bit type, but I don't know how this can be done reliably.

      snmpwalk example to show what I am referring to:

      1. snmpwalk -v2c -c monty localhost .1.3.6.1.4.1.8072.1.3.2.4.1.2.17.111.101.45.116.111.116.97.108.45.114.101.113.117.101.115.116.115
        ...
        NET-SNMP-EXTEND-MIB::nsExtendOutLine."oe-total-requests".49 = STRING: 49197860
        ...

      The problem is 49197860 is exactly 8 bytes, if it were 7 or 9 it would not cause any problems.

      The following is found in the collectd.log when encountering such values:

      2013-10-21 11:52:40,142 INFO [LegacyScheduler-Thread-6-of-50]
      SnmpUtils: Value '30048428' is entirely displayable. Still treating it
      as a proto-Counter64. This may not be what you want.
      2013-10-21 11:52:40,142 INFO [LegacyScheduler-Thread-6-of-50]
      RrdUtils: updateRRD: updating RRD file
      /opt/opennms/share/rrd/snmp/1/oeAppserverInst/r40.TVH/oeTotalRequests.jrb
      with values '1382349160:3688501095655813688'

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                seth Seth Leger
                Reporter:
                jankeir Jan Keirse
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: