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

Trapd is not able to process SNMPv3 INFORMs

    XMLWordPrintable

    Details

      Description

      SNMPv3 traps received from IP addresses not managed by openNMS will be (almost) silently discarded because no SNMP session exists for these addresses and the SNMP4J transport mapping therefore does not know which security-name to accept as valid. This is true regardless of whether valid USM credentials are present in snmp-config.xml. On my system, the following message appears in snmp4j-internal.log when such a trap arrives:

      2008-12-08 20:34:05,205 WARN [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.MessageDispatcherImpl: 1.3.6.1.6.3.15.1.1.3.0 = 0

      While this sounds like a REPORT PDU, I don't see such a PDU actually being sent.

      Initializing the SnmpPeerFactory in Trapd.onInit() does not resolve this issue. I think it may take some loving handling of the transport mapping on Trapd startup to get past this issue.

      According to the customer reporting this issue, V3 traps at security level authPriv worked in openNMS 1.3.2; probably the much older version of SNMP4J used by that release was less strict about this issue.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: