Trapd is not able to process SNMPv3 INFORMs
Description
Environment
Acceptance / Success Criteria
Attachments
Lucidchart Diagrams
Activity
Alejandro Galue March 5, 2015 at 12:23 PM
The JUnit test were failing with the original fix, so I reworked the fix on revision 308cc4922206a1398333071519451ba37c419f7b for foundation.
Alejandro Galue March 4, 2015 at 12:15 PM
Fixed on revision 06562f8d457300b14f0e76df93bdf4645ae4be2a for foundation.
Seth Leger September 18, 2014 at 3:51 PM
This should be retested during 1.14 testing to see if the upgraded version of snmp4j makes a difference.
Peter Eckel December 16, 2012 at 2:17 PM
Another update to this.
I tried to leave the encryption part out of the picture by modifying the OpenNMS setup so that the user does not require encryption. Unfotunately, the SNMP inform request fails again, and in this case it is easy to see why: The response PDU is missing from the SNMPv3 packet ...
I'll add another screen shot and another packet dump.
Peter Eckel December 16, 2012 at 2:00 PM
I have some more information on this, and steps to reproduce.
Actually the problem can be isolated with SNMPv3 informs, traps work fine. First of all, here is the method to reproduce the problem.
1. Set up an SNMPv3 user in etc/trapd-configuration.xml (and restart OpenNMS afterwards)
[code]
<snmpv3-user security-name="OpenNMS-Inform"
security-level="3"
auth-protocol="SHA"
auth-passphrase="opennms-inform-auth"
privacy-protocol="AES"
privacy-passphrase="opennms-inform-priv" />
[code]
2. Determine the IP address of the OpenNMS box in hexadecimal form. By default, OpenNMS uses the IP address to generate the security engine ID, so if, for example, the actual IP address is 192.168.42.74, the hexadecimal form would be C0A82A4A. The engine ID is that IP address, prefixed by the enterprise identifier 800016b5 and the engine ID format identifier 01, which makes it 800016b501C0A82A4A in this example.
3. Send an arbitrary SNMPv3 inform using the Net-SNMP snmpinform tool:
[code]
snmpinform -v3 -u OpenNMS-Inform \
-e 800016b501C0A82A4A \
-l authPriv \
-a SHA -A opennms-inform-auth \
-x AES -X opennms-inform-priv \
192.168.42.74 0 1.3.6.1.4.1.15904.1.1.2.0.1
[code]
The OID of the inform doesn't matter. Just the authentication parameters and the engine ID must match.
Two things will happen:
The SNMP inform will arrive in OpenNMS 5 times (more or less, depending on the setting for 'retries' in the Net-SNMP configuration - 5 is default)
The CLI tool will receive an error message and a timeout:
[code]
No log handling enabled - using stderr logging
snmpinform: Timeout (plaintext scopedPDU header type A2: s/b 30)
[code]
I dug into this a bit deeper using WireShark, and the problem seems to be that the packet from the Net-SNMP client tool is authenticated and encrypted properly, while the Response PDU from OpenNMS/SNMP4J is correctly authenticated, but the encrypted PDU is corrupt.
I'll attach a screen shot and the capture file shortly.
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.