Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Can't use SNMPv3 with NoAuth-NoPriv

Description

This issue is at the root of the following commercial support ticket:
https://mynms.opennms.com/Ticket/Display.html?id=2415

Using a configuration like the following:

<definition version="v3" security-name="topsecret" context-name="VF:2">

OpenNMS is going to force some default values for the following SNMPv3 settings when building the SNMPv3 PDU Requests:

  • auth-protocol

  • auth-passprase

  • privacy-protocol

  • privacy-passphrase

For this reason, the final request is built on a wrong way, because the remote agent expect to use only the security-name.

SNMP4J expects to receive null for optional parameters if they are not required. Actually, it is possible to execute an snmpwalk using SNMP4J as follow:

/opt/opennms/bin/snmp-request -Ow -v 3 -u opennmsuser -n VF:2 100.0.0.1 1.3.6.1.2.1.4.20
Using SNMP4J from: /opt/opennms/lib/snmp4j-1.11.1.jar

1.3.6.1.2.1.4.20.1.1.10.11.12.58 = 10.11.12.58
1.3.6.1.2.1.4.20.1.1.10.11.12.59 = 10.11.12.59
1.3.6.1.2.1.4.20.1.1.127.0.0.1 = 127.0.0.1
1.3.6.1.2.1.4.20.1.2.10.11.12.58 = 805306369
1.3.6.1.2.1.4.20.1.2.10.11.12.59 = 805306375
1.3.6.1.2.1.4.20.1.2.127.0.0.1 = 805306370
1.3.6.1.2.1.4.20.1.3.10.11.12.58 = 255.255.255.0
1.3.6.1.2.1.4.20.1.3.10.11.12.59 = 255.255.255.0
1.3.6.1.2.1.4.20.1.3.127.0.0.1 = 255.255.0.0
1.3.6.1.2.1.4.20.1.4.10.11.12.58 = 1
1.3.6.1.2.1.4.20.1.4.10.11.12.59 = 1
1.3.6.1.2.1.4.20.1.4.127.0.0.1 = 0

Because the above query is working fine, we can discard any problems with SNMP4J, so the problem is related with how the SNMPv3 settings are parsed, processed and/or passed to SNMP4J, when building the SNMPv3 PDU requests.

Acceptance / Success Criteria

None

Attachments

1
  • 13 Sep 2013, 04:54 PM

Lucidchart Diagrams

Activity

Show:

Alejandro Galue September 14, 2013 at 9:25 AM

It turns out that it is valid to specify only the passwords and OpenNMS should pick the defaults for the protocols, for example:

<definition version="v3" security-name="opennmsUser" auth-passphrase="0p3nNMSv3" privacy-passphrase="0p3nNMSv3">
<specific>10.0.0.1</specific>
</definition>

The above configuration set assumes that the default values for auth-protocol and privacy-protocols must be used, for this reason some changes are required. This use case was cached by a Bamboo failure:

http://bamboo.internal.opennms.com:8085/browse/OPENNMS-NMS7-39

Changes committed on revision ba305852996c035831f46a6b3ec2d9056f30560f for 1.12 and merged into master on revision de8f1bde817d895556177aab916a486f0249264b

Alejandro Galue September 13, 2013 at 4:59 PM

Fixed on revision 0ad8d1af51b4787e6995b60913df558ebd53e151 for 1.12 and merged into master on revision 7d5b1df52477110309da3dc214f85338d412c321

Alejandro Galue September 13, 2013 at 4:54 PM

A set of new JARs where built based on the proposed patch (snmpv3.patch), and the customer said that OpenNMS can communicate with the SNMPv3 device, using the simple SNMPv3 configuration with only a security-name and a context-name.

The proposed patch also include something missing on the solution for https://opennms.atlassian.net/browse/NMS-5556#icft=NMS-5556, in order to properly build the PDU if the context-name and/or the enterprise-context-id are defined on the configuration.

The patch is based on 1.12, for master, different changes are required on the pom.xml, but still all tests from opennms-config and core/snmp are passing on both branches.

Fixed

Details

Assignee

Reporter

Labels

Components

Fix versions

Affects versions

Priority

PagerDuty

Created September 13, 2013 at 4:48 PM
Updated January 27, 2017 at 4:20 PM
Resolved September 13, 2013 at 4:59 PM

Flag notifications