Details
-
Type:
Enhancement
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 21.1.0
-
Fix Version/s: 22.0.0, Meridian-2018.1.0
-
Component/s: Event Reception - SNMP Traps
-
Security Level: Default (Default Security Scheme)
-
Labels:None
-
Sprint:Horizon - May 2nd 2018, Horizon - May 9th 2018, Horizon - May 16th 2018
Description
I tried to send a SNMPv3 trap with Net-SNMP utils tools snmptrap to OpenNMS Horizon and couldn't get it work.
I've configured trapd-configuration.xml with the following content:
<trapd-configuration xmlns="http://xmlns.opennms.org/xsd/config/trapd" snmp-trap-address="*" snmp-trap-port="162" new-suspect-on-trap="false" include-raw-message="false" threads="0" queue-size="10000" batch-size="1000" batch-interval="500"> <snmpv3-user security-name="trapuser" security-level="3" auth-passphrase="authsecret" auth-protocol="SHA" privacy-passphrase="privsecret" privacy-protocol="AES"/> </trapd-configuration>
After restarting OpenNMS I tried to send a trap with the following command:
snmptrap -Dusm -v 3 -l authPriv -u trapuser -a SHA -A authsecret -x AES -X privsecret 127.0.0.1 42 coldStart.0
I tried also to use the generated OpenNMS Horizon EngineID described in NMS-2995 without any success.
The output from snmptrap command is
registered debug token usm, 1 usm: potentially bootstrapping the USM table from session data usm: no flag defined... continuing usm: user exists? x=(nil) usm: Building user trapuser... usm: USM processing has begun (offset 80) usm: getting user trapuser usm: match on user trapuser usm: Failed to find engine data. usm: Encryption successful. usm: USM processing completed.
I get the following error message in ${OPENNMS_HOME}/logs/trapd.logtrapd-log which I've set to debug:
2018-04-27 12:38:58,079 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] o.s.m.MPv3: SNMPv3 header decoded: msgId=1004545905, msgMaxSize=65507, msgFlags=03, secModel=3 2018-04-27 12:38:58,080 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] o.s.s.USM: RFC3414 ?3.2.4 Unknown security name: 74:72:61:70:75:73:65:72 2018-04-27 12:38:58,080 WARN [DefaultUDPTransportMapping_0.0.0.0/162] o.s.MessageDispatcherImpl: statusInfo=1.3.6.1.6.3.15.1.1.3.0 = 0, status=1404
I've translated the RFC3414 ?3.2.4 Unknown security name: 74:72:61:70:75:73:65:72 into ASCII which is trapuser.