From: Moein E. <moe...@gm...> - 2011-06-01 04:10:51
|
Hi Would you please help me on how to configure opennms config files to receive SnmpV3-Traps (or inform)? Currently I have a NetSNMP command which send v2 traps and *I can correctly receive it* in opennms events list. *>> snmptrap -Ci -v 2c -c public 192.168.0.26 "" 1.3.6.1.4.1.36353231.2.2.0 1.3.6.1.4.1.36353231.2.1 i 2* But as mutch as I try to send a *V3Trap * *>>snmptrap -Ci -v 3 -u admin -a SHA -A myPass -x AES -X myPass -l authPriv localhost "" 1.3.6.1.4.1.36353231.2.2.0 1.3.6.1.4.1.36353231.2.1 i 2* , I got an* authentication exception* on my agent. Thanks a lot for any comments and helps Moein Enayati |
From: Kevin K. <kev...@me...> - 2011-06-01 11:25:21
|
Hi, someone might correct me if I?m wrong but OpenNMS is still not able to recieve SNMP V3 Informs or Traps. Von: Moein Enayati [mailto:moe...@gm...] Gesendet: Mittwoch, 1. Juni 2011 06:10 An: ope...@li... Betreff: [opennms-discuss] How to Receive V3-Traps in openNMS Hi Would you please help me on how to configure opennms config files to receive SnmpV3-Traps (or inform)? Currently I have a NetSNMP command which send v2 traps and I can correctly receive it in opennms events list. >> snmptrap -Ci -v 2c -c public 192.168.0.26 "" 1.3.6.1.4.1.36353231.2.2.0 1.3.6.1.4.1.36353231.2.1 i 2 But as mutch as I try to send a V3Trap >>snmptrap -Ci -v 3 -u admin -a SHA -A myPass -x AES -X myPass -l authPriv localhost "" 1.3.6.1.4.1.36353231.2.2.0 1.3.6.1.4.1.36353231.2.1 i 2 , I got an authentication exception on my agent. Thanks a lot for any comments and helps Moein Enayati |
From: Moein E. <moe...@gm...> - 2011-06-01 11:44:59
|
I've heard some where it's a bug with NetSNMP API , but what about SNMNP4J ? |
From: David H. <da...@op...> - 2012-01-30 12:00:29
|
On Jan 30, 2012, at 6:26 AM, djrfnet wrote: > anyone got any more comments? Can I raise a bug report regarding to this? Does the "bug" still occur if the new-suspect-on-trap is set to false? David Hustace The OpenNMS Group, Inc. '\ . . |> \ . ' . | O>> . 'o | \ . | /\ . | / / .' | ^^^^^^^`^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
From: djrfnet <hda...@rf...> - 2012-01-24 10:32:55
|
Hi, When checking the configuration files regarding to receiving traps: eventconfig.xml manages the trap definitions; while the wiki page about trapd (http://www.opennms.org/wiki/Trapd) does not mention v3 configuration. I suppose snmp-config.xml is about configuring snmp client inside NMS to talk to a snmp agent in devices, which supports SNMP v3. There is snmp-config.xml in $NMS_HOME/etc/examples showing that. No example of trapd-configuration.xml is found in that folder. However, I just take a look at org.opennms.netmgt.trapd Java code. There is a function setSnmpV3Users to set v3 security settings. Does anyone knows where to set? -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7219824.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: djrfnet <hda...@rf...> - 2012-01-31 07:29:47
|
Hi, I think I've found the culprit, somewhere still in snmp4j. It doesn't matter whether new-suspect-on-trap is true or false. I have pointed out that it only works for a few minutes. For the working period, the following is a piece of snmp-internal.log: 2012-01-31 15:11:11,946 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.mp.MPv3: SNMPv3 header decoded: msgId=335921885, msgMaxSize=65507, msgFlags=03, secModel=3 2012-01-31 15:11:11,946 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.USM: getUser(engineID=01:02:03:04:05, securityName=rfnetech) 2012-01-31 15:11:11,947 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.UsmTimeTable: CheckTime: time ok (non authorative) 2012-01-31 15:11:11,947 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: initVect is 00:00:00:00:00:00:00:00:23:1d:47:cf:7a:0b:ad:a7 2012-01-31 15:11:11,947 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: Data to decrypt 30:81:b6:02:01:03:30:11:02:04:14:05:c2:dd:02:03:00:ff:e3:04:01:03:02:01:03:04:31:30:2f:04:05:01:02:03:04:05:02:01:00:02:01:00:04:08:72:66:6e:65:74:65:63:68:04:0c:d5:c4:30:3e:39:9b:4f:93:c0:cf:1b:04:04:08:23:1d:47:cf:7a:0b:ad:a7:04:6b:67:8a:ad:5e:39:ec:26:14:8a:58:76:b2:0e:f0:d6:c5:71:78:82:9e:fa:bd:96:fc:84:17:7d:01:fe:c8:60:2e:13:29:28:b9:ca:71:16:74:31:da:0a:5c:ed:c2:b8:48:da:2a:88:8e:a0:f6:56:fa:70:23:8d:cd:48:aa:9b:8f:24:cd:3b:72:dd:49:09:0a:8a:94:66:b7:4a:5e:e4:d1:5f:5a:0c:04:31:7a:5e:d1:d3:8a:c5:18:c1:06:35:32:c9:b9:99:cc:ca:8b:e1:d6:1e:63:67 2012-01-31 15:11:11,947 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: used key 6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f 2012-01-31 15:11:11,947 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: used privacy_params 23:1d:47:cf:7a:0b:ad:a7 2012-01-31 15:11:11,947 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: decrypted Data However, after awhile, it becomes like: 2012-01-31 15:12:52,356 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.mp.MPv3: SNMPv3 header decoded: msgId=748721846, msgMaxSize=65507, msgFlags=03, secModel=3 2012-01-31 15:12:52,356 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.USM: getUser(engineID=01:02:03:04:05, securityName=rfnetech) 2012-01-31 15:12:52,356 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.UsmTimeTable: CheckTime: received message outside time window (non authorative) 2012-01-31 15:12:52,356 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.USM: RFC3414 §3.2.7.a Not in time window; engineID='01:02:03:04:05', engineBoots=0, engineTime=0 2012-01-31 15:12:52,356 WARN [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.MessageDispatcherImpl: 1.3.6.1.6.3.15.1.1.2.0 = 0 snmp4j complains about UsmTime not in a certain window, so it drops the trap (I guess). -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7239178.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: geajith <aji...@de...> - 2012-01-31 08:31:52
|
Hi, yes. Even I think the issue is with the Timeliness verfification of the snmp messages. Just a thought on this SNMP V3 Trap authentication. The SNMP V3 manadates that the traps should be received within the specified time window. The following explanation would help... " This is based on the snmpEngineBoots and snmpEngineTime. When an SNMP engine is installed, both of the two values are set to zero. After the SNMP engine has been started, snmpEngineTime is incremented once per second. These values are placed in each outgoing message. The receiving management node's SNMP-engine then determines whether or not the incoming message is in the acceptable time window of 150 seconds. If the message doesn't fit the time window, it is simply ignored." Also in the SNMP 4J codebase, the UsmTimeTable.java; the CheckTime function validates this behavior as well. snippet : if ((entry.getEngineBoots() < time.getEngineBoots()) || ((entry.getEngineBoots() == time .getEngineBoots()) && (time.getTimeDiff() + now > entry.getLatestReceivedTime() + 150)) || (time.getEngineBoots() == 2147483647)) { if (logger.isDebugEnabled()) { logger .debug("CheckTime: received message outside time window (non authorative)"); } return SnmpConstants.SNMPv3_USM_NOT_IN_TIME_WINDOW; Hope this will help to get some insight on this. -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7239236.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: Alejandro G. <ag...@sy...> - 2012-01-31 18:54:10
|
Hello, This is a very good analysis. Thanks a lot for that! I'm still trying to figure it out what's wrong. In the meantime, I'll appreciate if you try something for me: download the JAR of the latest version of snmp4j and replace the existing one on /opt/opennms/lib, restart OpenNMS and let me know how it goes. https://server.oosnmp.net/dist/release/org/snmp4j/snmp4j/2.0.3/snmp4j-2.0.3.jar Alejandro. On Jan 31, 2012, at 3:45 AM, geajith wrote: > Hi, > > yes. Even I think the issue is with the Timeliness verfification of the snmp > messages. > > Just a thought on this SNMP V3 Trap authentication. The SNMP V3 manadates > that the traps should be received within the specified time window. > > The following explanation would help... > > > " This is based on the snmpEngineBoots and snmpEngineTime. When an SNMP > engine is installed, both of the two values are set to zero. After the SNMP > engine has been started, snmpEngineTime is incremented once per second. > These values are placed in each outgoing message. The receiving management > node's SNMP-engine then determines whether or not the incoming message is in > the acceptable time window of 150 seconds. If the message doesn't fit the > time window, it is simply ignored." > > > Also in the SNMP 4J codebase, the UsmTimeTable.java; the CheckTime function > validates this behavior as well. > snippet : > > > if ((entry.getEngineBoots() < time.getEngineBoots()) > || ((entry.getEngineBoots() == time > .getEngineBoots()) && > (time.getTimeDiff() > + now > entry.getLatestReceivedTime() + > 150)) > || (time.getEngineBoots() == 2147483647)) { > if (logger.isDebugEnabled()) { > logger > .debug("CheckTime: received message > outside time window (non authorative)"); > } > return SnmpConstants.SNMPv3_USM_NOT_IN_TIME_WINDOW; > > Hope this will help to get some insight on this. |
From: Alejandro G. <ag...@sy...> - 2012-01-24 12:27:58
|
Hello, The information stored on snmp-config.xml regarding to SNMPv3 is used for polling and data collection. I'm actually in the process of updating the documentation of Trapd. It is not mentioned but it is possible to receive SNMPv3 Traps. You must use at least 1.8.13 or 1.9.90 as explained here: http://issues.opennms.org/browse/NMS-2995 You must define the SNMPv3 users on trapd-configuration.xml, like this: <trapd-configuration snmp-trap-port="162" new-suspect-on-trap="true"> <snmpv3-user security-name="opennms" auth-passphrase="0p3nNMSv3" auth-protocol="MD5" privacy-passphrase="0p3nNMSv3" privacy-protocol="DES"/> <snmpv3-user security-name="agalue" auth-passphrase="secret" auth-protocol="MD5" privacy-passphrase="super-secret" privacy-protocol="DES"/> </trapd-configuration> Alejandro. On Jan 24, 2012, at 6:02 AM, djrfnet wrote: > Hi, > > When checking the configuration files regarding to receiving traps: > eventconfig.xml manages the trap definitions; while the wiki page about > trapd (http://www.opennms.org/wiki/Trapd) does not mention v3 configuration. > I suppose snmp-config.xml is about configuring snmp client inside NMS to > talk to a snmp agent in devices, which supports SNMP v3. There is > snmp-config.xml in $NMS_HOME/etc/examples showing that. No example of > trapd-configuration.xml is found in that folder. > > However, I just take a look at org.opennms.netmgt.trapd Java code. There is > a function setSnmpV3Users to set v3 security settings. Does anyone knows > where to set? |
From: djrfnet <hda...@rf...> - 2012-01-25 07:46:35
|
that's great. but How to set engineID? Is it auto-generated internally in NMS? Based on that snmp v3 tutorial, snmpget or walk is able to obtain it, isn't it? -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7223159.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: Alejandro G. <ag...@sy...> - 2012-01-25 15:23:47
|
Hello, I can't remember the details except for the information reported on NMS-2995, but I know that there is a flaw with the SNMP4J library used by OpenNMS when a user is explicitly created with a specific Engine ID. So, I guess (but I'm not sure) that probably it is internally auto-generated, auto-discovered or maybe is not being used by SNMP4J. I know that the Engine-ID plus the User Name should be used in conjunction to authenticate the SNMPv3 Trap, but for some reason, SNMP4J does not behaves as expected in that matter. Alejandro. On Jan 25, 2012, at 3:16 AM, djrfnet wrote: > that's great. > but How to set engineID? Is it auto-generated internally in NMS? > Based on that snmp v3 tutorial, snmpget or walk is able to obtain it, isn't > it? |
From: Antonio R. <rss...@ya...> - 2012-01-25 16:27:01
|
Well, I guess that is that Snmp4j does not use it to authenticate the traps. Just take a look at this article to understand why in this case the engineid cannot be guessed and should be explicitly added in configuration! http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap-v3.html Let me quote the relevant part: "SNMPv3 TRAPs are a bit more complicated in some ways, but it makes sense the protocol works this way if you spend a long time thinking about it. The difference is that SNMPv3 TRAPs use the engineID of the local application sending the trap rather than the engineID of theremote application. This means that you have to create users in your remote user database with a bit more care and need to create one for every engineID you wish to send traps from." Antonio Il giorno 25/gen/2012, alle ore 16.01, Alejandro Galue ha scritto: > Hello, > > I can't remember the details except for the information reported on NMS-2995, but I know that there is a flaw with the SNMP4J library used by OpenNMS when a user is explicitly created with a specific Engine ID. So, I guess (but I'm not sure) that probably it is internally auto-generated, auto-discovered or maybe is not being used by SNMP4J. > > I know that the Engine-ID plus the User Name should be used in conjunction to authenticate the SNMPv3 Trap, but for some reason, SNMP4J does not behaves as expected in that matter. > > Alejandro. > > On Jan 25, 2012, at 3:16 AM, djrfnet wrote: > >> that's great. >> but How to set engineID? Is it auto-generated internally in NMS? >> Based on that snmp v3 tutorial, snmpget or walk is able to obtain it, isn't >> it? > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > > opennms-discuss mailing list > > To *unsubscribe* or change your subscription options, see the bottom of this page: > https://lists.sourceforge.net/lists/listinfo/opennms-discuss |
From: djrfnet <hda...@rf...> - 2012-01-26 06:13:34
|
Hi, I just did some experiment. My NMS trapd configuration is like <trapd-configuration snmp-trap-port="162" new-suspect-on-trap="true"> <snmpv3-user security-name="user" auth-passphrase="0p3nNMSv3" auth-protocol="MD5" privacy-passphrase="0p3nNMSv3" privacy-protocol="DES" engine-id="0102030405"/> </trapd-configuration> I enable snmp trap sending in one of my Netasq firewalls with security setting according to nms trapd config. After I restart nms, for a few minutes I can see traps coming from the firewall in the event view panel. But it didn't last long, only for a few minutes. Another strange thing is in trapd.log nms says it receives v2 trap: 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] Snmp4JTrapNotifier$Snmp4JV2TrapInformation: V2 TRAP numVars or pdu length: 7 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] Snmp4JTrapNotifier$Snmp4JV2TrapInformation: v2 trap - trapInterface: /10.1.18.1 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] Snmp4JTrapNotifier$Snmp4JV2TrapInformation: V2 TRAP first varbind value: 0:06:42.59 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] Snmp4JTrapNotifier$Snmp4JV2TrapInformation: V2 TRAP first varbind value is of type TIMETICKS (correct) 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] TrapIdentity: snmpTrapOID: .1.3.6.1.4.1.11256.1.6.1 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] EventCreator: setTrapIdentity: snmp trap [Generic=6, Specific=1, EnterpriseId=.1.3.6.1.4.1.11256.1.6] 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] Snmp4JTrapNotifier$Snmp4JV2TrapInformation: Skipping processing of varbind 0: it is sysuptime and the first varbind, and is not processed as a parm per RFC2089 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] Snmp4JTrapNotifier$Snmp4JV2TrapInformation: Skipping processing of varbind 1: it is the trap OID and the second varbind, and is not processed as a parm per RFC2089 2012-01-26 13:37:19,872 DEBUG [TrapQueueProcessor] EventConfData: Match found using key: EventKey [ generic = [6] ] I am pretty sure the firewall is configured to send out v3 traps, which I double-check with wireshark. It says the captured snmp packets has encryptedpdu. Has anyone managed to make nms receive v3 traps? -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7226123.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: Alejandro G. <ag...@sy...> - 2012-01-26 12:05:35
|
Hello, You can enable DEBUG for snmp4j in log4j.properties like the following: log4j.category.org.snmp4j=DEBUG, SNMP4J-INTERNAL Then check snmp4j-internal.log for more details. Trapd will say that he received a V2 trap because the handler for V2 and V3 is the same, so you can find the details about the decoding in snmp4j-internal.log. If you can see the events in OpenNMS is because the traps were successfully processed. Also, please remove the engine-id entry from the snmpv3-user, this won't be used by SNMP4J. Alejandro On Jan 26, 2012, at 1:43 AM, djrfnet wrote: > Hi, > > I just did some experiment. My NMS trapd configuration is like > > <trapd-configuration snmp-trap-port="162" new-suspect-on-trap="true"> > <snmpv3-user security-name="user" auth-passphrase="0p3nNMSv3" > auth-protocol="MD5" > privacy-passphrase="0p3nNMSv3" privacy-protocol="DES" > engine-id="0102030405"/> > </trapd-configuration> > > I enable snmp trap sending in one of my Netasq firewalls with security > setting according to nms trapd config. > > After I restart nms, for a few minutes I can see traps coming from the > firewall in the event view panel. But it didn't last long, only for a few > minutes. > > Another strange thing is in trapd.log nms says it receives v2 trap: > > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] > Snmp4JTrapNotifier$Snmp4JV2TrapInformation: V2 TRAP numVars or pdu length: 7 > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] > Snmp4JTrapNotifier$Snmp4JV2TrapInformation: v2 trap - trapInterface: > /10.1.18.1 > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] > Snmp4JTrapNotifier$Snmp4JV2TrapInformation: V2 TRAP first varbind value: > 0:06:42.59 > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] > Snmp4JTrapNotifier$Snmp4JV2TrapInformation: V2 TRAP first varbind value is > of type TIMETICKS (correct) > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] TrapIdentity: > snmpTrapOID: .1.3.6.1.4.1.11256.1.6.1 > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] EventCreator: > setTrapIdentity: snmp trap [Generic=6, Specific=1, > EnterpriseId=.1.3.6.1.4.1.11256.1.6] > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] > Snmp4JTrapNotifier$Snmp4JV2TrapInformation: Skipping processing of varbind > 0: it is sysuptime and the first varbind, and is not processed as a parm per > RFC2089 > 2012-01-26 13:37:19,871 DEBUG [TrapQueueProcessor] > Snmp4JTrapNotifier$Snmp4JV2TrapInformation: Skipping processing of varbind > 1: it is the trap OID and the second varbind, and is not processed as a parm > per RFC2089 > 2012-01-26 13:37:19,872 DEBUG [TrapQueueProcessor] EventConfData: Match > found using key: EventKey > [ > generic = [6] > > ] > > I am pretty sure the firewall is configured to send out v3 traps, which I > double-check with wireshark. It says the captured snmp packets has > encryptedpdu. > > Has anyone managed to make nms receive v3 traps? > > -- > View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7226123.html > Sent from the OpenNMS - discuss mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > > opennms-discuss mailing list > > To *unsubscribe* or change your subscription options, see the bottom of this page: > https://lists.sourceforge.net/lists/listinfo/opennms-discuss |
From: Alejandro G. <ag...@sy...> - 2012-01-31 22:11:40
|
Hello, I've discovered that upgrading SNMP4J does not fix the problem, because I was able to reproduce the problem locally. I found a very interesting thread regarding this problem here: http://comments.gmane.org/gmane.network.snmp4j.general/521 Alejandro. On Jan 31, 2012, at 2:23 PM, Alejandro Galue wrote: > Hello, > > This is a very good analysis. Thanks a lot for that! > > I'm still trying to figure it out what's wrong. > > In the meantime, I'll appreciate if you try something for me: download the JAR of the latest version of snmp4j and replace the existing one on /opt/opennms/lib, restart OpenNMS and let me know how it goes. > > https://server.oosnmp.net/dist/release/org/snmp4j/snmp4j/2.0.3/snmp4j-2.0.3.jar > > Alejandro. > > On Jan 31, 2012, at 3:45 AM, geajith wrote: > >> Hi, >> >> yes. Even I think the issue is with the Timeliness verfification of the snmp >> messages. >> >> Just a thought on this SNMP V3 Trap authentication. The SNMP V3 manadates >> that the traps should be received within the specified time window. >> >> The following explanation would help... >> >> >> " This is based on the snmpEngineBoots and snmpEngineTime. When an SNMP >> engine is installed, both of the two values are set to zero. After the SNMP >> engine has been started, snmpEngineTime is incremented once per second. >> These values are placed in each outgoing message. The receiving management >> node's SNMP-engine then determines whether or not the incoming message is in >> the acceptable time window of 150 seconds. If the message doesn't fit the >> time window, it is simply ignored." >> >> >> Also in the SNMP 4J codebase, the UsmTimeTable.java; the CheckTime function >> validates this behavior as well. >> snippet : >> >> >> if ((entry.getEngineBoots() < time.getEngineBoots()) >> || ((entry.getEngineBoots() == time >> .getEngineBoots()) && >> (time.getTimeDiff() >> + now > entry.getLatestReceivedTime() + >> 150)) >> || (time.getEngineBoots() == 2147483647)) { >> if (logger.isDebugEnabled()) { >> logger >> .debug("CheckTime: received message >> outside time window (non authorative)"); >> } >> return SnmpConstants.SNMPv3_USM_NOT_IN_TIME_WINDOW; >> >> Hope this will help to get some insight on this. |
From: djrfnet <hda...@rf...> - 2012-02-01 02:01:09
|
I did another test. I make the trap sender use different engine ID to send v3 trap. The problem is bypassed. I guess it may not be the proper way. And it doesn't work in the case that I no control of the v3 trap sender. -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7241909.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: djrfnet <hda...@rf...> - 2012-01-27 03:30:34
|
hi, I enabled snmp DEBUG. This is a piece of msg in snmp4j-internal.log: 2012-01-27 10:31:25,812 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.transport.DefaultUdpTransportMapping: Received message from /10.1.18.1/10614 with length 313: 30:82:01:35:02:01:03:30:11:02:04:2b:a5:cf:e1:02:03:00:ff:e3:04:01:03:02:01:03:04:31:30:2f:04:05:01:02:03:04:05:02:01:00:02:01:00:04:08:72:66:6e:65:74:65:63:68:04:0c:9c:ec:23:2b:e3:80:eb:3f:cf:95:ac:49:04:08:93:a1:68:21:80:59:02:51:04:81:e9:01:5f:86:9a:7a:be:cf:60:65:d0:33:11:f8:89:0e:0a:af:09:3c:c1:72:25:11:30:75:47:e2:7c:d4:82:a1:49:dc:f5:b0:5c:fa:45:12:31:77:3e:d9:5f:a8:91:49:fc:dd:fb:82:d8:34:f4:85:4c:46:99:ba:d5:3e:de:17:fa:fa:52:b8:74:73:f0:b3:2f:4d:68:c5:35:68:eb:d1:6d:b1:3a:e7:47:11:e3:6a:99:09:6e:22:4a:27:69:04:73:97:71:fe:3c:c2:27:d7:b6:f7:db:d7:b5:7d:2b:1c:72:d4:06:ae:12:43:63:62:c2:51:55:6f:9e:55:8d:14:48:5d:3b:1d:1e:23:a0:d9:a3:87:82:b4:8b:75:8e:47:90:8d:29:dc:94:b7:b8:9e:34:cb:cc:1c:be:20:42:b8:e4:64:25:2f:e6:af:cb:1d:c2:a0:2a:3a:0a:21:a6:ec:1f:12:57:48:23:c5:f7:f5:f6:58:25:ad:b0:7f:18:67:7f:02:c9:43:aa:94:80:73:6c:a4:b4:d2:5b:0d:02:08:e5:9d:0f:60:e1:54:8b:d5:f8:61:9d:3f:f8:9a:04:e6:26:0c:8e:44:e1:88:59:5c:33:0c 2012-01-27 10:31:25,823 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.mp.MPv3: SNMPv3 header decoded: msgId=732286945, msgMaxSize=65507, msgFlags=03, secModel=3 2012-01-27 10:31:25,827 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.USM: getUser(engineID=01:02:03:04:05, securityName=rfnetech) 2012-01-27 10:31:25,862 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.AuthGeneric: MD5First digest: 87:78:72:ab:e4:0e:db:5a:98:82:b5:58:a3:51:56:70 2012-01-27 10:31:25,862 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.AuthGeneric: MD5localized key: 6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f 2012-01-27 10:31:25,878 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.AuthGeneric: MD5First digest: 87:78:72:ab:e4:0e:db:5a:98:82:b5:58:a3:51:56:70 2012-01-27 10:31:25,878 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.AuthGeneric: MD5localized key: 6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f 2012-01-27 10:31:25,878 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.UsmUserTable: Adding user rfnetech = UsmUser[secName=rfnetech,authProtocol=1.3.6.1.6.3.10.1.1.2,authPassphrase=6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f,privProtocol=1.3.6.1.6.3.10.1.2.4,privPassphrase=6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f,localizationEngineID=01:02:03:04:05] 2012-01-27 10:31:25,879 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.UsmTimeTable: CheckTime: time ok (non authorative) 2012-01-27 10:31:25,880 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: initVect is 00:00:00:00:00:00:00:00:93:a1:68:21:80:59:02:51 2012-01-27 10:31:26,130 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: Data to decrypt 30:82:01:35:02:01:03:30:11:02:04:2b:a5:cf:e1:02:03:00:ff:e3:04:01:03:02:01:03:04:31:30:2f:04:05:01:02:03:04:05:02:01:00:02:01:00:04:08:72:66:6e:65:74:65:63:68:04:0c:9c:ec:23:2b:e3:80:eb:3f:cf:95:ac:49:04:08:93:a1:68:21:80:59:02:51:04:81:e9:01:5f:86:9a:7a:be:cf:60:65:d0:33:11:f8:89:0e:0a:af:09:3c:c1:72:25:11:30:75:47:e2:7c:d4:82:a1:49:dc:f5:b0:5c:fa:45:12:31:77:3e:d9:5f:a8:91:49:fc:dd:fb:82:d8:34:f4:85:4c:46:99:ba:d5:3e:de:17:fa:fa:52:b8:74:73:f0:b3:2f:4d:68:c5:35:68:eb:d1:6d:b1:3a:e7:47:11:e3:6a:99:09:6e:22:4a:27:69:04:73:97:71:fe:3c:c2:27:d7:b6:f7:db:d7:b5:7d:2b:1c:72:d4:06:ae:12:43:63:62:c2:51:55:6f:9e:55:8d:14:48:5d:3b:1d:1e:23:a0:d9:a3:87:82:b4:8b:75:8e:47:90:8d:29:dc:94:b7:b8:9e:34:cb:cc:1c:be:20:42:b8:e4:64:25:2f:e6:af:cb:1d:c2:a0:2a:3a:0a:21:a6:ec:1f:12:57:48:23:c5:f7:f5:f6:58:25:ad:b0:7f:18:67:7f:02:c9:43:aa:94:80:73:6c:a4:b4:d2:5b:0d:02:08:e5:9d:0f:60:e1:54:8b:d5:f8:61:9d:3f:f8:9a:04:e6:26:0c:8e:44:e1:88:59:5c:33:0c 2012-01-27 10:31:26,132 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: used key 6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f 2012-01-27 10:31:26,132 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: used privacy_params 93:a1:68:21:80:59:02:51 2012-01-27 10:31:26,132 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.security.PrivAES: aes decrypt: decrypted Data 30:81:e6:04:05:01:02:03:04:05:04:00:a7:81:da:02:04:49:63:6c:97:02:01:00:02:01:00:30:81:cb:30:0e:06:08:2b:06:01:02:01:01:03:00:43:02:35:99:30:18:06:0a:2b:06:01:06:03:01:01:04:01:00:06:0a:2b:06:01:04:01:d7:78:01:06:01:30:23:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:01:04:13:32:30:31:32:2d:30:31:2d:32:37:20:31:30:3a:33:30:3a:31:38:30:13:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:02:04:03:44:43:53:30:1b:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:05:04:0b:31:30:2e:33:30:2e:39:30:2e:31:34:30:1c:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:06:04:0c:31:30:2e:33:30:2e:39:30:2e:32:35:35:30:2a:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:0b:04:1a:49:50:20:61:64:64:72:65:73:73:20:73:70:6f:6f:66:69:6e:67:20:74:79:70:65:3d:31 2012-01-27 10:31:26,149 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.mp.MPv3: RFC3412 §7.2.10 - Received PDU is NOT a response or internal class message -> unchanged PduHandle = PduHandle[1231252631] 2012-01-27 10:31:26,153 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] org.snmp4j.Snmp: Fire process PDU event: CommandResponderEvent[transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@17c760bpeerAddress=10.1.18.1/10614, processed=false, pdu=[TRAP[reqestID=1231252631, errorStatus=0, errorIndex=0, VBS[1.3.6.1.2.1.1.3.0 = 0:02:17.21; 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.4.1.11256.1.6.1; 1.3.6.1.4.1.11256.1.5.0.1.1 = 2012-01-27 10:30:18; 1.3.6.1.4.1.11256.1.5.0.1.2 = DCS; 1.3.6.1.4.1.11256.1.5.0.1.5 = 10.30.90.14; 1.3.6.1.4.1.11256.1.5.0.1.6 = 10.30.90.255; 1.3.6.1.4.1.11256.1.5.0.1.11 = IP address spoofing type=1]]], securityName=rfnetech, securityModel=3, securityLevel=3] It looks good. I don't see anything unusual from trapd log either. The only problem is after about two minutes, there is no more log in the trapd of the trap, while logging in snmp4j-internal.log still continues. It is very obvious since I have only one trap source. The problem lies in snmp4j module passing trap info to trapd, I guess. -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7229083.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: Alejandro G. <ag...@sy...> - 2012-01-27 12:06:29
|
Hello, Yeah, the snmp4j-internal.log looks good. What about the DEBUG logging content from trapd.log ? Can you see the event in the WebUI? Alejandro. On Jan 26, 2012, at 11:00 PM, djrfnet wrote: > hi, > > I enabled snmp DEBUG. This is a piece of msg in snmp4j-internal.log: > > > 2012-01-27 10:31:25,812 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.transport.DefaultUdpTransportMapping: Received message from > /10.1.18.1/10614 with length 313: > 30:82:01:35:02:01:03:30:11:02:04:2b:a5:cf:e1:02:03:00:ff:e3:04:01:03:02:01:03:04:31:30:2f:04:05:01:02:03:04:05:02:01:00:02:01:00:04:08:72:66:6e:65:74:65:63:68:04:0c:9c:ec:23:2b:e3:80:eb:3f:cf:95:ac:49:04:08:93:a1:68:21:80:59:02:51:04:81:e9:01:5f:86:9a:7a:be:cf:60:65:d0:33:11:f8:89:0e:0a:af:09:3c:c1:72:25:11:30:75:47:e2:7c:d4:82:a1:49:dc:f5:b0:5c:fa:45:12:31:77:3e:d9:5f:a8:91:49:fc:dd:fb:82:d8:34:f4:85:4c:46:99:ba:d5:3e:de:17:fa:fa:52:b8:74:73:f0:b3:2f:4d:68:c5:35:68:eb:d1:6d:b1:3a:e7:47:11:e3:6a:99:09:6e:22:4a:27:69:04:73:97:71:fe:3c:c2:27:d7:b6:f7:db:d7:b5:7d:2b:1c:72:d4:06:ae:12:43:63:62:c2:51:55:6f:9e:55:8d:14:48:5d:3b:1d:1e:23:a0:d9:a3:87:82:b4:8b:75:8e:47:90:8d:29:dc:94:b7:b8:9e:34:cb:cc:1c:be:20:42:b8:e4:64:25:2f:e6:af:cb:1d:c2:a0:2a:3a:0a:21:a6:ec:1f:12:57:48:23:c5:f7:f5:f6:58:25:ad:b0:7f:18:67:7f:02:c9:43:aa:94:80:73:6c:a4:b4:d2:5b:0d:02:08:e5:9d:0f:60:e1:54:8b:d5:f8:61:9d:3f:f8:9a:04:e6:26:0c:8e:44:e1:88:59:5c:33:0c > 2012-01-27 10:31:25,823 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.mp.MPv3: SNMPv3 header decoded: msgId=732286945, > msgMaxSize=65507, msgFlags=03, secModel=3 > 2012-01-27 10:31:25,827 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.USM: getUser(engineID=01:02:03:04:05, > securityName=rfnetech) > 2012-01-27 10:31:25,862 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.AuthGeneric: MD5First digest: > 87:78:72:ab:e4:0e:db:5a:98:82:b5:58:a3:51:56:70 > 2012-01-27 10:31:25,862 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.AuthGeneric: MD5localized key: > 6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f > 2012-01-27 10:31:25,878 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.AuthGeneric: MD5First digest: > 87:78:72:ab:e4:0e:db:5a:98:82:b5:58:a3:51:56:70 > 2012-01-27 10:31:25,878 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.AuthGeneric: MD5localized key: > 6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f > 2012-01-27 10:31:25,878 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.UsmUserTable: Adding user rfnetech = > UsmUser[secName=rfnetech,authProtocol=1.3.6.1.6.3.10.1.1.2,authPassphrase=6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f,privProtocol=1.3.6.1.6.3.10.1.2.4,privPassphrase=6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f,localizationEngineID=01:02:03:04:05] > 2012-01-27 10:31:25,879 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.UsmTimeTable: CheckTime: time ok (non authorative) > 2012-01-27 10:31:25,880 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.PrivAES: initVect is > 00:00:00:00:00:00:00:00:93:a1:68:21:80:59:02:51 > 2012-01-27 10:31:26,130 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.PrivAES: aes decrypt: Data to decrypt > 30:82:01:35:02:01:03:30:11:02:04:2b:a5:cf:e1:02:03:00:ff:e3:04:01:03:02:01:03:04:31:30:2f:04:05:01:02:03:04:05:02:01:00:02:01:00:04:08:72:66:6e:65:74:65:63:68:04:0c:9c:ec:23:2b:e3:80:eb:3f:cf:95:ac:49:04:08:93:a1:68:21:80:59:02:51:04:81:e9:01:5f:86:9a:7a:be:cf:60:65:d0:33:11:f8:89:0e:0a:af:09:3c:c1:72:25:11:30:75:47:e2:7c:d4:82:a1:49:dc:f5:b0:5c:fa:45:12:31:77:3e:d9:5f:a8:91:49:fc:dd:fb:82:d8:34:f4:85:4c:46:99:ba:d5:3e:de:17:fa:fa:52:b8:74:73:f0:b3:2f:4d:68:c5:35:68:eb:d1:6d:b1:3a:e7:47:11:e3:6a:99:09:6e:22:4a:27:69:04:73:97:71:fe:3c:c2:27:d7:b6:f7:db:d7:b5:7d:2b:1c:72:d4:06:ae:12:43:63:62:c2:51:55:6f:9e:55:8d:14:48:5d:3b:1d:1e:23:a0:d9:a3:87:82:b4:8b:75:8e:47:90:8d:29:dc:94:b7:b8:9e:34:cb:cc:1c:be:20:42:b8:e4:64:25:2f:e6:af:cb:1d:c2:a0:2a:3a:0a:21:a6:ec:1f:12:57:48:23:c5:f7:f5:f6:58:25:ad:b0:7f:18:67:7f:02:c9:43:aa:94:80:73:6c:a4:b4:d2:5b:0d:02:08:e5:9d:0f:60:e1:54:8b:d5:f8:61:9d:3f:f8:9a:04:e6:26:0c:8e:44:e1:88:59:5c:33:0c > 2012-01-27 10:31:26,132 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.PrivAES: aes decrypt: used key > 6b:6b:be:95:12:91:95:bc:de:88:b1:2d:73:c4:92:2f > 2012-01-27 10:31:26,132 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.PrivAES: aes decrypt: used privacy_params > 93:a1:68:21:80:59:02:51 > 2012-01-27 10:31:26,132 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.security.PrivAES: aes decrypt: decrypted Data > 30:81:e6:04:05:01:02:03:04:05:04:00:a7:81:da:02:04:49:63:6c:97:02:01:00:02:01:00:30:81:cb:30:0e:06:08:2b:06:01:02:01:01:03:00:43:02:35:99:30:18:06:0a:2b:06:01:06:03:01:01:04:01:00:06:0a:2b:06:01:04:01:d7:78:01:06:01:30:23:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:01:04:13:32:30:31:32:2d:30:31:2d:32:37:20:31:30:3a:33:30:3a:31:38:30:13:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:02:04:03:44:43:53:30:1b:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:05:04:0b:31:30:2e:33:30:2e:39:30:2e:31:34:30:1c:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:06:04:0c:31:30:2e:33:30:2e:39:30:2e:32:35:35:30:2a:06:0c:2b:06:01:04:01:d7:78:01:05:00:01:0b:04:1a:49:50:20:61:64:64:72:65:73:73:20:73:70:6f:6f:66:69:6e:67:20:74:79:70:65:3d:31 > 2012-01-27 10:31:26,149 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.mp.MPv3: RFC3412 §7.2.10 - Received PDU is NOT a response or > internal class message -> unchanged PduHandle = PduHandle[1231252631] > 2012-01-27 10:31:26,153 DEBUG [DefaultUDPTransportMapping_0.0.0.0/162] > org.snmp4j.Snmp: Fire process PDU event: > CommandResponderEvent[transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@17c760bpeerAddress=10.1.18.1/10614, > processed=false, pdu=[TRAP[reqestID=1231252631, errorStatus=0, errorIndex=0, > VBS[1.3.6.1.2.1.1.3.0 = 0:02:17.21; 1.3.6.1.6.3.1.1.4.1.0 = > 1.3.6.1.4.1.11256.1.6.1; 1.3.6.1.4.1.11256.1.5.0.1.1 = 2012-01-27 10:30:18; > 1.3.6.1.4.1.11256.1.5.0.1.2 = DCS; 1.3.6.1.4.1.11256.1.5.0.1.5 = > 10.30.90.14; 1.3.6.1.4.1.11256.1.5.0.1.6 = 10.30.90.255; > 1.3.6.1.4.1.11256.1.5.0.1.11 = IP address spoofing type=1]]], > securityName=rfnetech, securityModel=3, securityLevel=3] > > It looks good. I don't see anything unusual from trapd log either. The only > problem is after about two minutes, there is no more log in the trapd of the > trap, while logging in snmp4j-internal.log still continues. It is very > obvious since I have only one trap source. > > The problem lies in snmp4j module passing trap info to trapd, I guess. > > -- > View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7229083.html > Sent from the OpenNMS - discuss mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > > opennms-discuss mailing list > > To *unsubscribe* or change your subscription options, see the bottom of this page: > https://lists.sourceforge.net/lists/listinfo/opennms-discuss |
From: djrfnet <hda...@rf...> - 2012-01-28 01:59:18
|
yes, I can see the event in web UI. But it stopped to appear in web UI and trapd.log as well after about two minutes, although the traps continue to appear in snmp4j-internal.log. -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7231662.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |
From: djrfnet <hda...@rf...> - 2012-01-30 11:26:27
|
anyone got any more comments? Can I raise a bug report regarding to this? -- View this message in context: http://opennms.530661.n2.nabble.com/How-to-Receive-V3-Traps-in-openNMS-tp6425566p7236249.html Sent from the OpenNMS - discuss mailing list archive at Nabble.com. |