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

Configuring SNMP broken for biggish IPv4 ranges

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.9.91
    • Fix Version/s: 1.9.93
    • Component/s: Architecture
    • Security Level: Default (Default Security Scheme)
    • Labels:

      Description

      Encountered while delivering on-site training for JTAC team. Filing under architecture because this would seem to affect the webapp, the ReST API, and direct creation of the configureSNMP event all equally, and no other component fits better.

      Steps to reproduce:

      1. In web UI as an admin user, navigate Admin -> Configure SNMP Community Names by IP
      2. In "First IP Address", enter "1.1.1.1" or "0.0.0.0". In "Last IP Address" enter any IPv4 address from "128.0.0.0" through "255.255.255.255"
      3. Enter a community string and, if you like, some other stuff too.
      4. Submit the form

      Expected result:
      Success indication from web UI plus reflection of the indicated changes in OPENNMS_HOME/etc/snmp-config.xml

      Actual result:
      Success indication from web UI but no changes to snmp-config.xml. Also observe a seemingly nonsensical error message and exception stack trace in collectd.log:

      2011-10-06 08:35:45,119 ERROR [OpenNMS.Collectd] SnmpEventInfo: createDef: Can not create Definition when specified last is < first IP address: Info:
      first: 1.1.1.1
      last: 255.255.255.255
      version: v2c
      community string: private
      port: 0
      retry count: 1
      timeout: 3600
      2011-10-06 08:35:45,119 ERROR [OpenNMS.Collectd] Collectd: configureSNMPHandler:
      java.lang.IllegalArgumentException: First: 1.1.1.1 is greater than: 255.255.255.255
      at org.opennms.netmgt.config.SnmpEventInfo.createDef(SnmpEventInfo.java:302)
      at org.opennms.netmgt.config.SnmpPeerFactory.define(SnmpPeerFactory.java:683)
      at org.opennms.netmgt.collectd.Collectd.handleConfigureSNMP(Collectd.java:799)
      at org.opennms.netmgt.collectd.Collectd.onEventInTransaction(Collectd.java:714)
      at org.opennms.netmgt.collectd.Collectd.access$400(Collectd.java:88)
      at org.opennms.netmgt.collectd.Collectd$3.doInTransaction(Collectd.java:697)
      at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
      at org.opennms.netmgt.collectd.Collectd.onEvent(Collectd.java:694)
      at org.opennms.netmgt.eventd.EventIpcManagerDefaultImpl$ListenerThread.run(EventIpcManagerDefaultImpl.java:175)
      at java.lang.Thread.run(Thread.java:679)

      Additional notes:

      Entering a "Last IP Address" of 127.255.255.255 or smaller does not trigger this problem. Neither does leaving blank the "Last Address" field. Looks like a math error in either InetAddressUtils.difference or in SnmpEventInfo.createDef. Probably also reproducible using IPv6 addresses but I haven't had time or reason to try that.

      This bug might explain the scattered reports we've seen of late that users are sometimes allowed to enter ranges where the starting address is larger than the ending address, and the hosed ranges actually get persisted to snmp-config.xml.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: