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

The Valere devices with broken SNMP agents are hanging Provisiond.

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.10.13
    • Fix Version/s: 1.12.6, 1.13.1, 1.10.14
    • Security Level: Default (Default Security Scheme)
    • Labels:
    • Environment:
      OpenNMS 1.10.14-SNAPSHOT running on a Linux Machine monitoring some Valere devices.

      Description

      If OpenNMS is configured to discover these Valere devices using SNMPv2, Provisiond is going to enter into an infinite loop because the SNMP agent doesn't implement properly SNMPv2, and it is returning "valid" PDUs without errors but with NO varbinds.

      Actually, the following snmpbulkwalk command (which is similar to the PDU sent by Provisiond while discovering the device) just hang on an infinite loop trying to walk the OIDs, and that is what is happening on Provisiond:

      snmpbulkwalk -d -v 2c -c XXXX -Cn10 -Cr1 Y.Y.Y.Y .1.3.6.1.2.1.1.1 .1.3.6.1.2.1.1.2 .1.3.6.1.2.1.1.3 .1.3.6.1.2.1.1.4 .1.3.6.1.2.1.1.5 .1.3.6.1.2.1.1.6 .1.3.6.1.2.1.4.20.1.1.Y.Y.Y.Y .1.3.6.1.2.1.4.20.1.2.Y.Y.Y.Y .1.3.6.1.2.1.4.20.1.3.Y.Y.Y.Y .1.3.6.1.2.1.4.20.1.4.Y.Y.Y.Y

      Note: I'm masking the customer sensitive information from the above command.

      Note: the above command requires a manual abort in order to terminate it (which is exposing the problem).

      Because of this, Provisiond is not responding and OpenNMS must be restarted.

      The workaround is configuring these Valere devices to use SNMPv1 in OpenNMS, as the following command works fine:

      snmpgetnext -v 1 -c 7XXXX Y.Y.Y.Y .1.3.6.1.2.1.1.1 .1.3.6.1.2.1.1.2 .1.3.6.1.2.1.1.3 .1.3.6.1.2.1.1.4 .1.3.6.1.2.1.1.5 .1.3.6.1.2.1.1.6 .1.3.6.1.2.1.4.20.1.1.Y.Y.Y.Y .1.3.6.1.2.1.4.20.1.2.Y.Y.Y.Y .1.3.6.1.2.1.4.20.1.3.Y.Y.Y.Y .1.3.6.1.2.1.4.20.1.4.Y.Y.Y.Y
      SNMPv2-MIB::sysDescr.0 = STRING: Sys Description
      SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.13858
      DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (2313260404) 267 days, 17:43:24.04
      SNMPv2-MIB::sysContact.0 = STRING: support@valerepower.com
      SNMPv2-MIB::sysName.0 = STRING: XXXXXX
      SNMPv2-MIB::sysLocation.0 = STRING: XXXXXX
      IP-MIB::ipAdEntAddr.Y.Y.Y.Y = IpAddress: Y.Y.Y.Y
      IP-MIB::ipAdEntIfIndex.Y.Y.Y.Y = INTEGER: 1
      IP-MIB::ipAdEntNetMask.Y.Y.Y.Y = IpAddress: 255.255.255.240
      IP-MIB::ipAdEntBcastAddr.Y.Y.Y.Y = INTEGER: 1

      Note: I'm masking the customer sensitive information from the above output.

      The idea is to modify the PDU walk processing in OpenNMS in order to abort the walk if the response is valid and contains 0 varbinds as a defensive code against these broken SNMP agents.

        Attachments

          Activity

            People

            • Assignee:
              agalue Alejandro Galue
              Reporter:
              agalue Alejandro Galue
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: